Assumption Mapping
What to do when your product has too many features, no precedents and an undefined audience.
Updated: January 2019
Watch the talk starting at 3:20:00 https://youtu.be/KlgLSdCDUGc
Designing a software UX is always a challenge, especially when it is a general-purpose tool for enterprise of professional users. New features quickly get added into product systems, and as a result, the interdependencies of features and UX manifold that designers, engineers (and eventually users) must grapple with, grows exponentially. Complexity settles into a thick and dense layer, one that a lot depends on. It is critical that it be unraveled meaningfully and carefully, but it can be like trying to unravel uncooked instant ramen — chances that you will break the product system run high.
The complexity of it’s features set the tone of an application. The usability of these features builds a user’s mental model of it. And so, the complexity of an application is pivotal in determining the success with which a user achieves their goal, and as we well know, successful user = successful product. For product teams, it’s very easy to get overwhelmed and demotivated, as you get lost in the nuances of this complexity.
The hardest kinds of products to recover from, are ones that have absolutely no precedents whatsoever, or are targeted at an incredibly underserved audience. We often see this when we try to design applications and softwares for emerging and specialized industry applications, where our power users are (a) experts or near-experts in their domains and (b) have a huge appetite for any kind of domain specific tool. We also encounter this challenge when product teams work to generalize niche products that have been designed to solve very specific, local problems.
In 2016, I was a part of a team that had a hard deadline to ship a SaaS project. It was abundant with incredibly sophisticated data viz features for content marketers that we were sure would elevate their user’s experience, delivering delightfully crafted and magically personalized interactive content. At the same time, we also knew that there was absolutely no way to have everything ready for our beta launch. We needed some justifiable way of prioritizing these features, but we had nothing to go on. In a moment of desperation, assumption mapping was born. It’s January, 2019, and while I’m no longer on that team, I’ve refined and used assumption mapping to ship at least four relatively successful niche products for machine learning research. So let’s get straight to it.
Assumption mapping — what is it?
Assumption mapping is a useful method for unravelling feature complexity, prioritizing feature importance and defining target audiences from the feature set (rather than the other way around). It’s a step-by-step activity in which stakeholders get together to create an inventory of all features of a product, define ways in which users can interact with the features, map them to users’ expertise levels, and finally, exhaustively list and evaluate assumptions that can affect features. The goal of the assumption map is deceptively simple — give each feature meaning such that you can establish an easily consumable mental model for users, whom you are barely acquainted with.
This is likely the most daunting task of the UX process. Typically, we use personas and scenarios to tackle this. But in the case of a product that is emergent, personas don’t work. This could be because you either don’t have enough users, the feature set is too broad, or your product is incredible specialized. Assumption mapping is a participatory method that can help you to start tackling all three of these concerns. To get the most out of assumption mapping, you need to get together the following:
- A good sense of your entire feature set, and all possible methods of implementing this feature. We’ll get more into features and methods in just a minute.
- A prototype, a proof of concept, or medium-fidelity mock-ups that show all the features, each with at least 3–4 states in the user flow.
- As many people as you can in the product team. This includes UXR, UXD, Engineering, PMs, marketing, and ideally, some domain experts. The more the merrier
- A couple of hours blocked out. No remote participation.
- Supplies:
Post-it notes — I like at least 5 different colors + red.
White boards, markers, etc. - A product statement — 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. This statement will act as an enabler and a constraint. Never start without this.
A note on features and methods
For the sake of consistency, I’m describing features as the ability is a software or tool to enable users to achieve a significant, desirable outcome or result, through an individual interaction, or a set of interactions. A method by which a feature may be implemented refers to the set of predefined or configurable constraints that allow users to achieve significant, desirable outcomes.
For instance, changing the size of an image is a feature. Examples of methods for this feature are (a) changing image dimensions, (b) cropping the image and (c) changing image resolution. More nuanced methods would involve combinations of maintaining the aspect ratio of an image when changing image dimensions, cropping an image or changing the resolution. As you see, methods can grow exponentially, hence the distinction between features and methods.
The Assumption Mapping Mindset — what to expect
Assumption mapping requires a critical, creative and open-mindset. It requires deconstructing your application with surgical accuracy and unpacking your assumptions. Through the process of assumption mapping, teams are bound to discover a few unexpected things. Perhaps there are gaping holes in the product. Or maybe, the features are actually not that diverse — just different ways of achieving the same thing. Expect to prune and grow your product offering. Some features will become more important than others, and some might be rejected altogether. It’s best to enter this exercise with an open frame of mind. When it comes to actually defining assumptions, it pays to be creative. No assumption is trivial or insignificant. A lot of your assumptions will be uninteresting — yet they are equally important. Finally, in order to arrive at valuable and interesting insights, each participating member must be critical in thinking. As an FYI: there may be disagreements, but please don’t be a jerk to your colleagues about it.
Stage 1: The feature inventory
Think of this as the KonMari medicine to Norman’s featuritis. Systematically, we are going to make an exhaustive inventory of all features and their methods. This step is critical because first, it brings all participants on the same page. Secondly, it gives a full sense each feature and method, clarifying its need, value and context within the product system. Finally, it makes any gaps and any overlaps in your feature system evident.
Start with assigning one or two presenters, who will walk everyone through each and every mock. Presenters are responsible for calling out high-level features and describing them in detail, so it’s best that presenter be those who are most intimate with the prototype.
Together, presenters and participants generate a list of all possible features that are available to the user and the corresponding methods. Presenters are responsible for noting down high-level feature names, (one per post-it) while participants will jot down one method per post-it note for the feature they are working on. Since we don’t expect prototypes and mock-ups to describe all methods, participants will need to get creative, filling in the blanks as the group progresses from one feature to another. Completely disregard feasibility, production timeline, resources, and any such considerations. While the inventory should be as comprehensive as possible, participants should try to not create duplicates.
On the white board, leave some room on the top for a horizontal axis and some titles. Now, draw a column one post-it wide on the far left for the high-level feature names. These will become horizontal swimlanes for the features, so give some vertical space between them. Now, horizontally stack the method post-its as shown below. Don’t worry about the organization yet, we’ll get to that.
Pro tip: color code your post-its by feature, and cycle through them, as shown in the illustrations.
Now that all features and their corresponding methods are up on the board, start clustering methods using some sensible grouping system that a majority of participants agree on. Preferably stick to one that you’ve been using up to this point in your product design process. The point is to get through this fast, so avoid getting stuck on the grouping system.
Clustering is useful because (a) it will help managing the post-its, (b) some features and methods are more likely to appear together in the interface so they are better together (c ) it’s gives a sense of how all the feature can manifest in the interface. Ensure that each feature and it’s method clusters are arranged vertically on your white board. It should look like so:
You should start to see the first signs of any gaping holes and wrinkles in your product system. Take note of any blank spaces on a separate whiteboard, designated as the parking lot. This way, you’ll have a clear picture of where you currently stand, and what you may want to consider for the future.
Repeat the process of brainstorming new methods for features that fill the gaps, and cluster them till no more gaps are left. Remember to keep revisiting your product statement to stay within scope.
Pro tip
- Use a differently shaped post-it to fill in the gaps. Write the feature idea, what need it solves, and a couple of methods on the post-it.
- Alternatively, use a separate whiteboard or a large sheet as a parking lot.
- Keep referring to the sticky notes already up on the whiteboard to make sure you aren’t recreating a feature using a different description. Function over form at this point.
Stage 2: Assigning expertise
You can see all your features and the corresponding methods on the same board, draw a horizontal X-axis on top (we left space for this earlier). This will denote the expertise continuum: Basic (left), Intermediate (middle) and Advanced (right).
As a group, consider each method cluster from the perspective of expertise. Who is most likely to make the most of the given method cluster — users with little expertise or power-users? How much domain knowledge is needed to use these clusters? And finally, are the tasks supported by the method cluster basic- , intermediate- or expert-level tasks? While retaining the grouping as much as possible, move the method clusters along the axis to their most appropriate location.
- “Basic” covers the very basic features (and methods) that that you want your users to be able to perform with practically no domain expertise.
- “Intermediate” covers features and methods that require slightly more domain understanding or cater to more specialized use cases. These are the nice-to-haves for your basic or barebones UX.
- “Advanced” features and methods are the power-user features, which often require a considerable amount of domain expertise, have a steeper learning curve, and cater to highly specialized use cases. These are, in turn, the nice-to-haves for the Intermediate user experience.
You may find that some features have variations of the same method under different columns. For instance, scaling up while constraining aspect ratio is a basic feature, but scaling up while constraining aspect ratio by changing image resolution is an advanced feature.
Note that these are not three discrete buckets on your X-axis, but are rather a continuous scale. Method clusters are entities that can slide along the axis or spread across it, based on the nature of the method. Your map should look somewhat like this:
Pro tip: you may need to create duplicates methods at this stage. Do so with caution — remember, users on the right of the continuum should be able to use features to their left easily.
Stage 3: Listing assumptions
Ready the red sticky notes.
The whiteboard should have groups of post-its, spread into rows of what resemble three columns, that describe your entire product system.
Start at the ‘basic’ column, and move left-to-right. Discuss one feature at a time, carefully considering each group of methods. On the red post-it, articulate every assumption that the team is making about this method cluster. It does not matter how trivial these are. Write down every bit of information that a user may need to know in order to use this cluster of methods.
For instance, to re-size an image, the user will need to know that the feature is available, and where they might find it (it’s tucked under this menu). They will need to know the size that they are going to resize the image to, as well as the original size. They should know the units of the size — pixels, points, inches, percentages? They might also need to know the motivation to resize that image- a different use case, perhaps- and the impact of resizing on the resolution.
Repeat this for each cluster of methods, considering each post-it on your whiteboard carefully. Critically evaluate the user experience of each method from three contextualizing perspectives. The first, as an individual stand-alone method. If there were no further action possible down this path, what more assumptions could you make? What baggage and knowledge would the user arrive here with? The second context to evaluate the method, is as a part of the feature. What other methods would support this method? How do other methods in the cluster change the interpretation of a specific method? And finally, evaluate the method in the context of your entire product experience. Are you using the same implementation technique too many times? Is there a better place for the method? Can this method create conflict with a method in another feature? Use these three context lenses to come up with assumptions for each cluster of methods.
I’ve found that articulating all assumptions and seeing them with their method cluster is a good vetting process. In one instance, I had to move a method cluster from “basic” towards “intermediate”, as the assumptions were fairly sophisticated. This was further corroborated by user studies. In the final implementation, special attention was paid to onboarding users and providing documentation for that method cluster.
Pro tip: at this stage, assign one person to take notes of the discussion. It will be this person’s job to document if a particular feature needs more onboarding, or the rationale behind moving a feature to the left or the right.
Stage 4: Mapping Dependency Networks
Assuming that all participants have reached a consensus on features, methods, their position on the expertise continuum and have noted their assumptions, participants will consider the influence of each method cluster on the rest of the product system.
Using a white board marker, draw any dependencies between methods, features and assumptions. Highlight any dependencies that an assumption may have on another feature group or action. Draw out connections between features and methods that affect each other. Take special note of stand-alone method clusters — those that have no relationship with any other feature, method, or assumption.
A hierarchy or network in the features should start to emerge with enough repetitions of this process. Once all dependencies have been called out, participants should together classify features and method groups. Here are a few feature types to get you started, but feel free to create your own categories:
- ‘Spinal features and methods’ support several other features. E.g., Selecting a fill color supports the pen, paintbrush and bucket tool.
- ‘Assumed features and methods’ have little to no assumptions or are very obvious to the user. E.g., Panning tool can move an image.
- ‘Neuron features and methods’ affect other features, or allow users to ‘unlock’ another feature. E.g. Scaling down an image will scale down the font size of any block of text in that graphic.
- ‘Deep features and methods’ require a deep understanding of the subject matter- features that are likely to be used by a power user for enhanced control. E.g., editing colors using RGB level sliders & histograms.
- ‘Core features and methods’ are those that drive value in the product — your USP. Eg. converting night pictures to day picture,
Pro tip: Have the note-taker make note of features that are core, spinal and neurons. You should be able to :
- Contrast these features against your product mission
- Use this classification as a way to check if a feature is within scope
Congratulations!
You have successfully made an assumption map!
Evaluating the assumption map
To recap, your assumption map should capture the viewpoints of a variety of stakeholders. All features and corresponding methods, assumptions and dependencies should be organized along expertise and clearly visible in one go. Using the assumption map, you should be able to (a) assign a priority to features, (b) create a design brief for each feature and (c ) create profiles for basic-, intermediate- and advanced-level users.
Prioritizing features
Seeing features clearly laid out along expertise level makes it easy to see what’s essential and what isn’t. You can see the exact dependencies of each feature as you assign priority for design and launch.
We chose to include features and methods that were basic, core and assumed in our MVP. Since we excluded a lot of spinal features and methods, we had to refactor the ones we chose to keep. The team moved them around, and did some regrouping and re-classification. We found two method clusters to be redundant, and had to remove one entirely. This is where we needed to keep an open and incredibly critical mind. We also found that in order to deliver what the product promised, we needed to retain some advance-level methods. Using the dependency network, we were able to prune our feature offering for the beta release, and really hone user journeys for a few, specific advance-level methods.
Feature-level design briefs
Assumption maps are useful for describing user profiles at a feature level, and elucidate other features that one might depend on or affect. With this information, you could start to put together design briefs for each feature, “… is the kind of user who is likely to use this feature, and … is their user journey.”
Assumptions can guide teams when defining the layers and depth of engagement in products. They highlight features and methods where the learning curve is steep, and simultaneously show opportunities to soften the curve, for instance, identifying areas where the onboarding experience needs more explanation or simplification. Alternatively, specific features may need more guidance and explanations. Perhaps a performance optimization feature needs to be re-introduced at specific points in a user journey.
As discussed, each assumption should indicate critical knowledge that a user must possess to execute a task. If you can connect each assumption to a specific method that it will contribute towards, it may be worthwhile adding it to your user profile for that feature, the guidance for which can be built into the UX. If, however, there are several unconnected assumptions, the feature assumes a certain level of external, precursory knowledge from your intended user group.
Specifically, if unconnected assumptions have to do with core features or deep features, it may not be possible to design the guidance into the interaction flow. But, it may be an opportunity to revisit FAQs or documentation so that users are not confused or in the dark. One may go as far as saying that it is ok to be lenient if the target group are prosumers or experts. However, if the product introduces a brand new service or feature that doesn’t currently exist on the market in any form, being stringent about apriori knowledge may pay off.
Audience profiles
Frequently, when designing a novel product, teams have little or no user stories or user tasks to go on. In UX research, it’s considered poor practice to ask “Would you use a product that could do *insert description of product features here*?”. “Yes”, “Of course”, and “Sure” are all forms of a positive and uninteresting response. So where do we begin?
As an unintended consequence of the exercise, we have created an extensive list of assumptions about basic-, intermediate- and advanced-level users of the software or product on the red sticky notes. These can be very telling about who we are designing for, and can serve as critical material when defining target user groups. A summary of these assumptions can be used as starter audience profiles to design your prototypes for. Note that once your product is launched (even in beta), UX research should vet these profiles against real users.
In one project, a team working on a machine learning product was able to deduce its user groups on the basis of these assumptions alone, as follows:
- Basic users were students, undergraduate or self-learners, typically from a different domain expertise, or experts from a different domain that was frequently affected by ML
- Intermediate users were developers with little familiarity with Machine Learning, but typically used 3rd party libraries and off the shelf ML models
- Advanced users were typically ML researchers, folk who were comfortable implementing and experimenting with model architectures.
These profiles were corroborated by UX research after a beta release. Further, the need for a lot of the advanced features (that were lower priority for development) were validated.
At the end of an assumption mapping activity, I hope that you’ll have a few fresh lenses to apply to your feature(s), and have uncovered user-centered insights that previously escaped your attention. It’s also a great way to prioritize which features work coherently towards a single user goal — and subsequently, when they need to be displayed together in the UI. Or identify concrete ways to meaningfully segregate controls, methods, and features so users can access them appropriately in their journeys.
When I first conceived of this method, our goal was to ensure that basic and intermediate features are so explicit, that there would be no assumptions at all. Each feature would progressively reveal function and purpose. Disconnected features in the advanced column were axed, and instead focus was placed on connecting basic and intermediate core features.
In my experience, I’ve found that the successful use of an assumption map depends on the abilities of the team. The most successful teams are able to think critically, are unafraid of voicing concerns, are generous with feedback, and possess an unabashed ability to play the devil’s advocate. Quite simply, the more perspectives a team covers, the more assumptions are surfaced, and the more material teams will have to design for. At the same time, there is always a chance layers of complexity or worse, complication, are added in doing this exercise. For that reason alone, 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, go wild with your assumptions!
Acknowledgements — I’d like to thank @dweinberger for all his feedback!
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.
