The what, the how and the when

Weeknotes 8: July 13–17, 2020

As a technical team, we are charged with delivering valuable products. But who decides the what, the how and the when?

This Friday, a fellow UXer and I facilitated a 90 minute session on ‘writing future state requirements’. We invited nearly 30 colleagues from across three project teams, with roles ranging from UX designer to business analyst to technical lead, to join us.

As I explained to attendees at the outset of the meeting, I wanted to have this discussion is because I’m unclear where requirements come from, and who is involved (but I think there’s room for improvement..)

We used funretro to encourage everyone to contribute to the topic, but as you can imagine, follow-on discussion was hindered by the size of the group.

One of the concerns we’d had early on with this format was whether we’d be accurately able to capture the future state and process. Sure enough, it was clear to see that many people had different perspectives of what was involved in preparing for a product release, in terms of the what, the who and the how.

Although we haven’t really reconvened to go through what came out of the session, it got me thinking…..

What will we deliver? / What user needs are we addressing?

Deciding what to work on and deliver isn’t a trivial question, and the best products arise from a balance among three tensions:

• meeting user expectations and needs,
• in a way that is technically feasible, and
• financially and strategically viable for the business.

A Venn diagram showing three overlapping circles: user needs, business goals and technical constraints

It’s not uncommon for a business analyst to decide ‘what to deliver’ — but this shouldn’t be done in isolation without consultation with members of the other disciplines.

Deciding ‘what to deliver’ can be communicated in terms of the user benefit, or at a high level functional requirement. This way the business can feel confident that the planned work addresses strategic goals.

I’ll admit, it’s hard for me to imagine deciding on what to deliver without focusing on user needs. I believe we have to first start with user problems, and then decide if it is a problem the business wants to attempt to address.

In other words:

1. what could we do (user needs)
2. should we do it (does it make sense for us to solve that problem — business goals)
3. how should we do it (technical feasibility)

It doesn’t make sense to make business decisions to release products or features if there is no market demand, and we’re not solving an important problem for people. So although the business analyst may be the person who’s ultimately responsible for making the case for what problems should be addressed, I think that user experience research should be an input into that process. For more information, check out Marty Cagan’s writing about discovery. [He also has some opinions on requirements….]

Early on, to meet our obligations to the business, we can commit to solving an important customer problem — but we can’t know with complete certainty exactly how to solve it, and how much it will cost to do so.

An aside: what do we mean when we talk about being agile?

I remember the days of two-hundred page specification documents, that would outline what was to be built and how things would function. Those were the days before the software community recognized the value of agile software development. For those who aren’t familiar with the 4 values and 12 principles of the 2001 Agile Manifesto, here’s a few of the most applicable principles:

• Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
• Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
• Business people and developers must work together daily throughout the project.
• Continuous attention to technical excellence and good design enhances agility.
• Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
• The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
• Working software is the primary measure of progress.

Agile software development can seem messy, but that is because it’s recognized that we can’t plan for everything up front. To release and get feedback frequently is the way to minimize waste, and offset risk.

How should we solve the problem?

Once we’ve decided what user problems (or functional ‘stuff’) we will be addressing, the next question is “how”.

1. How will the user experience this new ‘stuff’ we release?
2. How should we technically address the problem?

If I asked you how much it cost to build a place to live, could you tell me with any certainty? No — you’d want to know more details to try to get more accurate. Who is it for? What is important to that person? What materials will we use? Where will it be? etc. We want to be sure we’re building something valuable and useful. When we jump too quickly to documenting ‘functional requirements’ (there must be a bedroom, and a bathroom, and a sink) without considering what users are trying to get done and what they value, we risk missing the mark. And, any suggestions made later may appear to change the scope.. even if it could result in a better end product.

I want to pause here a moment, because I’ve been struggling lately with some comments I’ve heard about how UX is about the look-and-feel only, that functionality will always trump “UI enhancements”, and it is the role of the business analyst to determine the functional requirements and then let the UXer know if/when there is work to be done. So this is going to be a bit ranty…

I recognize that some of this pushback may come from when we involve UX. If a business analyst has written a bunch of prescriptive requirements (especially if they’ve documented flows and language), and especially if they’ve already handed that off to a development team to estimate or code, it may seem wasteful to bring in UX, who will offer suggestions to change things. Because it’s already been ‘designed’. Any new ideas for how a feature could work seems like “an enhancement”.

We need to stop thinking of UX as “an [optional] improvement”. That assumes that what we came up with first was already good enough. Instead, we need to bring our UX designers in at the beginning, so we’re not pushing off their work for “future UI releases” or griping at the extra cost to go back and change/fix things.

Everything is designed, whether we have someone skilled in design working on it or not.

Early on, I relied on a Venn diagram found widely across the Internet. Perhaps it was ignorable as we’re not some venture-backed Silicon Valley product company. But may I also draw your attention to our own Government of Canada Digital Standards?

Government of Canada Digital Standards Guiding Principles — the first is “design with users”

The very first standard is “design with users”. And yet I’ve seen pushback that the contributions of people with the actual title of “User Experience Designer” are but enhancements that we can defer to some possible future release.

When we choose not to involve a UX designer in designing how a feature should work, we’re saying that we value outputs (ship something) over outcomes (ship something that helps people do their work). We’re saying we don’t value a discipline that has real documented ROI behind it. We’re saying that we don’t respect our colleagues who have been hired to do a job.

I’m sure it’s not intentional, but I hope that we can find a middle ground where we can each find a place at the table — or the three-legged stool — to work together to design and deliver valuable products.