Should I cover every single user flow including error states in wireframes for web and mobile applications?

Question

While creating wireframes, I mostly create the obvious screens and flows, and leave out all the micro flows like error states or less important screens. These are then fleshed out when creating the high-fidelity prototype. But due to this, I often end up missing screens that the developer then has to work with me on to build out. In some situations we miss out on the screen entirely resulting in users winding up in dead ends.

One way I thought to solve the problem was to create detailed task flows and then using the task flows as a reference to create wireframes that cover every single flow. But my concern is that this is going to end up being an unnecessarily time consuming effort.

Have you followed this process and seen good results? Is it worth the extra time? Can I just create detailed task flows and skip creating detailed wireframes and go directly to the low-fidelity mockup? (will still wireframe high-priority flows)

Any advice is appreciated. Thanks in advance.

Answer 1

As you mentioned before, there are trade-offs between working in high and low fidelity when it comes to creating prototypes.

I can offer a suggestion that might help give you the best of both worlds - create high level task flows (so not detailed task flows) but for every deviation or new pattern from the standard UI design (based on the existing UI or development framework) you can annotate and create detailed designs to help the developers answer their questions.

Actually, I think that the role of the UX designer isn't so much to focus on the detailed designs (although I know that one must wear more than one hat sometimes), but to educate the rest of the team and improve their skill levels. For instance, if you try to establish a common language for the BAs, designers and developers to communicate on the requirements, and for the designers and developers to have a common understanding about how the design work is done (e.g. design language or design system) then it means that over time they will become more efficient at doing their work.

As you said before, creating anything in detail can often be unnecessarily time consuming, but you have to look at the maturity of the design and development process and methodology (which includes the technology stack). So I suggest that you need to also look at your process as a UX research question as well - talk to your users and work out what the problem is before coming up with a solution.

Answer 2

Thank you for your detailed answer, Michael. When I first read your answer, a lot of the gaps in the process and the design system were oblivious to me. I have a fairly better idea now, so I thought I’d post an update based on what I understand.

Short answer: Yes, covering every flow including error states in wireframes has saved a lot of additional time and effort for my team and I down the lane. High-level task flows suffice since they just need to set the overall direction that the wireframes will flesh out.

Long answer: As Michael pointed out, there are obvious gaps in three areas:

There is no common language for designers and developers for the most part.

This is creating inconsistent designs, duplication of work and an unnecessary amount of time discussing how something should work (and/or rebuilding interactions).

The design and development process is not mature This results in designers/developers discovering missing screens at the prototyping/development stage. And mostly, we also discover that we hadn’t thought through how the product should behave in certain situations.

Incomplete understanding of the user Lack of clarity on:

• Motivations behind using a particular feature
• Outcomes from using it
• Frustrations while trying to use it
• Different types of users who might use the feature

These issues are being addressed currently along with a few changes to the design process.

Changes are:

1. After User research and before building user flows, designer breaks the PRD into user stories (smaller the better) to give clarity on outcomes.
2. User scenarios are fleshed out before building user flows
3. High-level user flows are built
4. Fully fleshed out wireframes are built. They will cover every screen and flow.

By visualising the solution in detail at the wireframing stage we were able to gain a lot of clarity on gaps in our understanding of the problem. And because this comes during wireframing, we are able to react and modify based on new learnings much quicker than before.

Throughout this process, there is an ongoing discussion with Product Manager and engineering lead after each milestone. Eg. Milestone 1: Completed user flows M2: Completed 1st draft of wireframes M3: Incorporated feedback into wireframes M4: Complete 1st draft of visual design M5: Incorporated feedback into visual design

The process still has a lot of gaps that I am trying to fix. I will try and post more updates when I learn more.