How to practice synthesis, the most important User research skill for any UX Researcher or Designer
How to learn the basics for the most important skill I learned from graduate school
Photo by Jo Szczepanska on Unsplash
You don’t need to go to graduate school to become a UX Professional.
Graduate School might be the quickest way to become a UX Researcher, but that doesn’t mean that there aren’t excellent UX Researchers and UX Designers that came into the field without first going to grad school.
However, I’ve realized that graduate schools offer two main advantages to aspiring UX professionals: standardized case studies to practice their skills and experience synthesizing data.
The former is something I’ve discussed before, and how practicing in public can help alleviate the former issue. But the latter is one of the most critical skills any UX Professional can have.
So what exactly do I mean by synthesis?
Let’s say you just got done conducting ten user interviews with various users and have a bunch of interview transcripts. How do you turn that into critical findings that you present to stakeholders? By synthesizing and analyzing the data.
How do you take a bunch of project documents written previously and turn that into something you should use for your re-design? By synthesizing the data.
How do you even take the big pile of documents your stakeholders might give you at the start of a project and turn that into things useful for design? By synthesizing the data.
Synthesis is a considerable part of the design process, taking data that currently exists, sometimes from multiple sources, and making sense of that (and turning that into something more beneficial for your purposes. Showing you can do this will not only net you a design job: it is an overall valuable skill for understanding any data you might encounter.
Graduate schools offer the chance to hone this skill over several years with feedback, but that doesn't mean you can’t learn the basics on your own. So here’s my crash course in learning to synthesize data.
It starts by taking the correct first step: having the Why-How-What model in mind.
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 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.
Luckily for you, some of this work is often done ahead of time. For example, the core layer, Why are we doing a project, is usually established with research or project plans ahead of time.
What’s more, this level of synthesis is likely what you’ll need in your working life. So while academia might involve deeper understanding, if you can think of data on these three levels, you’ll be able to synthesize information easier.
So let’s take one of the most common examples of synthesizing information: starting a new project and looking at existing documentation.
When you start a new project, take a deep breath.
When you start a project, you might be given an overwhelming amount of data from documents of every imaginable type.
I’ve gotten everything from organizational charts, previous user notes, meeting minutes, and more. The first time you encounter this, you might spend days or weeks reading through every single document and memorizing everything, only to not get much from it (and re-learning as you go).
So, when you are first handed a massive pile of documents, take a moment and breathe. Rather than diving into each document haphazardly, you should first sort your documents into different categories.
Sort your documents initially into “Why,” “How,” and “What” categories
To start, go through all of your documents and sort them into “Why,” “How,” and “What” categories based on the type of document. 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 besides the ones listed, but it should be pretty easy to sort these out initially. Don’t worry if you get the categories wrong initially: sorting the resources into these categories is necessary to do the next step.
Ask relevant questions based on the level of the document
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. However, you don’t have to have a perfect understanding of all these questions: all you’re trying to do is answer things as best as possible.
After doing this, we can ask the next important questions: what knowledge am I missing to do my job?
Find gaps in your knowledge after summarizing.
You might find that many of the team’s documents don’t seem relevant to your purposes as you answer these questions for your documents. This is why it pays to do the initial sort. Then, instead of wasting time and effort to understand marginally valuable documents, we spend time with the documents that matter most.
However, you should also be aware that while you don’t need to know everything to design a product, it pays to understand the larger picture a little bit. So at this stage, when you start answering questions, you need to write down your gaps in knowledge or different questions you might have.
For example, perhaps the user personas didn’t account for everyone, or your user’s workflow is different than your business. These things are hard to spot in many documents but will become more apparent as you organize things into these levels. These gaps in knowledge will then point you toward who to talk to in the final step: validating your understanding of others.
Run your partially formed understanding by others
You always want to get feedback from others as you learn from these documents, even if it seems crystal clear. This is for several reasons:
You might be completely misunderstanding certain parts of the process
There may be context missing from the documents provided
They might not understand what UX can do (and subsequently withheld other vital documents)
They might be able to address any gaps in your knowledge
In any case, the people who gave you the documents in the first place are usually the people who you should start asking questions of. So ensure you’ve compiled the documents to the point where you know what questions to ask.
Doing so is the last step in a basic synthesis process and will allow you to turn many documents into valuable knowledge.
Synthesis is a tricky but valuable skill to learn.
This process might take a lot of time, but it’s something you need to do as a UX Designer or Researcher. More importantly, it’s not as bad as it might seem. Start slowly, take small steps, and involve the rest of your team in your learning process.
Learning this skill is one of the most valuable skills you can learn in this day and age. Whether you’re reading documents for your design process, books to learn, or anything else, we live in an age where information is plentiful, but understanding is not.
This is why businesses pay six-figure salaries to people who can understand and synthesize Big Data, and it can be the key to you earning just as much.
The more you practice this skill, the quicker it will become. You’ll be able to identify what level of questions (and type of questions to ask) a document should receive automatically and even start to identify gaps in knowledge faster.
So don’t be afraid to practice synthesizing at work to try and learn this skill. It will reward you more than you realize.
Kai Wong is a Senior UX Designer and a top Design Writer on Medium. His new book, Data-informed UX Design, explains small changes you can make regarding data to improve your UX Design process.