Stuck in the Details? Mind Map User Tasks

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.

An example mind map

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.

Further resources

About the Author

Evgenia (Jenny) Grinblo

Evgenia (Jenny) Grinblo is a user experience practitioner at London-based mobile agency, Future Workshops. A native Russian-Israeli, she approaches her practice with a sociological mind and a passion for facilitating team work. When away from her iMac, she is a foosball apprentice and an occasional speaker on empathy in design.

Write for UX Booth

Contribute to UX Booth
Contribute

Contribute a guest post to UX Booth and let the community know what's important to you!



Comments

  1. Great article! :)

    I’ve used Mindnode several times over the last year or so – I find it works best for getting initial thoughts down very quickly, and then lets you work collaboratively to shift elements around and define a structure.

    I also find it’s better than sitemaps when defining no-linear tasks, the only down side being that clients still tend to understand the traditional hierarchical site map without guidance, where as a mindmap can require a bit more of a walk-through.

  2. Hi Barry. Thank you!

    I have found mind maps useful earlier in the project even before you have your information architecture or UI done. At that stage, it’s not really about where things might go in the interface or the structure but more about which things the user will need to achieve with that system.

    Yes, explaining it to clients who are used to working with a different tool can be tricky. I find that explaining things to clients or guiding them through how things might work is a big portion of my job as it is. It’s worth in this case because it gives you more flexibility than a mind map or a wireframe would and buys you time talking about what the system should help the user with before you’re ready to discuss the how.

    Thanks for reading and commenting!

  3. Jenny – great article and a nice clear intro, or reminder for some, on just how helpful mindmaps can be in UX.

    I think mindmaps are really helpful to capture the context within which a story takes place (the visual hierarchy is fairly clear). It’s also interesting to hear how you’re using them across the team.

    Perhaps they’re not so great for managing common tasks that occur repeatedly in multiple contexts. But if you’re aware of this it can be worked around.

  4. I had to laugh when I read the “verbs to remember”, I have started on a new project and literally find myself saying absolute rubbish to the back-end devs and then trying to explain flow charts rather than creating an easy map. Thank-you for reminding me to remind myself!

  5. Jenny, this is a really nice and explained article! Well pointed about how powerful mindmaps are. Usually people tend to be out of focus when discussing solutions and your approach really brings this essential point: “Focus on needs, not features”. I’ll be sharing this!

    • Hi Gustavo. Thanks for reading and the lovely comment! It’s true – being a bit out of focus and getting excited in a disorderly way is quite common. I’ve definitely come across this in my work, which is why I found mind maps useful. Plus, the orderly, diagram look tends to work well for more UX-resistant tech minds ;)

  6. Jenny, this was a great article, and came at a perfect time for me. I used this in a brainstorming session with faculty members at the University where I work. I’ve done mind mapping in other contexts, but I’d never thought to apply it to the concept of mapping user tasks! One issue, though.. the Kurt Vonnegut link goes to the iPad Frank resource… I’d love to read the thing you linked to from Vonnegut, though!

    • I really appreciate your comment! It’s great to hear that you were able to put this into practice. I’d love to hear more or see an example of the map you made, if you don’t mind sharing.

      As for the Kurt Vonnegut link – it was meant to link to a collection of his quotes. Something to the effect of: http://lifehacker.com/5687349/kurt-vonneguts-tips-for-writing-fiction. I love his determination in trying to make fiction focused and relevant, like: “Write to please just one person.” I think he’d be in UX if he weren’t a writer ;)

Related Posts