My favourite part of designing a user interface (UI) is sketching it with pen and paper.
In this post, I tell about a systematic way to create UI sketches.
This technique is part of Goal-Derived Design (GDD)*, a UI design method developed at University of Helsinki by Sari A. Laakso among others. I first learned of it in an event at Reaktor about 9 years ago. For some reason, it doesn’t seem to be that well-known among user experience (UX) designers despite its many benefits.
*) Not to be confused with Goal-Directed Design developed at Cooper.
Draw only what’s needed
The principle is simple: you start with a concrete scenario, and draw only what’s needed in that scenario, when it’s needed. Nothing else. The scenario must include a user goal, and you must know what the user does and doesn’t know.
A design drawn this way will:
- offer the shortest possible path to the intended result
- cause interaction to flow in the conventional reading order (left to right, top to bottom)
- require little or no navigation
- contain all the information the user needs to reach the goal
- not ask for input that isn’t needed
- not ask questions users are unable to answer
- contain no unnecessary features – only those required by the scenario.
I’ll show how it works in a bit. But before you start drawing, you need something to fuel the design work (besides your favourite beverage): goals.
First things first: what’s the goal?
When sketching, you’ll be working from a set of goal-based use cases.
What’s a goal-based use case? That’s a big topic in itself, but let’s make it clear we’re not talking about just any old use cases. In fact, I called them “scenarios” above, as goal-based use cases have more in common with scenarios than with most use case descriptions.
Many use cases specify user tasks, specific steps and system behavior. Not here. A goal-based use case does contain detail, but only about the problem the user is facing – not the solution.
Each use case defines a realistic situation, and should include:
- The user’s goal (“Anna files a reimbursement claim after her business trip to Tampere”)
- What the user knows (“left home at 6:55 and got back at 18:10”, etc.)
- What the user doesn’t know (“full-day allowance requires a trip length of at least 10 hours”, etc.)
- Activation time: The point where the user first began taking action towards the goal (“Anna just got home from the trip”)
So, our use cases are concrete and specific about the user’s existing and missing knowledge, but don’t define how to reach the goal (only what the goal is). In other words, they define the problem.
The solution is defined by drawing, as we’ll see next. Armed with the goal-based use cases, you’re ready to start.
How to draw logically
Take a large sheet of paper (A3 is good), and read the first use case. (We’ll use the example briefly outlined above, where Anna is reporting her business trip to get reimbursed.)
Put yourself in the user’s shoes. Picture the situation at the point of use case activation. Become Anna. You have just returned from the trip. What are you trying to do? What information do you need first?
Holding that image in your mind, become yourself (= the designer) again. What would be optimal for Anna to do first? Draw the first thing she needs in the top left corner of the page. It can be relevant information the system can show, or a way for Anna to give input about what she needs. Choose the control that lets her provide this input with the least effort possible. (Check the use case to make sure she actually knows what to enter!) Perhaps a heading “Get travel reimbursement” and two text inputs labeled “Left home at” and “Got back at”.
Become Anna again. There’s now a simple UI for getting your travel reimbursement. (Gee, it’s just what you needed! Nice!) Now use it to input the times. Draw this input into the picture.
Back to designer. Anna has just given input. Now we can show results. What can the system show to Anna, given the input? Draw the results either underneath or to the right of the input. Perhaps something like “Trip duration 11 h 15 min => Full-day allowance (39 €)”.
And so on. Repeat until the goal is achieved. Don’t worry about how everything will fit on screen – that will come later. If you reach the edge of the page, extend it with another sheet (transparent or double-sided tape is handy).
Build, test, repeat
Now you have a UI. Next, take another use case, and become the user of that use case. See if you can you run through it with the UI you already have, just by entering different input. You might – but more likely the new use case requires at least some information or functions not yet present in the picture. Perhaps it’s a variant of the first use case, where the trip was two days ago instead of today, and you just need to add a date picker. Or perhaps the goal is entirely different, and requires adding several new controls.
Edit the changes into the same picture. Whenever your sketch becomes too messy, you can redraw a cleaned-up version. But don’t make it too pretty! You’ll want to be able to mess up the new one, too.
After you finish the second use case, take the first one again, and become Anna once more. Can you still complete the first use case after the edits caused by the second one? If not, fix as you see fit, and then re-simulate both use cases again. Repeat until they both work. Then add in the next use case. And so on.
By now, you’ve created an early version of the UI. You refined it iteratively, one use case at a time. Using goal-based use cases as test cases, you routinely tested it by simulating actual use.
Tip: While you can do all this just fine by yourself, it can be useful (and fun) to work together with another designer, taking turns holding the pen. This can make it easier to stay focused. It may also improve your thinking as you verbalise it to your colleague.
When to do it?
So where in the design and development lifecycle does this fit in?
In short: pretty early. As you sketch the UI, you actually define what the system can do, and what functions it has. Therefore, drawing needs to happen before those things are set in stone.
You still need those use cases first, though. You can get them by watching users do their job, or by talking to them in their natural habitat and asking them to show how they do their job (user observation and contextual interviews, if you speak UX jargon). And to do that, you must know who your users are, and what is the general problem they currently have.
So, sketching happens after you figure out the overall business problem and dig into the details by visiting users, but before requirements are defined. In fact, much of the requirement definition gets replaced by the sketching.
At this point, you have a UI. If you’re really extreme, you can already start coding and make something. But even if you only have it on paper, you now have something to show, test, discuss and learn from. Learn more about requirements, about user goals, and about what solutions work (or don’t work) for your audience.
This approach benefits the entire team by directing everyone’s attention to concrete situations users face, rather than features. It also helps pinpoint missing information and functions.
You can use this method with an entirely new product or service, or for adding new functionality into an existing one.
I think the best use for this method would be in extremely lean development, when you are still defining what you’ll be building, and your aim is to learn what works for your customers as fast as possible.
If, on the other hand, you are dealing with something big and complicated that “solves all problems for everyone”, you may already have too many things locked in. You can still use this method, but you won’t get the maximum benefit from letting the UI drive the selection of functionality. (Still, once you break that big monolith down to smaller pieces, you might find areas that are more flexible.)
Thanks for reading! If you have encountered other systematic techniques for drawing a UI, be sure to leave a comment – I’d love to read about it.