Draw Diagrams of User Activities Before You Start “Designing”
I wrote a post for boxes and arrows (almost 10 years ago … ) that presents a detailed breakdown of the role between cognitive states and actions states, with preferred mental models, and actual models — go read it if you are up for a philosophical discussion of human-computer interaction. Otherwise, what follows is a simple method for diagramming user activities and why you should do it.
Some Key Concepts
- Behavior patterns: the observable relationship between what users think and what they do
- User Flow: the sequence of actions that add up to an activity
- Diagraming: drawing a sequence of actions (i.e. what the user will do, click-on, etc.) based on what they see (in terms of interface features)
- Activity Map: A final diagram presented start to finish for a full activity (or set of linked activities)
Diagramming a desired user activity in terms of an interface design is a great brainstorming tool. You’ll find yourself interrogating the diagrams, vetting assumptions, getting clarity/agreement from your team, and spotting potential complexities/issues/etc. Many teams, however, don’t diagram their ideas out. There are various reasons:
- diagrams feel constraining in the early stages of brainstorming, “how do you represent the cool slide out menu in a diagram?”
- diagrams are way too specific for early stage design, “how do we even know it’s going to be a button vs. something else?”
- diagrams quickly become too difficult to read/present
- basing UI/visual design on diagrams feels like guesswork, and is awkward
- diagramming is a pedantic activity for “big thinkers” to feel like they are part of the process
- diagramming is just a step in the process you can charge more money to client for
All of the above could be true — yet all represent an inappropriate use of diagramming. Everybody on the team shows up with some idea of what they think the final product should look like, what it should do, what the best outcome should be, and what the user should do when all is complete. The problem is that we seldom articulate these ideas even to ourselves. Diagramming is how you clarify your own thinking and communicate your vision to the team.
How you start
- Break your product idea (or entire project) into activities. Here are some example activities: “draft an email and send it”, “find a particular song and save it”, “add the event to your calendar.”
- Next, propose the simple question for each activity: Can the user do X and what happens when they try?
- Then, start drawing with boxes, arrows, and labels what the activity looks like (in user actions) when the user attempts the activity.
Keep it simple, don’t delve into all the edge cases. Complexity is a time vampire. You can noodle and hem/haw for days, paralized by avoidable complexity. Some simple ways to remove complexity:
- don’t consider multiple pre conditions (e.g. “user has no saved recipies yet” vs. “user has 3 saved recipes”) just pick the most simple starting case
- leave out common, repeatable activity parts — like signing in to your account
- in multiple user activities (ex: instant messaging, curating/moderating user generated content), just view the activity from a single user perspective
- don’t diagram ‘checks’ the system does like “validate user creds” and diagram all branches from those check processes, just pick the good one.
Aim to draw out the activity in as little boxes, arrows, and labels as possible. The labels themselves should be as short as possible.
Some basic diagram techniques
A box should be a “view” or a page, like the homepage, account or settings page. The lines connecting boxes are actions. Try to represent all actions like the following examples:
Actions are atomic — keep them that way. Yet you often need to string them together in a single line, like these examples:
Use “dot boxes” to represent onscreen elements that a user interacts with. And connect arrows to the elements users are seeing based on what they have done — don’t repeat view boxes if the view doesn’t reload or otherwise change for the user.
Finally, don’t try to combine all your activities diagrams into one large map — it’s a waste of time, nobody will use it, and good designers will not be impressed by complex looking diagrams. Seriously, if somebody on your team (or some stakeholder) is impressed by a complex looking diagram — think twice about asking for their opinion and/or involving them in the design process.
Now I have some tips
- Try diagramming out non computer related activities — or even the analog equivalent of what your user activity is. You’ll find opportunities for UI improvement, and see exactly what parts of the activity are improved by your UI.
- Diagram out the mundane repetitive parts (like signing into you account, or resetting your password), and look at the number of mundane activities vs. the number of core (fun/meaningful) activities. You can also look at the number of actions for mundane activities vs. core activities. Is your system boring and tedious, or full of meaningful actions?
- Diagram out the tools/app and activities you do regularly — what commonalities exist? Is that just for users like you? How about your user/customer?
- Tag percentage numbers (next to boxes and dot boxes) that represent how many users you think will complete each step of an activity. Start with a number of users who will do it in the first place, then end up with the percent of users that will finish. Compare that assumption (or more formally, your hypothesis) against measures (or analytics) from your final design. Can you update your design to improve those numbers? Rinse and repeat.
Now that you and your team are on the same page and have a shared understanding of what you are trying to accomplish — break out your thick rimmed black glasses and commence “designing.”