How to inform design decisions without research in hands

I’m that Lucky One UX designer who always has some research findings handy while sitting in front of a blank Figma canvas. Combining the work of researcher and designer at BB Agency for over two years, I’ve learned to properly inform my design process so that when I start building an interface, I typically know where to begin.
On the other hand, my mentorship experience led me to the conclusion that many designers appear to struggle with UX design explorations, partially due to a lack of research deliverables and partially due to resources such as Dribble, which do not aid in the search for good UX references because their focus is primarily visual design.
I hope this article will help designers for whom the pain of designing without any research is palpable. I’ll share my pre-design process step-by-step as well as a couple of tips on where to quickly search for information when the design deadline is tight and the extensive research is out of scope.
Before we begin, let us first agree on the meaning of the terms. When we say “extensive UX research,” we most likely mean that it includes interviews, surveys, workshops, competitor research, CJM, affinity maps, a value proposition canvas, personas, jobs to be done, user stories, and a plethora of other tools, all based on a solid amount of relevant data in hand. The tough issue with UX research is that there are plenty of approaches and frameworks that may still not be beneficial if you are not able to choose the one that will match the specific problem or request.
If we perform some reverse engineering and try to narrow down this entire “extensive” tree back to the roots, there are four major areas that affect the product design that we should try to gather information on:
- business goals
- market circumstances
- user pains
- current phase of the product lifecycle
💡Good design solutions should ideally be located where these four zones intersect.
Even if we only have a few hours to devote to the whole research process, we can obtain at least some knowledge in each of those categories before beginning design. Let us start one by one.
Business goals
Why you need this?
To be able to design a meaningful product, you need to be aware of context. Context would mean to learn about business strategy, specific business goals, specific product goals, and the design (or redesign) goals. To cut a log story short, you need a clear understanding of business whys behind the decision to move forward with the design project.
How to gather the information?
The simplest way to learn about it is to ask, so you can use project questionnaires, interviews, or even run a workshop with the stakeholders. To make this phase of the research more comprehensive, you can also check the product roadmap to understand the bigger picture, dive deeper into the business history and their path by now, etc. You can always get some insides on the business end, because once you have the business stakeholders, you have at least one person to talk to. For me personally, the favorite way of learning about business is through stakeholders workshops that gives me the opportunity to gather all stakeholders together, spend 1–2 hours with them and gain a better understanding of their vision, as well as their internal misalignments and concerns that may not be as explicit during the 1–1 interviews. I also like to ask for the marketing materials or check the social media to understand how the company communicates with the market and what type of expectations they set for their current and future customers.
Market and industry trends
Why you need this?
Again, you should understand the context of market to be able to validate the business point of view on future design. In certain cases, it is clear, that the design notion in the business’s head does not correlate to the market realities. It may be common, for instance, for pre-seed stage startups that usually state, “We don’t have competitors.” If you are a freelancer, it may be time for you to reassess the product concept and check if it matches your goals. As someone said, “It’s easy to solve the wrong problems.”
How to gather the information?
Usually, if you’ve been in your product industry for a while, you are aware of all your major competitors, as well as of what they are doing well or wrong. If not, take time to gather this information. My competitors benchmark process is usually focused on two aspects: the strategic point of view, where I estimate the features themselves, and the executional level, where I look for the UX and user flow implementation. It is also never too late to grab some useful references from other industries to get some fresh ideas. Competitor websites, product trial accounts, and resources like Mobbin will help you gather good references.
💡 If you work on the UX design, don’t be lazy to install the apps and try them out one by one to see how the flows are implemented and how easy it is to interact with the app. Do not rely on the screenshots; static screens will not give you an answer on how things work.
User needs
Why you need this?
You know what I’ll say, right? 🙂 Yes, yes, in order to get more context. You need to know at least some basics about the people you are designing for. At the end of the day, whether you design for B2B or B2C, VR, web, mobile, or anything else, on the other side of your journey there will be people who are trying to deal with a specific situation in their lives through the interface you’ve designed.
How to gather the information?
Typically, when it comes to user-centered design, they all say you must create personas. When it comes to creating personas, you meet the boundary of not having access to actual or potential users of the target groups, so personas very soon become a my-guess-paper with no value.
I prefer to say, that it’s better to go and gather some information about the potential users in any possible form rather than be trapped with a specific framework.
If you have the option to run interviews, that’s great. Take your time, define target groups, run 7–10 interviews, and listen to what they say. It is worth considering that interviews are not a remedy. There are a lot of cases when we conduct the interview and get no valuable insights because we ask the wrong question based on a wrong assumption.
So my suggestion would be to not rely only on interviews. If you have it available, check some of the following sources: analytical tools, demographics and behavior reports in Google Analytics, heatmaps, past user test session recordings, customer support tickets, and your product reviews. If you don’t have any of this, go to Google and search for reviews of similar products on Google, Facebook, in the app store, and Google Play, and dig deeper to see what people say on Trustpilot or ProductHunt. I bet there is a lot of information available, considering that when people are involved in public discussions, it is usually relates to their negative experience. That can give you a glimpse of what their pains are.
Current phase of the product lifecycle
Usually, before beginning to improve something, first you have to assess where you are now and what your starting point is. So, the UX review of any kind can give you the first bunch of obvious problems that should be addressed in the first place. You can use UX laws, heuristics, CRUD, or any other methodology you prefer to get there. I usually run a UX review after all the previous steps, or at least after I’ve learned about the business and the market context. It sometimes gives a slightly different viewpoint compared to reviewing the interface without context.
💡 While reviewing the interface, do not rely only on what you see, it is crucial to try how the interface works. Often a lot of usability issues are hidden between two static screens
Thank you for reading! I’m Elena, a UX/ Product Designer.
🌟 If you have any questions or comments regarding the article, feel free to reach me via LinkedIn