DoGo mapping in the UX planning process
I believe that process is meant to change and is a fluid concept that should adapt to every client and every product. When values, principles, and purpose are upheld the steps along the way matter less. With this in mind, I’m always looking for ways to improve the path we take with our clients.
In my UX planning role there are several activities that follow the research initiatives we undertake on any given project. These activities are aimed at transitioning from our understanding of what we should do to how we should do it. On a recent project I’ve implemented a new approach to help bridge this gap.
The lean approach we use assumes that the product is not yet well defined and is almost certain to change. While effective for a general, high-level view of a system and its screens, an information architecture scheme lacks the details to indicate where features should be added and removed and how that affects the overall website or application.
After reading this UX Magazine article by Rob Keefer I took an afternoon and worked through a mapping session with an active project that was in the perfect place. I learned a few things, but first, here’s a summary of DoGo mapping:
Each node in a DoGo map represents a screen or view in an application or website. In my case, I used a large yellow post-it note for each node. On each node is the following information:
- Name: the name of the screen or page
- Reference Number: quick reference for a node (instead of relying on screen names)
- Fields: important form fields
- Do: actions for the screen
- Go: neighbours, or where you can go from this node
Lines drawn between each node connect them and eventually create a pattern where important screens (or nodes) are evidenced by the number of lines going to them.
I made a few changes to the mapping process as I put it into practice:
I created a common node to capture elements I expected to find on every screen. This included things like a search function and global navigation systems. The common node helped me consider everything a user would encounter on a screen without having to replicate it several times.
Actions and content
I expanded the ‘Do’ component to include content types in the context of ‘seeing this type of content is something I can do on this node.’ This wouldn’t be necessary for an application with more actions and less content but the project I was applying this to is content rich.
I used layers of colour-coded post-it notes to create the nodes and the information on them. I found this to be useful as I moved things around, came back to the map after a few days, and worked through it with team members. The pile of discarded post-it notes on my desk was an indication of the changes I made as the direction became clearer.
Using colour-coded post-it notes also allowed me to quickly recognizes screen where cognitive overload was likely to occur. Too many pink notes alerted me to areas where I was likely asking too much of the user or requiring an unreasonable amount of mental bandwidth to perform key tasks.
I found starting with a DoGo map to be incredibly helpful, particularly for deciding what to include as we moved to wireframes and in making content and feature recommendations. The exercise is very foundational and is something I’ll be using again on both content-heavy web projects and feature-driven applications.