Breaking down the end user’s mental journey
As product designers, it’s easy to get lost in the nuances of the product, its system and its features. As the number and the interdependencies of the said features increase, so does the complexity that the first-time user (or returning user, depending on what version you’re shipping) has to grapple with. For the designer, this is a critical ‘engagement-level’ layer of complexity that must be handled, and handled well. It sets the tone for the product, and forms the backbone of the user’s mental model of product operation. The encoding of this layer will determine the success of the user in achieving his or her goal, and consequently, the success of the product.
Encoding this layer and establishing an easily consumable mental model for the user is one of the most challenging tasks that a team of designers can face. To tackle this, we use personas and scenarios. The personas and scenarios are fantastic at illustrating different user journeys, and can be used successfully enough to vet a product. The basis for personas and scenarios are assumptions. We gather all our insights and pour them into personas, and based on assumptions, we start to design. Assumption mapping brings back these assumptions, and explodes them over each feature and each action. It breaks down the product not from the perspective of a specific persona, but the real person who could be represented by the persona. Done a little later into your product design process, attacking a product plan with assumptions can accost it towards a complete poka-yoke. And to achieve this, assumption mapping is a great guiding tool in your arsenal of design-mapping tools.
A few weeks ago, my team had a ‘ready, set, go’ plan for our SaaS project. We were excited to have a whole list of features that would alleviate the user’s experience, making it delightfully crafted and magically personalized. We also knew that it wouldn’t be feasible to have everything ready-set-go for our beta launch, so we decided to prioritize and map. And the end process is what we coined, Assumption Mapping. It’s a simple four-step process that takes anywhere between half an hour to half a day, depending on the complexity of your product, but it’s bound to decipher critical aspects of the engagement layer in your MVP.
I’ve described this tool that I found so incredibly useful in a loose and open manner, bearing in mind that developing this tool itself is a work in progress. I hope that you find it a useful addition to your design thinking kit. Here’s how it goes:
What you need:
- Your entire design team (throw engineering, quasi-engineering, quasi-design, strategy and all the in-betweens into the mix as well). The more minds working on this, the better.
- Post-its. Lots and lots of them, with as many colors as possible. Definitely get the tomato-red ones (or single out a color that won’t be used till Step 3).
- A whiteboard that can handle post-its.
- Whiteboard markers and sharpies.
- A goal — define what it is that you want your product to achieve, and what you expect from this exercise. Put it on the top of the whiteboard, nice and big. Your goal will be your enabler, and your constraint. Never start without this.
Step 1: The Incredible List
Think of this as the KonMari medicine to Norman’s featuritis. Start with creating a list of all the possible features that are available to the user and the corresponding actions. Note that this should be done completely disregarding feasibility and timelines, only keeping in mind the number of routes that the user might want to take to get to his or her goal using your product. Put each item on a post-it:
Next, group all the features and actions using a sensible grouping system, preferably one that you’ve been using up to this point in your product design process. Ideally nest actions under features, and put them up on your whiteboard. Arrange each feature-group vertically on your white board.
This has two purposes — the first is to ensure that your entire team in on the same page with respect to the product system. Second, seeing the features and actions will also point to any gaping holes and wrinkles in the system — but hopefully, you won’t have any. At this stage, try filling in the blanks. This way, you’ll have a clear picture of where you currently stand, and will be able to progress forward nice and easy.
Step 2: Horses and Engines
Now that you can see all your features and the corresponding actions on a single plane, it’s time to spread each feature group across a three column-continuum : basic, intermediate and advanced. As the labels suggest, basic covers the basic features and actions that you want your users to be able to perform. Intermediate covers features and actions that require a deeper understanding and more specialized use cases. These are the nice-to-haves for your basic user group. Advanced covers all the power-user features, which act as the nice-to-have for your intermediate user group. Note that these are not three distinct columns, but rather fuzzy columns that features can slide or spread across, based on the nature of the actions. Retain the grouping as much as possible.
Step 3: The tomato-red post-it notes.
Bring out the lovelies and keep your sharpies in hand.
By now you should have groups of post-its, spread into rows of what resemble three columns, covering your entire product system. Start at the ‘basic’ column. Carefully consider each group of actions, and on the red post-it, write down each and every bit of information the user may need to know in order to use this group of actions, however trivial. For instance, to re-size an image, the user will need to know the availability of the feature (it’s tucked under this menu), the size that they need to or are going to resize to, the use of the image, and the possible impact on the resolution. Between these four assumptions, you’ve covered the first-time user and the power user. Try to do this for each group of actions and features, considering each post-it on your whiteboard carefully. Critically evaluate the user experience of each of these actions from three contextualizing perspectives- first as an individual, stand-alone action, secondly as a part of a feature and finally, within the context of your entire product experience.
Highlight any dependencies that an assumption may have on another feature group or action, connecting the two with your white board. You may find that some features have variations of themselves under different columns. For instance, resizing the dimensions of an image while maintaining the aspect ratio may be an intermediate feature-action nested in the resize group, but changing the resolution of an image may occur as an advanced feature-action in the same group.
Do this enough and you should start to see patterns forming. ‘Spinal features’ support several other features, ‘Assumed features’ have little to no assumptions or are very obvious to the user, ‘Neuron features’ bear impact on other features, and ‘Deep Features’ require a deep understanding of the subject matter- features that are likely to be used by a power user for enhanced control. ‘Core features’ are those that drive value in the product — your USP. I’ve only just outlined a few of the kind of features, but you may find more (or less) in your assumption map based on what your project is.
Step 4: Refactor and Design
Now that you have a nice big assumption map, you can not only prioritize what features to include in your MVP (we picked those that had a tendency to be Basic, Core, and Assumed), you can also refactor your features. Move them around, re-group, re-classify, or even remove them if you find redundancies.
But here’s the icing on the cake, your last and final (but recursive) step — design for the assumptions. Now that your assumptions are visible, they can guide you in defining the layers of engagement and depth in your product. Assumption maps can identify areas where you can simplify your on-boarding experience or re-introduce it. They highlight areas where the learning curve may be steep, but simultaneously show opportunities for softening it.
Each assumption should point towards what could be considered critical knowledge that the user must possess in order to execute a task. Now, connect each assumption to the point in your feature-group map that will contribute to converting it into a surety, or a known fact. If you’re left with a handful of disconnected assumptions, you know that you’re expecting a fair level of precursory knowledge from your user group.
If these have to do with assumed features, you may be in the clear; but if they have to do with core features or deep features, you may want to revisit your FAQs or your on-boarding so you know that your users won’t be left confused or in the dark. You may be lenient if your target group are prosumers or experts, but if you are trying to introduce a new product that doesn’t currently exist out there, you might want to be stringent about prior knowledge.
Overall, you’ll have a fresh lens to view your features through, and hopefully you would have uncovered user-centered insights that may have previously escaped your attention. We decided to axe disconnected features in the advanced column, and instead focus on connecting core features in the intermediate column to those in the basic column. Our goal was now to ensure that the basic and intermediate features would be so explicit, that there would be no assumptions — each feature would progressively reveal function and purpose. The bottomline remains that the successful use of an assumption map remains in the abilities of your team. They have to be able to think critically, unafraid of voicing concerns, generous with feedback, and an unabashed ability to play the devil’s advocate. The more frames of mind you cover, the more assumptions you will bring to surface, and the more material you will have to design for. At the same time, there is always the chance that in doing this exercise, you create levels of added complexity or you complicate things. It is important to always start with a goal (what is it that you are trying to achieve?) and never lose sight of it. Set a time limit, and clear your calendars. And of course, try to have fun with your assumptions!
If you’ve found this useful and used this methodology, I would love to hear your experience and feedback. Please do leave a comment or a note! Thank you.