Working in a team of brilliant creatives is a double-edged sword. Sure, passion and expertise facilitate great discussions, but focusing too much on your own craft can be counter-productive. Sometimes, being a UX practitioner in a team of technology experts inspires new tools for the job.
Discussing features before design may seem like a problem solely afforded to clients but we, fellow creative types, are not immune. We get excited by making a solution happen and, before we know it, an interface is born.
This was certainly true on my product team. When it came to discussing the user experience, we were often confronted by the technical details and the interface itself. Sometimes we’d forget that a screen’s layout wasn’t willed by the gods. We’d argue about where to move this button or how to redesign that popover – instead of going back to the screen’s purpose. It soon became clear that we needed a solid overview of what we were trying to offer the user, especially before diving into the details.
A bird’s eye view
Getting stuck in the details is dangerous. It’s also easy. The usual design suspects – wireframes, site maps, prototypes, etc – provide teams with conversation pieces, but they also limit the scope of our design considerations. In order to facilitate the right kinds of ideas in a collaborative design environment, we primarily need an overview of the tasks that design supports.
Mind maps aid visual thinking.
Enter mind maps. More commonly used for brainstorming, list-making, summarizing a topic or learning new information, mind maps enable association-based thinking in a non-linear way.
My team uses them to depict every user task an application supports. They shift the focus from where the user should “go” to what that user is trying to do. They remind us to think in stories and narratives, not features. Additionally, they’re flexible: If the implementation details change, our mind maps change along with them.
Mind the map
While most people on a team focus on a single aspect of the project, mind maps bring us all together. They visualize the project’s progress and demonstrate how usable a project is in its current state. They are also useful for every phase of a project: from planning and testing to development and quality assurance.
Here are some other great things about mind maps:
- They help prioritize features. Kurt Vonnegut once said that every line in a story should advance the storyline or reveal character. Similarly, everything we add to a website or application should build upon the existing story. Mind Maps help us visually assess new ideas and prioritize them based on their relevance.
- They aid in usability test planning. When it’s time to test with real users, branches of a mind map can serve as self-contained test plans. Simply pick a few branches, write a test scenario around them, and you’re ready to test.
- They quickly show us what we’ve tested. Along the same lines, mind maps help to get a visual indication of our automated testing coverage by pairing branches on the map with the names of feature files that exist in our automated testing system.
- They keep the focus on the end user. Instead of focusing on “this screen” or “that page,” mind maps encourage stories: Whether or not a user can “upload photos,” “register with a new account,” or “learn more about someone.” Since the map is focused on tasks, it becomes a makeshift user proxy.
- They ensure we plan for things that don’t go as planned. Part of planning a user experience is considering what happens outside of the best-case scenario. Our team uses mind maps to plan where to write helpful copy for errors and see what alternative routes we are missing. It’s also a great reminder to include a way out for the user – include a “cancel” option on relevant branches to allow the user to undo at any point.
- They give QA a snapshot of the whole system. Finally, mind maps help our QA team understand the system more quickly and consider significant edge cases. It can also be used in exploratory quality assurance testing to create a quick overview of the system, discuss risks or changes, and display test coverage.
After hearing so much about how useful mind maps have been for us, you’re probably itching to try them yourself. You’re in luck.
Roll your own
Let’s pretend we are making a mind map for a dating app, MyDates. If you’ve never created a mind map before, there are plenty of great tutorials that will guide you through the basics.
We will use our mind map to make an association-based inventory of all the functions that live within MyDates. In practice, you can start from an existing product and work backwards, or introduce mind maps in the planning stages.
MyDates allows someone to create a profile with their information, and find matches by looking up other registered users. The following example was made with Mind Node, which is a Mac and iPad app with free and paid versions.
Begin by listing high-level tasks. First, add branches for every big task the app supports.
This can be a difficult step if this is the first time you’ve had to group functionality clusters into themes. I find it helpful to pretend I’m trying convince a close friend to use the app. Instead of a marketing pitch where I’d focus on flashy features, I’d want to tell my friend what the app would add to their lives.
Remember to use verbs. The most obvious things MyDates allows someone to do are:
- Set up a profile,
- Manage a profile, and
- Browse other profiles for possible matches.
Start the sentence “as a user, I can [verb]…” In this case, “manage my profile” and “find matches.” These are the two, most obvious, high-level tasks. Using verbs means we’re focusing on actions and not on location.
Next, expand each branch. Focus on each branch and expand it to include everything the app can do for the user within that realm of functionality. It’s all about sorting functions into the appropriate branch. Uploading a photo and deleting my profile go under the managing a profile branch, learning more about other users and viewing recently visited matches goe under “find matches.”
Focus on needs, not features. Instead of writing “browse someone’s profile,” go for “learn more about someone.” The desire to learn more about potential matches is relevant, regardless to where that information is displayed. Don’t be shy about using working titles and renaming nodes as you go. Perhaps “manage my profile” should be changed to “share information about myself.” When I send a copy of the map to others, I’m always sure to include a date. That way the recipient knows my map is a work in progress.
Only include what’s already there. Include only tasks already supported by the product, or those in design or development. As the app grows bigger, use dotted lines for tasks that haven’t been fully implemented. This isn’t the place to keep track of suggestions or ideas, although you can certainly make another mind map to do just that.
Do a final run-through. When I begin a map, I often get caught up in the most central features and forget basic tasks like logging in or creating an account. When I think I’m done with a map, I do a mental run-through of an app as if I am trying to use it. This helps me see if there’s anything missing. Remember to ask yourself: “how did I get here?”
Show the way
Don’t wait for someone on your team to ask to see your mind map. Make sure everyone working on the project has seen it and can get a hold of it without asking you. The easiest way to start is introducing new team members to the project. Don’t be afraid to be blunt. Highlight all the central things the app can do by reviewing the first-level nodes.
Don’t forget to make your map visible. If you’ve made a map in the middle of an existing project, pull it out during project discussions and leave it on the table. I have gone as far as putting up a mind map on the wall near my desk. When someone comes to ask a question about the project, I point to it casually when answering their question. Before I knew it, colleagues were asking about it.
For us, mind maps became part of the routine because they filled a gap in our communication. Pull out your mind map when someone needs to refresh their memory, see what’s been tested, or decide where the next usability test might focus. User experience is a joint effort. Bring it with you to client meetings. Showing something you’ve worked on to make communication easier never hurts and might even impress your client.
Getting your team to worry about user experience takes time and thought. A good way to spend your time is to remind everyone about the bigger picture: who the product is for and what it helps them to achieve. Mind maps are an excellent low-maintenance way to do just that.