Assumptions can be difficult to overcome. Many times we don’t even realize we’re making them. As an experienced product designer, I find it easier to make these assumptions. They more easily creep into my work subconsciously because I have more knowledge and experience of “best practices” and “what worked before”.
So how can we keep these assumptions in check?
Mapping Assumptions
One of the many design thinking exercises my team implements is user assumption mapping. The first part of the exercise is simply brainstorming any assumptions you’re making.
- What types of users are you trying to reach?
- What do you think your users already know?
- What do you think your users want?
- How will a solution to this problem make a better experience for your users?
Deliberately think about and force yourself to recognize the assumptions you’re making.
After spending time brainstorming, the next step is mapping them on a “truthiness” scale. Can you validate the assumption with any existing data or is it just made up? If it can be confirmed with any data or user interviews at your disposal, it’s a good assumption to keep. If not, it’s just an imaginary assumption. That’s not to say it’s not a valid assumption. It may still be a valid based on knowledge of your users, but it’s important to make that distinction.
User Testing
User testing is a great way to check your assumptions. Earlier this month I was part of a remote design sprint at Automattic to kick off a new focus area. In the end of the week and a half sprint we came out with two concept prototypes that we used to test with real customers.
One insight I gained from this particular sprint was that some assumptions we make can be completely shattered with user testing.
The prototype that I worked on included a checklist of about 10 items to complete. I did my best to make this long checklist approachable. Lots of white space and breathing room in the UI. Starting the checklist with a few items already checked off to give the user some momentum right in the beginning. Providing plenty of education about why these to-do items are important.
Despite all this, I was absolutely certain this long checklist format would turn them off and discourage completion. After testing with a few users, we found they were surprisingly receptive to it. They had an obvious path and next step, and they really appreciated the information and knowledge presented.
A/B Testing
If you’re working to iterate on an existing feature, rather than tackling a new problem, A/B testing can provide some useful insight into your users’ behavior. A huge reason why you should be A/B testing is being able to validate any improvements with cold, hard data. I won’t go over all the benefits of testing here. That can be an entire post in itself.
One thing to keep in mind, as I learned from my colleague Luca, is to try not to create a hypothesis around validating a bias. Don’t use a test to back up an already made decision. Don’t use testing as a way to confirm strong opinions and weak arguments. Test against your bias. Think about what data would invalidate the assumption and look for that, rather than looking for ways to validate it.
As a bonus, this data can be used later to prove any assumptions as more true in your next assumption mapping exercise!
It’s important to recognize the assumptions you make in your product design work. If they can be backed up as true, assumptions in your product and users can be helpful to inform your design decisions.
But if you have no proof to substantiate these assumptions, it can lead to solutions that are off target and wasted time. Try hard to check and cross-check them. This will provide a better solution and experience for your users.