How to better familiarize yourself with projects when starting a redesign
How to make sense of all the documents your team might pile on you
I figured out a better way to familiarize myself with redesign projects when I started one in December.
When you’re asked to redesign a project, your manager (or the team) might give you a stack of documents to get you up to speed. Sometimes, it’s everything you need to understand everything from a UX perspective. Other times, it’s a pile of seemingly unrelated documents.
So you might heavily rely on other team members to make sense of everything you’re given. Unfortunately, that wasn’t the case in December: between team members taking vacations and the holidays, I had to learn how to make sense of everything mostly on my own.
I did this by relying on one of the fundamental concepts in project management: the Why-How-What model.
Understanding the Why-How-What model
The Why-How-What, or Golden Circle Model, was developed by Simon Sinek, a British-American author and Marketing consultant. While it was initially designed for Project Management, it has been adopted in several fields, including UX Design.
The model involves three levels of understanding, with each being crucial in getting people to understand the larger picture:
What: What is being done in a project?
How: How are the things being done?
Why: Why are we doing these things (i.e., the project’s purpose)?
Everyone on the team knows What they should be doing, but very few people may know Why they are doing something. However, knowing each of these levels is crucial to provide clarity and focus to your project.
Consider the way you present user research findings. If your team adores and trusts UX, all you need to do is present the What. In this case, you would tell them two things:
What are the UX problems?
What do you recommend to fix this?
Most of the time, you must add the How to your presentation. This includes:
How did you find this problem? (i.e., your methods and testing approach)
How high-priority is this problem?
How severe are these issues (i.e., what happened with users that encountered the issue)?
How much will it cost to address this? (i.e., is this low-hanging fruit or a significant investment)
etc.
The core layer, Why are we doing user research, is usually established ahead of time with research plans. Doing so allows our team to understand what we plan to understand through user testing and know there are reasons for recommending design changes.
If this is how we present our user research, why not take that approach to understand new projects? Here’s how to do that.
Sort your documents into “Why,” “How,” and “What” categories
To start, go through all of your documents and sort them into “Why,” “How,” and “What” categories. This helps you understand what questions to have in mind while reading them.
As a rule of thumb, the less UX-focused a document is, the more likely it is to be in the “Why” or “How” categories. Here are some examples of different kinds of resources:
Typical “Why” Resources:
Project plans/Mission statement
Powerpoint presentations for stakeholders/conferences
Organizational maps
Internal wikis
Technical/Database maps
Typical “How” Resources:
Design systems
Previous UX Research (interviews and feedback)
Design artifacts (user personas, journey maps, etc.)
Research plans
Internal wikis
Typical “What” Resources:
Current designs
Old user prototypes
Powerpoint “tutorials”
Workflow diagrams
Your team might give you tons of potential resources, and it can quickly be overwhelming if they’re given to you all at once. But if you’re able to sort each type of resource, then you can move on to the next step.
Ask relevant questions based on the level of the document
One thing you should keep in mind is sometimes, you’re not the primary audience for specific documents. This is why breaking the documents down into these categories can help you understand what sort of answers you can expect to find in them.
For example, perhaps you don’t have to know the technical implementation of how databases interact with one another (a “Why” resource). However, what might matter then is understanding more general questions, such as:
How does your product interact with other systems? Are there specific interactions that take you to other products?
Likewise, if you’re looking at User Personas (a “How” resource), you might have more specific questions, like:
Are all of these personas still relevant?
Do we need to consider additional personas for users?
Are there any unusual categories that don’t usually appear in personas? Why are they there?
Lastly, with a Current website (a “What” resource), there are a lot of questions you might want to consider:
What is the overall usability of the site?
What interactions run against best practices?
What terms do I not understand (and need clarification)?
What doesn’t make sense from a UX perspective?
What are the core tasks a user might accomplish on this website?
Etc.
Sorting your documents like this helps to guide what questions you might try to answer when looking at each document. But, ultimately, this isn’t something that you can do alone.
Reading over past documents helps you find gaps in knowledge
When you start any UX Design project, you often know nothing about the subject. That’s the reason your team might provide you with tons of documentation. But you don’t need to understand everything given to you to accomplish your primary task: redesigning a product that needs it.
What matters, then, is understanding the product well enough to find where your gaps in knowledge may be. For example, perhaps the user personas didn’t account for everyone, or your user’s workflow is different than your business’. Whatever the case, finding those gaps in knowledge requires talking with the rest of your team about the questions you might have from those documents.
But the Why-How-What model can help you more efficiently understand the documentation your team might provide you, especially if it’s not all UX-related. Doing so allows you to figure out what you need to understand from certain documents and can help you get familiar with the ins and outs of your project.
Kai Wong is a Senior UX Designer, Design Writer, and author of the Data and Design newsletter. His new book, Data-informed UX Design, explains small changes you can make regarding data to improve your UX Design process.