This article introduces the requirements-definition method we use at our company. Whenever we develop a business system for a medium-to-large project, we always use this approach.
Our policy is to get to know the client's operations as thoroughly as the people actually working on the front line — ideally to the same level of familiarity.
It's a very hands-on, labor-intensive process, and it requires the client's employees to take time out of their day to cooperate with us — but it becomes an extremely powerful tool when it comes to building the right product.
The Actual Process
Survey Sheets
To understand the business workflow, we ask every employee to write down the work they do on a survey sheet.
Since we'll be conducting interviews afterward, you might wonder why we bother having people write anything down at all.
But going through this step lets us, the researchers, prepare in advance by studying the material beforehand, and it also lets employees walk through their work with us step by step, confirming each point together as we go. That's why we use this method.
Books on UX research, UX engineering, and user interviews often don't mention doing a survey beforehand — probably because it pulls people away from their normal user flow. But for large-scale projects like core-system development, it turns out to be a highly efficient technique.
Understanding the Existing System
If a system is already in use, we check the contents of the database and form a rough idea of the business processes involved. This helps us get a head start on understanding what's happening inside the company, and it also helps us pick up on the terminology commonly used there.
Some systems are low-code tools that don't have a database of their own, but even then we make a point of using the actual system ourselves to build our understanding of the business.
How We Conduct Interviews
In our case, we work in teams of three.
One person carries nothing so they can focus entirely on the interview. This is the basic approach described in other books as well.
One person carries an iPad and takes notes in GoodNotes. Taking notes while listening helps organize the information and can make the conversation easier to follow; this person also steps in to cover for the others if their concentration lapses.
One person acts as cameraman, mainly using a smartphone to capture the PC screen, printed materials, and audio. We use a smartphone because its pan-focus lens means we don't miss any important moments. We also use a ZOOM F2 (a lavalier pin mic) to capture clean audio — having the employee wear it is an effective way to record clear sound on sites where equipment like sorting machines is running and a smartphone's built-in mic would otherwise struggle to pick up voices.
How We Store Data
We use cloud services or file servers to store all videos and surveys. For audio, we use Whisper to transcribe everything into text.
File names are matched to the ID of the original survey from the initial user-flow exercise. This lets us keep interviews and surveys linked together and manage them as a set.
User Story Mapping
Based on the information we've gathered, the whole team works together on user story mapping. We use FigJam so that remote team members can join in and brainstorm ideas at the same time.
Turning everything into user stories forces us to digest what we heard in the interviews all over again, which deepens our understanding of the business.
These stories also become the units of functionality we implement later.
Summary
Written out, this looks like a short, simple process, but in practice it's extremely time-consuming and mentally demanding work. Even so, we believe it's an essential step for building something genuinely good.
If your company is unhappy with your current system, please don't hesitate to get in touch.
References
These links do not include affiliate tags.
The UX Research Toolbox
Usability Engineering
Lean UX, 3rd Edition