Tools for Making Sense of It All
A few weeks ago, I wrote a blog post about how we learn from user interviews to serve as an overview of our process for conducting and learning from user interviews. In that post, I mentioned a few of the design frameworks that we use, but wanted to go more in depth about what those actually are, so here’s my attempt to do just that.
Personas
So you’ve interviewed a bunch of people and are eager to get started on designing a new product or new interfaces for them. As you’re producing new artifacts, you find yourself trying to balance all of your users’ needs — noticing a lot of similarities and a lot of fundamental differences. You might also be finding it difficult and a bit overwhelming to balance the opinions of 10+ people.
Enter personas.
Personas are the basis of our design research. Instead of designing for 10+ people with whom we spoke, we can design for 3–5 users who are generalized representations of these people. They are, in a way, the guiding design framework for the rest of the frameworks they use, allowing us to ask questions about what our users value.
There are a ton of great resources on how to design effective personas, including an awesome blog post written by Patrick. Here’s another great resource: https://www.usability.gov/how-to-and-tools/methods/personas.html
2x2s
As you’re talking to people and starting to squeeze out any insights, you might find that some opposing principles emerge. An example that’s appeared in our research has been “focus on research” and “focus on application.” This duality represents a spectrum of different motives that relate to an interest in hydrologic data. A 2x2 (pronounced 2-by-2) is a way to capture two orthogonal dualities, in addition to being one of my favorite design frameworks.
Or-what-onal?
This is a fancy way of saying that these two dualities must be completely independent of each other. For example, in our research, when we produced our first 2x2, our orthogonal dualities were “focus on research versus focus on application” and “consumer of data versus producer of data.” It’s easy to see that these things are independent. Below is a representation of the types of people that would come out of this 2x2.
In fact, the reason that they’re called 2x2s is that they’re usually represented graphically in this way. This gives you a space to plot your users as you interview them. You should hopefully notice clusters of users appear. These clusters will help in distilling principles and giving you some structure to your user data.
This tutorial gives you a good idea of how to make a 2x2: https://dschool-old.stanford.edu/groups/k12/wiki/29e5a/2X2_Matrix.html
Journey Maps
Once you have your personas and some principles developed, you probably want to understand where your product fits in or where there is an opportunity to address a pain point with a product that doesn’t exist or addresses said pain point in a way that’s currently addressed by products on the market. A great first step in identifying these pain points is to identify the how the users’ current interactions take place. Journey maps are a great way to do this.
Journey maps are essentially a step-by-step walk through of an interaction with the world or with your product from your users’ perspective. It’s really helpful to have personas already developed when you make journey maps, since you’ll want to know why a user might be doing something and what kinds of interactions you could expect them to have. An example of a journey map would be how one of our personas walks through publishing hydrology data with HydroShare.
Journey maps are really helpful in making sure that you’re keeping on track with your designs. A good tutorial to explain them can be found here: https://www.nngroup.com/articles/customer-journey-mapping/
Assumption Testing
As you’re designing, you’re constantly making assumptions about how your users will interact with your product. An example of an assumption that you would make is “our users understand the difference between a group and a page on Facebook.” It’s really important to make a distinction between assumptions and facts that you’ve gotten from testing.
These assumptions can be represented via a graph of the “confidence” vs “risk.”
What are these axes?
Confidence is pretty straightforward, in that it’s the confidence that your assumption is right. Going back to the Facebook example, an assumption like “our users want a way to post text and images to their news feed” is an assumption that probably has pretty high confidence, whereas something like “our users want to be able to use Messenger to send money” was probably an assumption that designers at Facebook were much less confident about.
Risk is essentially the measure of how important finding an answer to that an assumption is. In the previous example, it was probably pretty important that the designers of Facebook find out if their users want to post text and images to their news feed since it’s a core functionality, whereas sending money over Messenger is a much lower risk assumption.
Once you have this framework, it’s important to develop strategies for testing these assumptions, especially assumptions that are high-risk and low-confidence. Here is another tutorial for doing assumption testing: https://www.ibm.com/design/thinking/activities/assumptions-and-questions
Wireframes
Ok, so you’ve done all of these frameworks and learned a lot about your users, and you want to get a product in front of them to test to see if your product is useful. A great way to do this, especially for user interfaces and software products, is through the use of wireframes.
Wireframes are a super concrete framework that could almost be considered to be the deliverable of a complete user experience design project. They are prototypes of your product in the form of a mocked-up user interface. Wireframes can take on many different levels of completeness (sometimes called fidelity) — from scratch work on paper to pseudo-functional deployable prototypes. They are especially useful for doing co-design, so these wireframes can be taken back to your users to see how they interact with your product.
A good tutorial for wireframing can be found here: https://www.usability.gov/how-to-and-tools/methods/wireframing.html
Other Frameworks
These are by no means the only design frameworks that exist. Some external sources for some other really helpful ones can be found below!
Card Sorting: https://www.usability.gov/how-to-and-tools/methods/card-sorting.html
Scenarios: https://www.usability.gov/how-to-and-tools/methods/scenarios.html
One Last Note
One thing that is super important to realize about the design process and design frameworks is that they are not one-size fits all. I’ve gone through so many design processes that involved modifications to some of these design frameworks, or didn’t involve these design frameworks, since they’re not required. The most important thing when creating design frameworks is to make them most useful to your process.
