If you ask Google, you’ll figure that the user experience research process is some kind of a systematic study to gather insights that will drive and inform your UI/UX design decisions.
The important word here is “systematic”. The methodical process of designing a research project is what saves your precious time and brain, and helps to get maximum value from research.
Sounds good but flat, let’s try to visualize our research process.
Seems like any process can be shown as a line. Every time we at Eleken write an article like the one you’re reading, or a case study about a new product Eleken’s team has designed, we’re trying to stretch out the research our designers have done into a chain of steps.
And every time designers argue that they are rather buzzing around their research subject than moving from point A to point B. Thus, the UX discovery studies feel more like a loop, where you discover, define, design, and rerun it all one more time. But a closed loop as a route gives us a migraine. It shows no progress.
Let’s better make our research process model look like a spiral with many loops. We start with wide discovery research when we know nothing about the product, the audience, and the market to learn a few rough ideas on the topic, then spiral back, making connections between the ideas. Then keep lurking around, again and again, gradually adding new insights, validating or discarding our assumptions, and making more connections, checking if each idea is consistent (or inconsistent) with the users’ expectations.
With every new loop, we’re getting closer to our goal — the perfect fit between the product and the audience’s needs.
Now, when we understand the approximate path, let’s see what elements it consists of.
What are the 4 stages of UX research process?
The research process consists of single studies we conduct to learn something new. Every study is a set of steps, whether it is a usability test, benchmark study, or user interview,. A convenient way to identify those steps provides a DECIDE framework, that stands for the six steps in conducting user research for effective UX:
- Determine the goals,
- Explore the questions,
- Choose the methods,
- Identify the practical issues,
- Decide how to deal with ethical issues, and
- Evaluate the results.
If you need some tips for running a specific study, check out this UX research plan template, it digs much deeper into this topic.
When you face a challenge to design or redesign an app, you need to string a series of such specific studies into a system that will help to gain all the knowledge you need to get the job done. The first step here is to clarify what knowledge you are looking for. At different stages of product development, you need different insights.
Say, you might want to get a sense of your users’ problem to solve it via your app. Or you need to test the product prototype to see whether you’re moving in the right direction in terms of usability. Finally, you can ask for feedback when everything is ready to see if any improvements need to be made.
We can split our research into four phases according to our intent — to discover, to explore, to test, and to listen to the reaction. Let’s look at each of the phases in detail, and see how they fit into the overall product design project timeline.
User research discovery phase
The discovery phase is a way to deal with the uncertainty that is inevitable at the onset of any project. To beat the uncertainty, you’re googling and doing qualitative interviews to collect and analyze information about the app, its audience, and intended market.
Discovery helps to clarify the goal and the direction of further movements. If your assumptions make you do a wrong thing or a right thing but in the wrong way, this stage is your chance to figure things out.
It appears from the above that discovery research works especially well when done prior to design itself before efforts are wasted. But you can return to discovery research anytime you need to.
Exploring research phase
During this phase of exploration, you dig deeper into the topic to solve applied problems of design that appear in front of you in the working process.
You compare your features against competitors and detect their user experience shortcomings that you need to rectify within your own app. You split your audience into personas and build user flows to define risky areas for losing customers along the way. You analyze users’ tasks to find ways to save their time and effort with your design decisions.
This research phase overlaps with your active phase in the design process. Whenever you need to validate your design assumption, you use one of the exploring methods.
Testing research phase
The research to ensure that your design is easy to use is mostly done as usability testing.
Nielsen Norman Group teaches us that if you can do only one activity in an effort to improve an existing system, you should choose moderated usability testing, where the person interacts with the interface while continuously verbalizing their thoughts as they move through the tasks.
Thinking aloud usability tests sound easy and cheap. You recruit representative users, give them tasks to perform, let them do the talking, and sit nearby absorbing the insights. That's how it worked in the Pre-pandemic era. If you want to run such research remotely, let me recommend Lookback, one of the remote moderated usability testing tools we at Eleken use. Check out our list of UX research tools that can save the day.
Testing research happens repeatedly during the design process and beyond so that you have time to make changes to your design if the test shows that such changes will benefit the product.
Listening phase
You can’t anticipate everything by testing your interfaces on small samplings. Your final and your most reliable test team is your actual users. So after your product is released, you should listen carefully to the feedback and monitor user problems, successes, and frustrations.
This observation may trigger a new circle of design and development changes called to improve the user experience even more.
When to use which UX research method
There’s a broad list of UX research methods that can answer the questions you ask yourself within each of the four phases of your research. If you want to get to know them better, we have a whole detailed article about UX research methods. However, understanding methods is only half the battle.
Projects with such budgets and timelines that allow using the full set of methods exist only in our dreams. Life is about making choices. Sure you can use one or two familiar methods all the time, but would they give a perfect mix of data every time given that no two apps are identical?
To help you choose the right method, Nielsen Norman Group suggests using their three-dimensional framework that is so good I’m jealous it wasn’t me who came up with this.
Here we have 20 methods mapped across the frame with the following axes:
- Attitudinal ↔ Behavioral
- Qualitative ↔ Quantitative
- Context of Use
The attitudinal vs. behavioral distinction helps us identify the gap between what people say and what people do. Usually, on discovery and exploring phases you need self-reported data, gathered from interviews and card sorting. Behavioral data is especially useful when you’re testing your interfaces.
Now, let’s explore the difference between qualitative and quantitative methods. Qualitative studies observe the event or behavior directly, as is the case with focus groups. They are perfectly suited for answering questions about why or how to fix a problem. Quantitative studies gather the data indirectly, through an analytical tool, for instance. Thus, they are useful when your questions start with how many and how much.
Finally, the context of use means that depending on the phase where you are in your designing process, you can run tests without any product, with a scripted version of the product, or with the actual product when it’s (almost) ready.
Let’s say we’ve started doing a website redesign and need to figure out how many weak spots are there to fix. We’ll use Google Analytics or Hotjar to figure out what frustrates our users. Next, we have a few hypotheses on how to fix the issues. We make paper prototypes and find five volunteers for usability lab studies.
Knowing what you want to ask, and what context of use you can afford at the stage where you are, the problem of choosing the right method is not a problem anymore.
Now it’s your turn.
Keep going
Want to dig further into the user experience topic? Here is an article about human-centered design — our North Star that we aspire to when conducting UX researches.
For more research-focused reading, check out this article about design audit, it is full of usability checkup tricks and you can see how we run researches at Eleken UI/UX design agency.
Top Stories
Try, Then Try Again: Why Iterative Design Process Brings the Finest Results
You have 18 minutes, 20 sticks of spaghetti, one yard of tape, one yard of string, and a marshmallow. You need to build the highest tower possible with a marshmallow on top. What would be your strategy?
That’s not a child game, that’s a design exercise called Marshmallow challenge, that presents surprisingly valuable lessons about the nature of collaboration and project management:
- There’s a group of people that show consistently poor results in solving a Marshmallow challenge. They are recent MBA graduates.
- There’s also a group of people that performs consistently well. They are recent kindergarten graduates.
How is that possible?
Business students are trained to find the single right plan and then implement it. They spend half of their time planning, then building spaghetti constructions, and in the final moments, they put a marshmallow on top. Sometimes it works well, but more often MBA guys end up in “oh-oh” situations.
Children work differently. They start with a marshmallow and make successive prototypes, always keeping a marshmallow on top. So they have a chance to fix unreliable designs multiple times along the way. When time is up — ta-da! — a marshmallow stays on top.
The moral of the story: If you experiment early on, you build the highest towers. This experimental type of collaboration is the essence of the iterative design process.
What is iterative design process?
Let’s start from the iterative design process meaning. It’s simply a series of steps that you repeat, tweaking and improving your product with each new cycle. The goal of iteration is to get closer to the optimal solution with each repetition. Iterations underlie design thinking, as well as Scrum and Agile project management methodologies.
The iterative idea seems effective. It’s obviously effective, yet too-seldom-used — if you look closely at the design agencies’ landscape, you’ll notice how many companies employ the MBA students’ working model (together with their “oh-oh” results).
Take classical service agencies. They provide their clients with big impressive teams that, apart from designers, would include project managers, design architects, and researchers. All those people would investigate the case, draw pie charts, analyze the market to define the single perfect plan, implement it, and then… you figure out they’ve missed something crucial.
Why is iterative design used?
Clients rarely come to a design agency with a detailed project roadmap in place — they mostly have a foggy idea of what they need.
The designer’s main challenge in such cases is to get somehow into the clients’ heads to create the things exactly how they want them to look, even if clients themselves lack understanding.
“Iterative working process is the only way to ensure your design will be a precise fit.”
That was a quote from Maksym, a Design Director at Eleken UI/UX agency. Maksym is a stickler for the iterative design process and Figma (but that's another story). That’s why all designers at Eleken work iteratively (in Figma).
It's not because Maksym forces us to adopt an iterative working model. There are just some obvious iterative design benefits for both designers and their clients:
- Iterative design saves time and money. Mistakes and misunderstandings between requirements and implementations become visible in the first steps, so we can fix them early.
- It enables the team to leverage lessons learned so that designers continually improve the process.
- It involves clients effectively in a design process evaluation.
- It guarantees that the design would reflect the interests of all stakeholders. This is especially important in terms of designer-developer collaboration.
- It ensures that stakeholders of the project have a clear understanding of the project's status throughout the lifecycle.
How iterative design process works
One programming wisdom on Twitter says that theory is when you know something, but it doesn't work. And practice is when something works, but you don’t know why.
We won’t give you any theory here — you can easily find shaky theoretic structures if you google “iterative design process”. We are not theorists, we are an agency that uses iterations on an everyday basis for years already. Iterations are something that works for us (and we even know why).
So let’s look at an iterative design example — the project we carried out for TextMagic. TextMagic was an established CRM app that was going to add some new marketing functionality to their product. They hired Eleken to design that functionality.
The scope of the project was broad, so to start the first iteration we needed to split the whole job into tiny bits. In UI/UX it’s fairly easy — you just iterate screens one by one. Each iteration of the design process goes through three stages: creation, testing, evaluation.
- We take the first screen and make a guess on how it’s going to work based on our initial observation, research, and requirements we gathered. We shape our guesses into a raw mockup and send it for approval to the client’s Project Manager. That’s the stage of creation.
- The Project Manager points us to the ideas they like and those that they don’t. We gather the feedback and leave to reflect on it. That’s the stage of testing.
- We come up with new ideas on how to improve the mockup based on the feedback we got. That’s the evaluation stage, that closes the loop.
As you can probably guess, it’s not the end, only the beginning. Where the first iteration ends, the second starts. Thus, iterations work like spiral turns, that bring us closer to the goal with each turn. You review your solution, refine your guess, review the revised solution, and repeat until you get the answer that satisfies everyone.
Look at TextMagic’s chat widget below. It’s pretty minimalistic, but before it evolved to the final form you can see, it went through numerous approval cycles.
Anything like this, before going live, gets on the PM’s radar. If the design looks good for the PM, the screens land on the desk of the CEO. It can be also reviewed by a Tech Lead or developers that will implement the design. If something on the mockup turns out to be too hard or too long to implement, the designer may be required to simplify a feature of concern.
This iterative process is often called “rapid prototyping,” and it’s not for nothing. The important thing is that creating and testing ideas should happen quickly. The faster, the better. Working with TextMagic, our designers could run several iterations per day. The more often the client or their representatives can negotiate designers’ intermediate results, the faster the design process moves.
Let's not forget about user testing. Testing new designs for projects that are already running, like TextMagic, is an absolute pleasure because you can talk to people who already use the product.
Brand-new startups, however, can also test their prototypes on users. Design collaboration tools, like Maze or Lookback, allow you to test your work on different stages, from product concepts to prototypes.
Great design comes from iterations of good design
Ilya, the Founder & CEO at Eleken, likes to remind us that design is a process, not an event. One might even say it’s an endless process. That means the design can’t be finished — only put on hold for time. Users’ needs change, and the market changes — so should design.
A non-iterative design process is just not suitable for constant improvements. It tries to put a marshmallow on top of your design tower at the last moment and to step aside.
The iterative design project, in contrast, allows you to adjust the tower all the time. Billion-dollar startups take advantage of this possibility like no one else. To prove the point, we have five real stories of top SaaS companies that use iterative design thinking.
Designing Tools for Software Developers: What We've Learnt
Developer tools have been a rather small niche compared to other professional instruments, like design or sales tools. Some call it a typical “cobbler’s children” effect. However, with the rapid growth of the software development sector, things have changed. There are more and more offers on the developer tools market, and the potential is huge.
Our designers got to work with two products made for developers, creating UX design for them from scratch. After diving deep into the world of developer tools design, we discovered that there are so many challenges and issues specific to this type of software. This experience has led us to many insights, some of which we would like to share.
Why is user experience often neglected in developer tools?
The logic is very basic: developers have been active software users long before UX was a thing. As professionals, they easily recognize quality and put functionality before anything else when choosing a product to use (or so we assume). That is why many dev tools look complex and hard to understand for inexperienced users. There’s no point in making an app look sleek and pretty for people who know very well the “dark” side of the software.
Developers often tend to oppose themselves to the users. In this case, by “users” we mean people who interact with software on the very basic level, don’t get the things that are behind the user interface, and believe that most issues can be solved with the "Reset" button. Yet, developers become users, too, when they use the product. Of course, they would make less of the typical user’s silly mistakes, but the rules of the UX design apply to them as much as to any other person.
Also, product owners who make tools for “serious work” tend to invest less in design because they think that there is no need to make such products “fancy”. However, UX design is not about making things pretty.
Think of Adobe products as an example. This is not a developer tool, but it’s a product that most of us are familiar with. Different Adobe products, such as InDesign, Photoshop, Illustrator have quite a complex design that looks serious, professional, and a bit old school. Despite having different functions, all the products follow the same structure and logic so that designers who use all of them won’t get confused. These classical products were created in the nineties. In 2016, when Adobe XD, a tool for UX and UI designers, was launched, its interface was quite different, as the standards of usability have changed, too.
But when it comes to developers tools, good UX doesn’t necessarily mean modern and sleek UI. Let’s take Vim, a code editor developed decades ago that hasn’t changed its look much since then. You have to spend time to learn how to use the software, but it doesn’t seem a problem because, well, that’s part of learning how to code. What is important for developers compared to other solutiona, the tool is functional, light, and adjustable. You can change its look according to your needs.
And here is Sublime, a code editor developed in 2000s. It is quite fast and has introduced new features such as multiple cursors. Developers value it for neat UI and UX. Would you expect Vim and Sublime, two products from distant digital epoques look as different as first and last MacOS do? Let’s take a look: if you are not well familiar with these products, interfaces of both Vim and Sublime don’t look that different.
Most developer tools start with a programmer noticing they have a problem, imagining a way to fix the problem through software automation, and then writing the code that implements that automation. Building for yourself means you get to wear the hat of product manager, engineer, and customer simultaneously.
Beyang Liu, CTO, co-founder of Sourcegraph
Owners of products for developers are often developers themselves. Naturally, they are well-aware of the challenges that their colleagues face, and they have the ability to build a solution to solve them. So, they often end up testing the product themselves, and as a result, the product seems to have no UX flaws at all — because people who have been developing it know the logic and structure well and won’t be confused with the interface: their focus is to test functionality.
As a UX design agency, we always advocate for quality design based on proper UX research and user testing. It’s not just because our job depends on that. Here are some arguments for the importance of UX in tools made for the developers.
Reasons to pay attention to user experience in developers tools
Working efficiency. Good UX decreases the task time, making the work of a developer faster and more productive. This one reason could be enough, but we have a couple more.
High competition. In the past, having a unique technology or functionality was enough to be on top. Nowadays the market is growing faster than ever. No matter how unique your product is, alternatives will appear sooner or later (maybe even sooner than you expect). And that is when usability can play a crucial role, helping you to keep the market without having to lower the prices.
Product owners who think strategically don’t leave design for “later”. That is what our client SlamData did. They developed Reform, a product that can load data from any source and transform it into a comfortable-to-use form. When we started working on the design, we realized that there were no analogs to use as a reference: the idea was completely new.
Developers often launch their product without thinking much of the design because they want to reach the market before competitors do, but it’s a good idea to make a redesign before starting to lose clients.
Simplifying the onboarding. There’s no doubt that developers are tech-savvy enough to operate a complex user interface faster than other people would. But do you know how much time they spent practicing? They have been using this interface daily for many years. Every product owner wants the onboarding to be as fast and smooth as possible, and UI/UX design is a key to that.
Advantage at sales. We have to remember that not all developer tools are sold to individuals. Often the audience includes managers, directors, and other specialists who make the purchase decision. They might have a bit different perspective than developers, and it is likely that a good-looking app will have more points in their eyes (even if they don’t say it directly). A similar effect works with pitch decks: investors are more willing to trust a product with good design, which signals there has been real work input in the project.
This was the case with , a code security app. The founders of Tromzo are developers themselves and they had a very clear image of the product when they came to us. What they needed was a good-looking prototype that they could present to the investors. There are quite some code security apps on the market, so quality UX and UI are a way to stand out.
Developers are humans, too. Tools are made to make the work easier, so why not make the developer's working process more enjoyable? We all like user-friendly and good-looking apps in our daily life, so why do we make developers use those cluttered and clumsy designs at work?
So, how do you design tools for developers? Here are some pieces of advice that we found useful while working with Polaris and Reform by SlamData (with examples).
Three golden rules of UX design for developers tools
Organizing a large amount of information
In many dev tools, you will face large amounts of information. And these are not the things that you can hide in the burger menu: all of them are important for the proper functioning of the app. To not overclutter the screens, you have to use different ways of visual organization.
Here are some examples. In Tromzo, we used heatmaps to give a fast overlook of large depositories. Below there is a long table of vulnerabilities, which would be hard to analyze without some visualization. Heatmap draws the attention of the user to the most problematic repositories, teams, or projects by coloring them in bright red.
On the dashboard of Tromzo that contains a few blocks of information, we used separated cards for each and visualized trends with a graph. In addition, all the most important numbers are shown with big font sizes.
Another way of visualizing a complex system is intelligence graph: each separate element is shown in connection with team, project, vulnerabilities, and so on.
Keeping lots of data on one page
Developers often work with two monitors showing different data that they need to check regularly. Unlike “average” users who easily get lost when they have too much information in front of them, developers are used to it. Even more, some of them would consider it inconvenient to spend precious time switching between different apps or clicking buttons to get to another screen.
One of the solutions can be creating keyboard shortcuts, preferably the combinations that are familiar to the users of other popular software. However, there are more ways to fit big information clusters in an accessible way.
Look at the screen in Reform below: it shows a sequence of steps/choices for setting data conversion variables. We chose point-and-click card-based user interface instead of alternatives such as wizard pattern (each step opening on the new page, like when entering shipping and billing data in a typical online shopping process). This way, each variable is shown at the same time and can be changed within the same screen.
Minimalist colors and visuals
After all, this is a tool for professional developers, so the fewer distractions, the better. Don't use more than one bright color, keep fonts classic and readable, and avoid decorative elements. This advice comes very logically after the previous ones.
For both Tromzo and Reform, we've chosen minimal color palettes with neutral basic color and one accent. Green, red, and yellow are used occasionally when they have a certain function, such as signing the status of items in the list or showing trends: increase or decrease in indicators.
Final thoughts
Designing developer tools is a real challenge: complex software with lots of important information. It may look like “strictness” and “minimalism” constrain creativity, but we think it is the opposite: these requirements stimulate designers to find original solutions and create developer tools with the level of UX that they deserve.
Would you like to get a consultation from experienced UX designers about your product? Contact us!
Your email has been submitted successfully. Check your email for first article we’ve sent you.
