Why simple UX stories are best: the power of clarifying ambiguity
Why going back to basics can often be the best approach
Sometimes, telling the most straightforward UX story is the best approach.
One of the things I’ve often seen when reviewing other designers' portfolios is a desire to overcomplicate and overexplain. There’s a tendency to dive into the details and talk about everything you did, but that’s often not what your audience wants.
Instead, a simple story may be one of the most compelling: You listened to ambiguous requirements, worked to clarify them, and designed an intuitive user experience that people understood.
That simple story is at the heart of many design projects, and it’s often a designer’s strength that we often forget about.
Visualizing designs requires clearing up ambiguity
The best designers tend to ask many questions during meetings because they tie the answers they get to the mental sketch they’re making.
To many designers, this isn’t a big deal: after all, it’s just creating a sketch.
But to the rest of the team, it’s like a superpower. The fact that we’re thinking visually about what might be a list of requirements on a page is something most of the team can’t do.
Of course, this is just the first step of the design process. A decent sketch is nice, but you must explore different ideas, iterate on them, and more. This is why we often forget that this transformation is compelling to our audience.
This is because this sketching process is about confronting ambiguity. Imagine being told you need to “design a dashboard that points users in a bunch of different places.”
Could you sketch that out right away? Not really. It's incredibly vague, and we have no idea where we’re pointing users or why they’re going to these pages.
You’d probably want to ask a ton of questions like:
Where are we pointing the user towards?
What’s on the dashboard?
Why should users go there?
etc.
That’s the process of clarifying ambiguity. If you get your answers, and the statement turns into “We’re creating a dashboard for metrics W, X, Y, and Z, with links to specific pages if there are problems with that specific metric.”, you can sketch that.
According to The Design Method: A Philosophy and Process for Functional Visual Communication, A designer’s greatest strength is clarifying ambiguous requirements and creating a tangible output.
Here’s how to make use of that.
Explain so your audience understands: create a simple context
To show that you’ve cleared up ambiguity, you must explain the problem in simple terms.
When creating design portfolios, we often don’t think about our audience, but it’s often the most crucial place to start.
Whether it’s a 3rd party recruiter or design interviewers, they do have a few things in common that you must be aware of. First of all, they’re overwhelmed: nowadays, if they’re hiring, they’re likely sorting through 100+ resumes and design portfolios because the UX job market sucks.
Secondly, they’re incredibly busy. If they’re hiring for a position, the organization already has too much work for current employees (otherwise, why would they hire more people?).
However, many interviewers aren’t full-time hiring managers: they’re design managers who must meet with executives, manage designers, do design strategy work, and sort through a pile of resumes in their spare time.
As a result, you need to make the problems you’re trying to solve as simple as possible. Rather than trying to wow them with complex design problems they may or may not fully understand, it’s better to describe the problem in simple terms.
For example, imagine you’re designing an onboarding process for a patient portal. Which of these problem statements is easier for an audience to understand?
I designed patient portal onboarding where I needed to help users understand concepts like Explanation of Benefits vs. a bill and how to find service providers that were in-network and wouldn’t require a hefty co-pay.
Users often get confused about understanding insurance concepts and how to find medical providers covered by insurance, causing them to call in and clog the customer support lines. I designed an onboarding process to help users find what they need.
The second statement highlights the problem from a User (and business) perspective and clearly explains what you’re designing and why. As a result, it’s easier for your audience to understand.
After this comes an interesting question: how do you systematically reduce ambiguity?
The design process and systematically eliminating ambiguity
After we define the problem like this, we need to discuss how you broke down the larger problem and ambiguity through the systematic nature of the design.
Whether it’s a specific design process (like empathize, define, ideate) or a design system (with specific components), we often apply a systematic approach to solving problems.
So, after we’ve framed the problem simply so that others can understand, we need to investigate where the users are struggling. In our onboarding example, this might include:
What concepts do users struggle with?
What concepts are the highest priority to understand (i.e., need to be in onboarding instead of in a help menu)?
What are the main tasks users are hoping to do on the page?
Why are users coming to our site?
Etc.
At this point, we’ve established the overall problem and are now discussing where users struggle.
You paint a logical picture of what should come next by highlighting specific issues and insights about your user that you uncovered through your design process.
If users are struggling with concepts X, Y, and Z, and you uncovered that all your stakeholders cared most about those three concepts, it shouldn’t be a surprise that you might re-design onboarding with those concepts in mind.
When you systematically define things like this, it becomes easy to trace the design story and showcase how the design plays a role.
Lastly, talk about how you solved the problem
From here, you want to emphasize how your design process addressed the ambiguous problem you started with and whether you solved it.
When we’ve established why a problem started as ambiguous and where users are struggling, laying out a clear path toward solving the problem (and providing clarity) should be a logical next step.
This is where you can bring up your design process but also where you should talk about significant project milestones, like the transformation that occurred around visuals.
In many cases, the first time you show stakeholders (or users) your reimagined design, there is almost a visceral reaction. A vague, ambiguous picture in people’s heads about the design gets replaced by a much clearer picture, and you can sometimes hear the relief in people’s voices.
You want to mention this to showcase how you made something ambiguous tangible (and clear).
Clarifying ambiguity and why it matters.
One of the things that I particularly like about working in healthcare UX is the idea that I often have to simplify complex and unintuitive concepts into something easily understandable.
Doing this for a career has made me hyper-aware that sometimes a designer’s greatest strength is listening as an outsider and turning a list of vague requirements into something visual.
Learning to do this hasn’t just allowed me to solve complex problems and improve my design portfolio. Many people work in complex design fields, and the thought of a candidate who can listen and get to the heart of a problem is incredibly appealing.
So sometimes, the simple approach of telling a story that removes ambiguity is the one that will get interviewers interested in you. After all, the simple story is often the most appealing one.
Kai Wong is a Senior Product Designer. His course, Data-Informed Design, teaches designers to become more effective and valuable to businesses by combining Data and Design.