The one thing that stops designers dead in their tracks

It’s not the lack of inspiration (that’s true). It’s not imposter syndrome (that happens). It’s something we forget to ask for.

The one thing that stops designers dead in their tracks
Getty Images on Unsplash+

During a coaching 1-on-1 design session, a designer brought the screens she was working on asking for a review of her very complex enterprise app feature.

She gave me the tour of the step-by-step actions the user would take. At the final screen in the sequence, she even had three different options for solving this very detailed interaction of selecting data. That was all great—double thumbs-up, in fact.

I understood exactly what she was solving for, and she even had a good approach. However, as put myself in the user’s shoes, there was one question burning my curiosity.

“So, why does the user want to do this?”

I could hear the realization kick in, and then her excitement.

“Oh!”

She had done an excellent job at making sure the user clearly knew where to go for each of the intermediate steps. Exploring multiple ways the user might work with complex and interpretive data was also top-notch. What was missing was the burning question of the purpose.

She nailed the what, but was missing the why, and that drove every design decision she made.

What we did over the next few minutes was to dive into the higher business process and motivation for the feature. I asked about the process leading up to this task and the one following it, about dependencies and decision points. I wanted to discover if they built this feature exactly as it was, what did they expect to have solved? That’s when we started to discover the true purpose of the feature.

She was able to explain some of those drivers, but where she couldn’t, those became a list of questions she would take back to the stakeholders for clarification. Through the discussion, we even discovered possible ways removing parts of this step benefitted the greater initiative.

This sort of detail was never ever articulated in the requirements—they typically aren’t. It may have been hinted at verbally during the initial meeting, maybe.

It’s very possible to design a great solution and miss solving for the real intended outcome.

The good news of this session was she got a chance to present her design, and I played the role of stakeholder (with a designer’s eye). It was very low-risk for her which boosted her confidence as well as provided an opportunity to refine the flow before going to the real stakeholders.

Why is missing the purpose of a feature such a design killer?

While the current requirement might seem like it’s the solution, it might literally end up being a task—a very good and well designed task—but not moving the needle the stakeholders actually want moved.

Think of the real purpose as waiting at the head of a branching river. One branch leads to delivering value, and the other is the current requirement everyone was briefed on. Perhaps you’re on the right branch, but perhaps not.

Designers need to go back upstream and help stakeholders define the purpose through some well-guided questions. This amounts to getting an understanding of what is the intended outcome.

Without that, we end up guessing instead of designing.

Once you find—and agree—on the real purpose, you’re free to explore all the options that may fulfill that outcome. There are always infinite possible options—some stronger and some weaker—and they each have their tradeoffs. You job is to tease out the strongest.

With the intended outcome in mind, design decisions become more purposeful and design reviews become more objective.

The designer I was coaching came to our next session with a win

She asked the questions we discovered and brought new clarity to her stakeholders. They were able to refine the feature and trim it down. Cutting out complexity to deliver a more purposeful feature also saved development time.

When the stakeholder, engineer, and users benefit from a single, purposeful design, that’s designing for value.


Are you in a similar situation of designing only for requirements?

  • I have a quick course on How to Make Vague Requirements Clear at Designy Academy that goes deeper into the how-to. You can get it done in a lunch hour.
  • If you’re looking for some more specific 1-on-1 design advice, reply to this email or leave a comment and let’s set up a free call to review the challenges you’re facing. Perhaps I can help.

Thanks for stopping by—