When a team gathers the requirements for an enterprise software intended for expert users, workshops are organised with managers, stakeholders and users, corporate procedures are reviewed, alignment with management takes place. When the picture looks complete, development starts. Some time later, when the prototype reaches the users, requests, exceptions and decision criteria emerge that were never declared upfront. A series of reworks follows, with costs that are hard to estimate in advance.
This happens in particular when the software is for expert users, and it has to do with how their minds work: an important part of the real work stays outside what gets said.
When experts’ needs remain unspoken
Think of an experienced mechanic who, the moment an engine starts, immediately identifies the cause of an unusual sound. If we ask how, the answer is that they hear it. A complete explanation is rarely articulated, because over the years their mind has learned to recognise that sound immediately.
The same happens with the professionals who will use the software we are designing. An auditor, a hospital pharmacist, a quality inspector: each has learned over the years operations they now perform automatically. When a project team investigates procedures or working practices, part of the information stays outside what gets said.
Philosopher Michael Polanyi, in his 1966 book The Tacit Dimension, defined this phenomenon as tacit knowledge, summarised in the sentence “we know more than we can tell”.
Four practices to surface the hidden requirements
When we work on design with expert users, we integrate specific practices into requirements gathering, dedicated to surfacing the part of the work that the expert performs without thinking about it. We combine them depending on the project context.
1. Working alongside the expert, like an apprentice
One of our analysts spends a day, or more, alongside the professional, asking questions during the real work, the way an apprentice would. In this role, the expert puts into words choices and criteria they would otherwise apply automatically.
2. Going through the recording with the expert
With their permission, we record the professional during a real task. Right after, we go through the recording together and ask what they were thinking at specific points. By watching their own actions, they tell us the reasoning that stayed implicit during the work.
3. Examining the notes, files and objects the expert uses every day
Every expert builds, over time, personal artefacts: parameterised Excel files, sticky notes on the monitor, work notebooks, desktop shortcuts. A session devoted to going through these together, with precise questions about why they are made the way they are, surfaces practical rules that rarely come out in meeting rooms.
4. Reconstructing one difficult decision, step by step
Instead of asking how the work runs in general, we start from a concrete case: a difficult decision, an avoided error. We guide the expert to reconstruct, step by step, what they saw, what they thought, what they ruled out. The memory of a specific case carries many more details than an abstract account of one’s own method.
What changes for project sponsors
The effect of these practices, in software analysis, shows up on four levels:
- Requirements are more complete and less subject to rework. Exceptions and edge cases emerge during analysis rather than during testing, reducing requirement changes and shortening overall development and release time.
- Hidden costs go down. More complete and accurate requirements mean less ambiguity for the development team, less rework on features that do not reflect real work, fewer support tickets after launch.
- Trust in the initiative and in the solution improves. Stakeholders meet a team that gets into their work and asks questions consistent with their practice, and their trust and willingness to take part in other initiatives grow.
- The product makes work more efficient because it is more aligned with real work. In production, the expert user recognises the software as a useful tool and integrates it into their daily workflow.
Conclusion
A large part of an expert professional’s knowledge lives in automatic actions, implicit criteria and perceptual signals that they struggle to articulate when asked directly.
Addressing this phenomenon during requirements gathering calls for dedicated practices, which can be integrated into the analysis process to reach, in a short time, a product that supports real work.
A Product Design team grounded in user-centered practices can support the gathering of this information to make the difference between a successful investment and one that has to be repeated, avoiding later rework and revisions.
In design for vertical domains, healthcare, finance, industrial or legal, the difference between a successful investment and one that has to be repeated happens here.
Are you designing software for professionals in industrial, healthcare, financial or legal sectors? Tell us about your project.
Read how we approach requirements gathering with expert users.
Main Author: Gabriella Moro, UX Manger @ Bitrock