Today I’d like to share an UX research experience and the process that we followed. In the company I work for we are a team of +30 designers, specialised in different fields and working for different products. One of the challenges that we face since we’ve grown so much is the collaboration and cross-product alignment in terms of UX patterns. In this case, we gather several designers (UX, research, Jr. and Sr.) from different products.

1. Context — My role

I’m a Lead UX Designer of a team of +9 UX designers, working on four professional applications for the banking and finance sector. At the same time we contribute to the company’s Design System (used by other products).

2. Challenges

  1. A different UX pattern is used for the same process in different products: in some cases, a horizontal stepper in some other cases, a vertical stepper.
  2. It’s not clear when it’s about a sequential process, with a defined order (Step 1 must be completed to go to Step 2) or a long process with different sections, but no mandatory order.
  3. It’s not clear when it’s a process with different sections (Step A, Step B, Step C etc.), i.e., the user is free to choose their own order.

Observation: two different components are used for a similar task.

3. Research goals

  1. To understand whether we could unify the pattern and use only one component covering all our process-oriented tasks in the different products.
  2. If a single pattern can be used for both processes, how should that look like?

4. The process

Together with an in-house UX researcher and 3 members of the team we started by defining what we wanted to find out with the research.
For that we collected our process in a Miro board. This helped us to have a collaborative approach.

Miro board to plan the research
Defining the research goal(s)

Defining the research goal(s)

Collaborative process to brainstorm what we want to find out through research.

Defining the type of data that we need

Qualitative Vs. Quantitative data. Based on the research goals, we defined what type of data we want to collect to help answer our questions.

Qualitative Vs. Quantitative data

Generative Vs. Evaluative research. Since our team was quite new in UX Research, we refreshed the different types of research:

– Generative, useful for activities like understanding or exploring.

– Evaluative, good to validate, assess, evaluate, compare or measure.

For our case, running evaluative research to collect qualitative data would be the best approach.

Generative Vs. Evaluative research

Conclusion. Which research method will we adopt? Based on our resources (time availability, designers, testing participants, research platform) we decided to use Usability tests for our first step in the research.

Selected research method: Usability tests

Moderated Vs. Unmoderated tests

And then whether it would be Moderated or Unmoderated.

Moderated Vs. Unmoderated tests

What do we know? Vs. What do we assume?

It’s important to differentiate between things that WE KNOW and things that WE ASSUME. This helps realize that many things that we state might be only assumptions and therefor is useful to be aware that those can be proved wrong.

Facts Vs. Assumptions
Who are our users?

Who are our users?

Defining who are our users is important to know whom we need to reach out to run the usability tests. Even if our products are for professional users, the topic of our research is a UX pattern used by different type of users, not restricted to the specific professional users of our products.

5. Research scope

What do we specifically want to find out?

We defined our research scope by specifying our two main goals:

  • We want to compare the effectiveness of vertical vs horizontal steppers in different use cases. →Horizontal Vs. Vertical
  • We want to validate that the users understand that in certain processes they cannot go one step back, and in some others they can. → Linear vs. non-linear
Research goals

6. What do we know?

  • A stepper guides the user through out a process.
  • A stepper can be confusing for the user (bank’s feedback).
  • A stepped process will help the user to accomplish complex tasks.
  • Clients have to interact with steppers to navigate forms.
  • We currently use vertical vs horizontal steppers depending on the layout and space available in the screen.
  • Horizontal steppers do not work well as a pattern when some steps have subcategories or very long labels.
What do we know?

7. What do we assume?

  • Vertical steppers are easier to use.
  • Items organized vertically are more often associated with a menu, and not with a linear process.
  • Process is better understood when steps are organized horizontally than when they’re vertical.
  • People understand it’s a linear process when they see one step after the other one.
  • People may think that they will have to complete Step 1 to proceed to Step 2.
  • Users expect that horizontal steppers mean linear process so they can’t skip steps.
  • Users expect more flexibility in changing the order of the steps in vertical steppers.
  • A horizontal stepper implies a specific order (associated with timelines).
  • Steppers help the users to navigate within a process.
  • Different icons help users understand which steps they’ve completed in vertical steppers.
What do we assume?

8. The solution

After analyzing the different use cases in our products, we confirmed our need for two different patterns, one for sequential processes (predefined order of steps) and another one for non-sequential processes. As such we then drafted new rules for the design system, that will define two different components, and its usage, to be applied and tested at a later stage:

  • STEPPER: Sequential steps to be completed in a process prior to submission.
  • NAVIGATION: No submission needed. Sections can be completed optionally and in any order.
Drafting a solution

Lessons learned

  • Know the different methodologies and tools to conduct UX research  involve an expert!
  • Involve different stakeholders that know about the topic to test.
  • Have a clear idea of what the problem to tackle is. Many times, it’s not about testing something, but first designing clear rules in the design system.
  • Define what exactly you want to find out with your research, before going blindly into just testing something.

Showing that you or your team are doing user testing might sound sexy to other teams and clients. But all that effort might be useless, or even worse: it might lead to wrong conclusions, if it’s not done a) correctly and b) with a clear idea of what needs to be found out.


Published: