How initial user interviews get projects on track from the start.
Conducting user interviews when designing digital products is always a good idea. Even more so, for products with highly specific user base and use cases. Let me share some personal experiences.
Insights gained from user interviews and user observation give us designers a reality check of our assumptions and ideas. We depend on research to create products that meet user’s exact needs and expectations.
This particularly holds true for products designed for a very specific and specialized user base. They require us designers to build understanding for the subject matter and use cases the product will be designed for.
Project settings that demand early user interviews
Having worked as a digital designer for almost twenty years, I’ve been involved in many different kinds of projects. An ideal design project starts with a research phase. Unfortunately, it’s not always possible to integrate user research from the start. Frequently we are able to conduct user interviews to validate our designs only at a later stage of the product development. This works ok for products that don’t require us to dive into complex, specific domains that exceed general knowledge and experience. In this case, we are able to draft our first ideas based on general research.
In my experience, projects that meet one or more of the following criteria need early user interviews to eliminate uncertainties from the start:
- Targeting a highly specialized user base
- Operating within a very specific subject matter that we are not familiar with
- Unclear stakeholders and user base
- Unclear client briefings and/or briefings that contain different, competing use case descriptions
- Business tools for company internal use
- Overall unclear goals
You get it: whenever I and my team had troubles understanding the background and goals of a new project at the start, we tried to kick it off by conducting user interviews with relevant users and stakeholders.
When initial assumptions meet reality
Whenever I talk about this topic, a personal work experience from some years ago comes to my mind.
A department of a long term client contacted us for a new project. The company (the IT branch for a large Austrian enterprise) needed support with redesigning an application for internal use.
In a first briefing meeting with management, we learned about the backgrounds of the existing application. According to the briefing, department managers relied on the app to check and validate access rights of their employees once in a year. There were only some brief remarks about other seemingly unimportant target groups. After the initial project meetings, this single use case and user group formed the basis for our assumptions.
Since the overall subject matter and internal perspective of the tool was fairly unknown to us, we selected a group of department managers and division managers with the client for initial user interviews and observation.
Conducting the first round of user observations and interviews was an eye-opener on many levels. It always makes a big difference to watch actual users use the software and perform tasks previously only described in a briefing meeting.
For user interviews and observations, it’s always a good idea to split tasks: My user research colleague guided the test person through the interview, asked questions and set the tasks to perform with the tool. I observed the test person using the tool, took notes and asked questions in between.
We also recorded the interview’s audio, as well as the screencast of the test person using the tool. This way, we could always come back to the interview details, if needed.
A whole new story, discovered by interviewing users
Throughout the interviews, we started to better understand the test person’s tasks and needs regarding the tool. However, there was another big surprise for us. Every manager we interviewed and observated pointed out the importance of another user role: the IT coordinator.
It turned out that C-level management had underestimated this role in the initial briefing.
In fact, there was another major use case: Besides the annual controlling of access rights done by management, non-managerial staff also used the tool to evaluate other employees’ access rights.
Actually, this use case even was much more frequent than the initially considered controlling use case.
Because we had been speaking to top management for the initial briefing only, this use case was overseen since it’s kind of invisible to C-level management.
Thanks to starting the project with user interviews and user observation, we did not waste any time with following false assumptions. Instead, the whole team (including client stakeholders) started the project with newly gained insights and fresh ideas.
If uncertain, talk to users!
For our project, the first project phase of carefully designed user interviews and user observation was crucial for the accuracy and success of the subsequent project phases and outcome.
This little story is quite unusual and cannot be generalized.
Still, it opened by eyes about how important early and direct access to real users is.
If you happen to come across a similar project setting, I’d recommend talking to users before going into details.