Many years ago I was designing a website and was given a set of design guidelines that were quite interesting, shall we say. I think they were going for a Zen-like approach, in that it was a style without style, they used Arial everywhere and blue was their primary colour; it was painful to look at. I was tasked with designing the flow and UI.
During one of the presentations, I was asked by the PM if I could “add a bit more design” to the interface. This upset me quite a bit; it was as if design was being treated a bit like chocolate sprinkles, you add some on top. This approach to design happens when we are handed a brief and asked to create the outcome rather than look at the whole problem.
A different approach would be Scenario Based design, where you take a step back and look at the whole challenge. It starts by looking at the design brief and figuring out the scenario that fits it. For example, you are asked to redesign the look and feel of an e-commerce site, the first thing you would do is take a scenario where a user would go through the flow of buying a pair of jeans and look at all of the steps that lead a person there and the potential outcomes.
What you are looking for is known as the Golden Path, a critical set of steps a user takes to find something valuable to them. We start to map out these scenarios, listing possible paths for each type of user. From here you can see which ones would be your primary goals and prioritize accordingly.
In practice, it means starting with the first step in the experience, then adding each level until the task is complete, with a description of each step along the way.
Once you have a clear understanding of the problem, you can start proposing ways to fix it rather than focusing on adding a bit of design to the UI. This allows the designer to challenge the brief making sure to fix the correct problem. It also lets the group ask questions, as this process is excellent for finding gaps in knowledge too.
From here, you can start building a paper prototype testing out a flow to see if it breaks away from your golden journey and helps call out the desire to focus on visual design details, as this could break the flow. First, you build up a storyboard of each step in the flow, in very basic wireframe mockups.
Next, you sit down with a user, while someone on your team pretends to be the ‘computer,’ and the other is the interviewer. You set the user up with what you are testing, then get them to use the flow and observe how they do.
I ran through this technique at a design sprint for Delivery Hero, an internal food delivery company based in Berlin. We had two days to create a mock-up that we would test with real users. On the first day, we generated ideas based on their scenario and mocked up these paper prototypes. Right away the teams realized some of their focus was in the wrong space; one, in particular was trying to test a scenario that involves buying food for kids. In running through this simple test, they saw that this scenario was way more complicated than they intended it to be and were able to pivot and focus their final high fidelity prototype to be more focused on solving a critical problem; getting users through complicated and convoluted restaurant menu pages.
Scenario-based design lets you take a problem at its root and focus on creating a user-centric solution, and it is rewarding when you see the positive results. It can be hard when you are working in a machine, but as my colleague Paul Lewis often says when working on a project, he likes to do “one for ‘the man’ and one for ‘the soul’”. Because as designers this is the fix we crave, doing good work, and if we can inform the industry that our job isn’t just about slapping on some design at the end, then we can do a lot for our industry’s soul as well.
NotesThis article is for a new youtube series called “Designer Vs Developer”, which you can see here on our Youtube Chrome Channel. You can also listen to a longer version of the conversation by downloading or subscribing to our podcast.
First appeared in Creative Review.