How to conduct user research in enterprise software when you can't reach users

We worked on the design of a software without direct access to their users. We managed to do our job by involving stakeholders through interviews and workshop activities.

Author

Sara Fazzini

⚠️ Disclaimer (like on drugs package insert)

Belka advises against designing products without involving final users. This is the story of how we tried to deal with the problems anyway, but nothing beats a good initial research involving end users. Consult your UX expert before taking redesign actions in the absence of users.

We have decided to share our experience anyway to help designers dealing with similar limitations.

Where Have All the People Gone?

The scenario is the redesign of a financial software for a very specialized field where customers are few and almost inaccessible due to compliance.

The company we are working for doesn’t have a design-driven approach. We quickly understood that we could not engage users directly. As designers, we felt lost and stuck.

How can you bring value in these situations?

Confused dogs

We evaluated different approaches to face the situation: we had no intention of designing by relying on our intuitions. We wanted to bring our contribution and show to our customer the value of design, one step at a time.

We focused on the most promising starting point: the three stakeholders involved in the project.

Why Stakeholders

Stakeholders are people inside or outside the company involved with different degrees and interest in the creation and use of the product. The internal stakeholders of the company can be for example:

  • manager
  • developers
  • marketing
  • customer success

It is essential to understand who are the key people to involve, what responsibility and what role they play in the project.

In our case, the stakeholders we deal with are people from the IT area with a direct impact on the project: they take care of maintaining the software and satisfying the requests of users who come from Customer Success. They were able to help us in four aspects.

one two three four

They know the context. You, most likely, not yet. When designing in the enterprise environment it is essential to know the domain of the product. Stakeholders can explain the language of the sector, the concepts and workflows involved.

They saw the user’s needs. Stakeholders often work alongside users, or have been users themselves. They understand all the different users who use it, and their main needs. Moreover, we asked to the Customer Success staff current platforms known usability issues, in order to identify what already emerged explicitly.

They know the core features of the product. We talk to stakeholders to understand which features will be needed in the software, and which ones are not part of the value proposition of the product. The temptation of adding “just one more thing” is always strong.

They can clear up the technical limits. Stakeholders know the technical constraints of the software and the requirements in terms of industry compliance.

Talk is cheap

We started the activities with meetings for the complete team: 4 stakeholders and 2 designers.

We soon noticed some issues: the meetings were long and dispersed. Often the conversation was monopolized by one person, with others passively approving.

These are aspects that frequently go along with group brainstorming; moreover, as confirmed by a lot of research, the ideas produced in this type of activities are less effective than those of individual brainstorming. We realized that it was not the right way to proceed.

We needed to make the most of the contribution of each stakeholder and to be able to deepen the topics.

To solve these communication problems, we decided to involve the stakeholders in two different ways:

  • Individual interviews, in order to understand the context of use of the software better, absorb the maximum information without being overwhelmed by it, and more easily identify inconsistencies
  • Plenary workshop sessions remote.

The interviews

Before starting the interviews we usually set clear objectives. In our case they were:

  • Clarify technical requirements
  • Identify the task
  • Understand what the task consists of and the main contexts of use
  • Understand why the user needs that task and how it is articulated

To achieve these objectives we based the questions on the task, asking the stakeholders to focus

  • on the objective of that activity
  • on the actions that the user must perform
  • on what problems he encounters in doing it

We didn’t know anything about current software, so we asked for clarifications even on the most basic and obvious aspects in the eyes of our customer.

Through demo environments of current programs and the possibility to share the screen, we got the answers we were looking for.

Dog with an idea

Do not put solutions before problems. It sounds like common sense, right?

Mastering the domain and keeping stakeholders focused on the problem were the two most challenging aspects of this path.

Structured confrontation

In order to better understand such a specific context, we regularly asked questions to the stakeholders.

Moreover, we had workshop sessions, in addition to the interviews. We mapped all the elements the users interact with, during those workshops. We based our approach on Object Oriented UX.

Jumping to solutions is always tempting

Stakeholders felt involved, often inclined to present us with solutions to what they recognized to be the problems of current products. Our effort as a designer has been to limit the brainstorming of solutions and try to focus on bringing out all the problems present.

Before starting any activity, be it a workshop or an interview, we need to clarify the objectives and how stakeholders are asked to participate. If the conversation deviates, kindly interrupt the discussion, explicitly remembering what you are doing and why.

We know that a well formulated problem opens the way to a functional solution, and we do not want to anticipate or mix the design phases without reason.

Lessons learned

We collected meaningful information from this project.

  • There is no perfect method that applies to all projects, but there is the method that allows you to learn better in the context in which you find yourself. In our case, without access to users, reaching out to stakeholders was the winning methodological choice.
  • Our job as designers is educating as well as designing. We ask others to train their critical gaze and follow a process with us. We know how crucial and difficult it is to talk about design choices with stakeholders, therefore we believe that it is a skill that a good designer must be able to mature.
  • We cannot ignore good collaborative relationships with stakeholders. A working group that collaborates with pleasure and involvement is a group that will give good results; we maintain relationships with care, we show interest in everyone’s opinions.
  • Understanding the context is a complicated phase, often the most difficult in enterprise projects: let’s get help from internal experts.
  • Planning the design process is an active part of the designer’s work. Your role is to find the most correct methodologies to bring the project to success. Methodological choices greatly influence the output you can produce.

References

Author

Sara Fazzini

Keep in touch with us!

We like to share what we learn.
You can get our discoveries in your inbox subscribing to our newsletter.

Subscribing you accept to receive our newsletter. We will use your email address to send you our articles.
Read the privacy policy here.