How to use desk research to kick-start your design process
Research can generally be split into two categories:
- Primary: observations in the field, conducting interviews, usability tests, collecting surveys, diaries
- Secondary: desk research
Primary research is time consuming and as I hope you’ve experienced yourself, exhausting. Furthermore, if results are not summarised and presented well, all parties will end up being frustrated; researches because their excitement is not shared within the company, and management because time and money has been spent without clear results. Still, with all the risks and work involved, nothing gets me more excited and eager to design than the rush of adrenaline felt while observing people’s reactions in context, answering questions the entire team had or finding out what works.
Realistically speaking, research doesn’t just come up by itself, as a goal. The company you work for will most likely have a high-level goal set and it’s up to you and your team to define the path to achieve it. This is where secondary research comes into play by using existing knowledge in the world to support the problem space definition. It will guide you towards initial paths to achieve that goal and provide additional arguments to follow it with primary research.
The popular belief is that desk research is only necessary when looking for inspiration to influence an already defined idea. In academia, this first step, called literature review is revised multiple times and has a critical role in the process, driving the direction of the research and its role in the world. The same principle should be applied to design as well. It shouldn’t just be mentioned as a step taken to impress, it should help in grounding the design direction at any point in time, providing strong real-world arguments. Practically, I try to look at three things when starting:
- Existing products— looking at existing products and services, their concepts, interactions and experiences. It includes your internal organisation, the competition, partners or independently developing ideas. It can be incredibly specific or wildly generic — matching your scope.
- Internal knowledge — deep diving into your own company. Open up those ancient drive folders and spend some time understanding customer centre reports, data on previous A/B tests, design iterations, flow diagrams, partnership presentations. Talk to the owners of those files, you might understand more about your own project than you did before.
- Previous research — those crazy passionate researchers and writers spend quite some time making sure their studies, methods and results are valid. Make use of that vast knowledge base and check whether your topic was already considered. This will inform your design direction and help you find additional argument.
Existing products
Collecting a mix of screenshots from existing products and concepts, then categorising them as good and bad examples is not enough. It doesn’t matter if you’re designing a new product or improving an existing one. You’re at the beginning of your process, it’s crucial to look beyond the visual UI. While you’re still looking at actual products, write down summaries for each collection of screens:
- Context: provide some background information to avoid interpretations
- Tasks to achieve: what are they trying to solve at each step? This might feel like an assumption, however, if the product you’re including in your study isn’t clear at all, maybe don’t include it.
- Interactions: how does the system show people what they need to do? How does it provide feedback on their actions?
- Data required: try to understand the information a product requires from its users. Do they track locations? Do they require an account?
- Performance: take a quick peek into their reviews, check hashtags on social media — that’s what I do lately, before updating, to check if the newest release of Sketch is buggy or not
- Evolution: it’s good to find out the way a company got to that solution, what nudged them into that direct;
It might be challenging for highly technical and regulated environments, e.g. lab analysis software, military interfaces. Until you become an expert in that industry, it might make sense to keep the examples more generic and adapt any relevant information you find to your context.
Presenting outcomes
Create short phrases filling in each item in the summary, e.g. analysing two different products’ first screen, on first-time use.
Product 1 — Interactions: onboarding 10s videos to describe their main features. Videos play automatically, only once.
Product 2 — Interactions: in line dismissible text areas are used to describe their main features. Areas have a shine effect on first use to focus sight.
Place summaries near each small collection of product materials, forming a scannable analysis of existing products. It will make it easier to spot patterns used in your industry.
Internal knowledge
Following the same principles, simply listening to your manager, product owner or other stakeholders list requirements shouldn’t be enough either. Conduct similar investigative work and extract the information they most likely hold, expecting others to naturally be aware of it. Ask why, how, when, for whom are you all spending this much time in an office ? Check out these great guides for stakeholder and kickoff interviews too.
Furthermore, spend some time digging through internal documentation, explore your Confluences spaces, check out previous product strategy presentations, and untangle those nasty flow diagrams. Most of it might be dull, but I guarantee you’ll find little pockets of gold, greatly influencing future designs.
Presenting outcomes
Summarise this information in a document — I’m keeping this generic since it depends on your access to information. Different projects pushed me to put together either 1 pagers or infographics before. Earn even more credibility by mentioning internal experts’ know-how and add numbers to the quantifiable things you’re referring to, as customer calls, reviews or refunds.
Previous Research
This is my favourite part of desk research. Nowadays we have access to a vast amount of papers (research articles), use cases, and government studies. However, we are often disregarding these, thinking that our knowledge of design principles and previous work experience is sufficient for creating products, sometimes used by millions.
The only challenging part is finding relevant previous research. Perseverance is key in this case. Simply typing your specific topic in Google will most likely fail. Let’s say that you’re working on a new map based aggregator that’s supposed to display locations, search results, POIs and events, among other things. The lazy way out is to browse through the thousands of map designs available for any sort of device in Dribbble, Uplabs, Behance, Pinterest and create a few of those ‘clean’ designs. You’re done early, management is happy, solve issues along the way, all is fine.
Detach yourself from the position of product designer for a second. Forget about the outcome, the pattern library you’re supposed to use, the arguments you’ll have. Think of yourself as a discoverer of new worlds for a second. Now, look at your project again. You might begin to wonder:
- We can explore the entire planet, why do we look for our address first?
- How did map usage in the digital world evolve in time? What happened when digital maps could be directly manipulated by touch? Are they affecting or supporting our orientation skills?
- How do people look for a place of interest? How do they orient themselves to find it? Dive into the cognitive processes that take place when people perform these actions, at least be aware of them.
- How do people recognize buildings in the real world, when relating them to the digital map? How much detail is just enough to describe it?
You may find yourself with quite a few questions afterward. It’s up to you to merge them into a few focus points or keep them all as possible topics for finding materials
- Self-representation and spatial orientation in digital maps
- Digital maps usage and their effects on everyday lives
- Ability to map real-world location to the digital ones
Once you have those, it’s time to find studies and papers about them. I usually start in Google Scholar and ResearchGate. Both of these are huge databases of papers and thesis’ with downloadable PDFs. It’ even better if you have access to the ACM digital library. You can also check out conferences like CHI and the papers presented there as well — you’ll be amazed at what the amount of research done out there. Start by using a mix of specific and generic search queries. Try using one of the full sentences above, or simply look for keywords and see where it leads you. It’s alright to go with the flow for a while, just don’t get overwhelmed by the amount of available information.
Luckily, articles have a standardised format and just by skimming through their Abstract, Conclusion and Method, you will form a good idea whether the paper is relevant for you. Remember, a published paper was reviewed by a panel of experts analysing its scientific approach and value to the research community. Once you have a shortlist, I’d recommend writing down a summary, looking at:
- Method used to get to those findings, e.g. research method, usage of theories, amount of participants tested, period of time tested, etc.
- Research context: country conducted in, demographics considered, year of research. Be cautious in immediately adopting a study conducted many years ago, on the other side of the planet.
- Conclusions: these phrases validating or invalidating a hypothesis might prove to be strong allies for your case as well.
- Findings related to your topic. These can be statistics driven from government sources, questionnaire results, participant quotes, subject matter expert reviews.
- Ideas that came to you while reading it. You’re not supposed to focus on the solution at this stage, but you can’t stop your brain thinking, right? Write those ideas down and forget about them until the right time comes.
Presenting outcomes
You’ll notice that common themes will emerge while you’re creating the summaries. Some will be related to actual findings, while others to methods used in a context. Among these themes you’ll probably highlight outstanding facts, strong quotes and figures. In the end try to merge all your notes into two to five main themes. Describe each theme in a phrase or two and make snippets from your summaries available as theme details. I learned that giving themes relatable, funny names makes them quite easy to get back to later on.
When presenting these, make it clear that they are formed by thoroughly reviewed documents and highly detailed case studies. In the end, this document and the information it contains will form the basis for your first design explorations.
Does order matter?
Out of the three, you control internal knowledge/input the least. Whether it’s leadership, strategies, technical solutions, or budget cuts, companies do change. Keep this document open, it might steer the design process. When it comes to the other two, experience and discipline will help in knowing when to stop; if not yours then a senior designer’s. Generally, as in interviews, repetitive findings are a good sign to stop. There will always be more products and research to look into, but you need to start focusing on your process at some point.
Having all three covered ensures that you will not start designing based on business requirements and snapshots alone. You will have a solid foundation built to continue the rest of the process.
Redesign with secondary research
Let me put this in practice. I’ve picked a random product from my phone: Samsung’s Notes app. Since I am not aware of the company’s initiatives and strategy, I’m assuming there’s an issue within a user group and setting a broad goal myself:
80% of students interviewed use ‘Notes’ once and then download another app for taking notes. How can we encourage people to use their phone’s default app ?
The screens above are supposed to provide a bit of context about the current product. As mentioned before, the focus is now on defining the problem space. So, let’s start with a few questions on the topic of taking notes:
- How do students feel about their notes? Are they useful, chaotic, used for retention, organised, etc ?
- How did taking notes evolve in time? How do we process the information to write down, generally?
- Are personal notes taken differently from shared ones? If so, what aspects are important for each?
- How do notes look like in different contexts, e.g. learning, listening to lectures, working, team assignments? Are they keywords? Are they scribbled?
During very first try I found a peer-reviewed paper describing what happens in people’s minds while taking notes, to great detail. The study covers cognitive processes trying to describe what really happens in our minds.
Finally, just by typing ‘note-taking method’ and sorting by date, I stumbled upon this paper documenting a five-year long study, specifically mentioning learning and mobile devices. By scanning it, I noticed that it talks about students’ different ways of taking notes and the way it affects their efficiency — directly related to several of my initial questions. I’ve accessed years worth of studies in less than 15 minutes. This is a tiny example of an outcome.
This photo alone, extracted from one of the papers offers more insight than you will ever be able to get from design shots. It’s a representation of what medical students in Finland saw as an efficient note to help them study. It includes drawing, placement, layout, scribbles, highlights, sticky notes, and diagrams.
As I would do with my stakeholders, I’ll get to the point and present my outcomes. In this case, summaries are short and based on two papers only. However, even this small number yielded three common, but interesting themes. The novelty and diversity of your themes will increase with the number of papers you look into.
Adding this to the company’s internal knowledge and to an analysis of existing products would really help in creating a solid set of first sketches and wireframes, ready to be tested in the field.
P.S if you want to quickly turn those wireframes from light to dark mode (or dark to light), give my Sketch plug-in a try and let me know how it worked:)
