This content originally appeared on Level Up Coding - Medium and was authored by H Locke
How the design process can reduce development risk
A while back I read an awesome article by Matt Stephens on Level Up Coding about the challenges encountered in sprints when a user story generates a number of additional (unanswered) questions, reducing dev teams’ ability to accurately estimate effort and resulting in v-shaped burn patterns.
Why? Because there wasn’t any upfront work on the unhappy paths.
The solution proposed in that article was for devs and BAs to work on unhappy paths at the beginning of each sprint.
This will certainly fix the problem as it appears in the sprint, but it doesn’t have to be solely the dev team’s responsibility. Just because the devs are the last team to touch a product, doesn’t mean they’re responsible for fixing a rushed or ill-thought-through design process.
Just because the devs are the last team to touch a product, doesn’t mean they’re responsible for fixing your ill-thought-through designs.
Here’s an example of how the UX and design process can also mitigate these issues, and support dev team effort, by thinking about business and user unhappy paths upfront — specifically during the information architecture phase of your project — which is something that rarely gets through through when there’s so much excitement about Designing A New Thing.
In short, here’s a way for the design team to help the dev team, long before an interface is even conceived of. Whether you’re sprinting or not.
What is an unhappy path?
I have seen so many failing projects where a team has created screen after screen of idealistic, super-smooth user journeys and success states and don’t understand why a product failed either at launch or in beta testing.
A happy path of success states might look like this:
What the team have not designed here is for any error states, alternative or recovery journeys. Examples of this are sign up/in error, password reset, system errors and response codes.
An unhappy path, when built into the main IA work might look something like this:
As you’re probably already thinking — this could get very complicated, very quickly. And you’d be right. However, you’re not going to map every single back end error state in the UX work — you’re just making a start on the key paths that effect user task completion.
You’re just focussing on the key paths that effect user task completion
Even thinking through the front-end of a user’s reality can start aligning design work with business and systems reality, help inform the future work of the dev team and signal any impending icebergs early on.
Making unhappy paths part of the IA work
As above, the solution discussed in the article is to work with BAs and business experts to list as many unhappy paths as possible as part of the sprint or dev process.
I agree with this completely, however I’d suggest that the design team kick-start this work by carrying out the first draft of unhappy paths with business analysts and/or product owners, at the beginning of the project — as part of requirements gathering and IA phases.
By working this way on projects in our team, we have been able to provide business stakeholders and dev teams with better-thought-through journeys, and reduced burn time on build without taking away dev teams’ autonomy in solving the most complex technical and architectural problems.
If you imagine we’re on an expedition; the BAs, tech architects and dev teams are carrying out the full geological survey — but the UX team is the forward party, checking for dragons and icebergs.
An example process
This is how we worked on the redesign of a major ticketing site, during the IA definition phase of the project:
- Map out the primary proposed sitemap — Work closely with product owners, business analysts, and solutions architects, so that there is continuity for dev teams later on
- Identify the locations of key user flows — So that you know which parts of the experience (within the site map) are going to trigger which paths.
- Map the user flows’ happy paths — As many as are needed. So for this ticket site, we had event selection, ticket selection, seat selection, add to basket, sign in/up, redeem voucher, check out— all with different flows for different user types and scenarios
- For each path, map as many known or hypothesised unhappy paths — Either new flows or additional layers on #3 above (if you’re using Omnigraffle this will be easiest). This maps and identifies where additional flows, screens, or error state variants will be needed or triggered. These can then be simply flagged for the dev team to investigate later, or with additional requirements and flows integrated into wireframes, prototypes, UI or interaction specification
- Audit current and competitor sites — When you think you have exhausted the obvious unhappy paths, look for other live examples by playing with (i.e. trying to break) competitor and comparator sites. This allows you to sense-check any additional paths with business stakeholders and product owners and validate if they are also applicable to your product
- Test and iterate — Creating prototypes of the flows and key error states help you to validate assumptions, usability, user mental models of error recovery and also find new unhappy paths you wouldn’t otherwise have discovered. Deliberately user testing unhappy paths literally lets you stress test your experience
- Update flows and annotate — As part of your dev hand off or ongoing conversations and sprint planning, make sure that dev teams know which flows have been tested and validated and where there are still unanswered questions or possible back end implications.
Of course this approach didn’t get us all the unhappy paths; many of them still emerged later at the beginning of design and build sprints or from stakeholders who hadn’t manifested during the early stage of the project, or from new functionality being added in — however it got everyone talking about unhappy paths early on which meant no sudden complete surprises later on.
Any other benefits?
Apart from ensuring that unhappy paths are not the sole responsibility of dev teams, (when they could be focusing on the most interesting and complex challenges) this approach also has some benefits to the design and stakeholder teams, as well as overall product outcomes:
- Know your iceberg — Leaning into the unhappy paths early on helps you start to reach for the edges of your project’s complexity. Again, it doesn’t mean you have to deal with the whole of the back end architecture during the design stage, but it really helps to know how big and complex the thing might become, and where the major traps are for users
- Scoping for sprints — When you start to list out unhappy paths you can highlight them to your product owner, and decide which will be critical to MVP, sprints or iterations. This then shows how much work is needed from UX and UI teams, what needs to be tested with users, and what size of additional architectural or investigative work will be coming down the pipe to dev teams.
- Aligns teams and increases continuity — One of the most useful things UX people can do is connect stakeholders, design, BA and dev teams. In many scenarios dev teams may not want to hear about the product until the requirements are finalised but this is often too late to be able to manage stakeholder expectations on actual delivery. Involving at least BAs and tech architects in the upfront design process means that those same people can work both with UX teams on the IA phase (user journeys, key paths — happy, unhappy or otherwise), and with dev teams on the technical architecture and delivery.
Why don’t unhappy paths always get designed upfront?
Having outlined the above, you may be thinking — why would anyone skip this bit? And, if you’re anything like me, by now you’ve realised that identifying all the things that can go wrong in a journey that need to be designed for is both what’s right for users and what’s better UX outcomes… and also a lot of fun!
Well, unhappy paths get excluded from UX scope for many of the same reasons that other short cuts happen in the UX and design process; because they require work which takes time and requires brain power:
- There is pressure to reduce scope, time and costs
- The design team are under pressure to produce <something> no matter how superficial or ill-thought-through
- There is a lack of interest in anything other than the happy path solution
- The happy path is the easiest thing to “solve” and so teams and stakeholders can convince themselves they’ve achieved something with minimal effort
- Senior stakeholders just want to see something that “works” or are bored by any kind of detail or problem
- The teams that know, understand or will have to deal with the implications of unhappy paths have been excluded from the design process.
Balancing the happy and the unhappy
So how do we keep feeding stakeholders Happy Things while we’re down the unhappy mines? Well basically one can twin-track creative design and UX.
This is what it looks like in terms of running the twin-track on a project where you are creating a new look-and-feel from scratch (i.e. not working from an existing design system):
- UX team complete the first round of IA including any sitemaps, primary (happy path) user flows and then wireframes. As above, working closely with BA and/or Product Owner
- UX team test and iterate IA and/or wireframes as clickable prototypes
- Creative exploration essentially happens agnostically of final UX, except that there is an initial “holding place” wireframe, such as an example homepage
- Once the look-and-feel is agreed, the UI team can focus on the happy path production when working towards initial creative sign off
- In parallel, the UX team return to the land of boxes-and-arrows where iteration is cheaper than in UI and solve further unhappy paths at an architecture level (boxes and arrows) and where necessary, wireframes and greyscale prototypes — still working closely with architects and BAs, possibly bringing in some other specialist technical teams
- As unhappy path work is agreed and signed off, any additional screens or more likely components or component states can then be fed into the UI / pattern library backlog as needed.
Again, this is iceberg work. You are allowing the creative and visual design process to continue, whilst solving the difficult architectural and UX problems in the background.
You are also allowing those more interested in the happy creative execution to get what they want, ensuring stakeholders remain bought in, whilst reducing pain further down the tracks for everyone else.
And finally you are keeping UX and UI somewhat separate because sometimes, they just are two different jobs. Because #ItDepends.
Some watch outs
If you’re going to attempt to lean into the unhappy paths involved in your new user experience, well done!
Now, here are some tips to make sure it helps you and everyone around you:
- Involve dev teams early in the process — even when they don’t want to be. Or at least the solutions architects or BAs they will end up working with the estimate sprint effort. You want to avoid surprises
- Communicate the IA work — not just UI screens. Work out business and user flows early on, and expose them to the technical architecture teams at a minimum. You want to build understanding
- Do not be afraid of complexity — as a UX person you can absolutely get more involved in the technical reality of and implications for the product, support without taking full ownership of the iceberg. You don’t need to solve everything, but increasing your understanding will have better product outcomes
- Don’t lose sight of what the BA and TA team are doing — It’s easy to do a bit of UX work and throw it over the fence. Once business analysts are working with dev teams to implement your designs, ensure you are available for check ins and understand ongoing decisions that are being made that may result in design changes. You want a feedback loop so that final design is not at risk
- Know your limits — You can facilitate understanding of unhappy paths without being responsible for all of it. You don’t want to take on the full architecture role yourself. You want to focus on the things that will have the greatest impact on the interface.
As always, this is just an example of one approach to mitigating design risk and may not work in your specific situation, but it is particularly useful when you are creating something potentially complex from scratch and have stakeholders on one side wanting Things at speed, and technical teams on the other pointing out that Things are complicated and time-consuming.
These kinds of projects can be helped enormously with that elite UX skill combination of part ‘thinking things through properly’ and part ‘group therapist’.
Designing for unhappy paths was originally published in Level Up Coding on Medium, where people are continuing the conversation by highlighting and responding to this story.
This content originally appeared on Level Up Coding - Medium and was authored by H Locke
H Locke | Sciencx (2021-08-19T14:26:50+00:00) Designing for unhappy paths. Retrieved from https://www.scien.cx/2021/08/19/designing-for-unhappy-paths/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.