In the first article of this series, I wrote about entering a new role without a clear lesson or a triumphant ending. This story sits in the same space, just a bit later, when things felt more certain than they should have.
Receiving a request for a new feature is always fun and challenging. Fun because it’s an opportunity to learn something new, and challenging because every new feature quietly reshapes the system around it.
The first step is to understand the who, the why, the when, and the how. Having in-house end users who are actively participating in the product development has many benefits. However, it has some drawbacks as well. The obvious benefit is the immediate access to them. The inconspicuous drawback is that the immediate access can create a false sense of certainty.
Working with confident medical professionals with decades of experience dramatically reduces guesswork. Clinical workflows are specified down to the last detail, questions are answered, and explanations seem logical and clear.
While designing one of the main features (which was nothing more than a multi-step repetitive task from UX point of view), the primary concern was the number of clicks required to complete it. A familiar UX logic states that tracking the number of clicks can be used to identify unnecessarily long flows. Automating some parts of the medical workflow provided a logical comfort of certainty. In practice, that meant carrying over some information that would otherwise have to be manually entered every time.
While gathering all the requirements and iterating on the early stages of the feature, the confidence and expertise of the medical professionals transferred seamlessly to my responsibility to design it. Soon, I stopped looking for alternatives; there was nothing to challenge because everything made sense.
The implementation worked as expected; task completion was 100% across multiple usability tests. At that point, there was no reason at all to doubt that the feature had been designed in the best possible way.
Over the course of years (yes, years) of using this feature as it was originally specified, the medical professionals made an unexpected request: they asked to re-enter what had been removed. They no longer wanted information to be carried over, but instead preferred to enter it manually – adding back the clicks that had been removed in the name of productivity and speed.
My initial reaction was shock. I could not fathom the reasoning behind it, especially because it came from the same people who had asked for the original feature in the first place.
I kept pondering why someone would want to change something that worked as it was expected, checked every tick box of the UX guidelines, and replace it with the exact opposite of all things. The logic I had followed blindly started to feel more like uncertainty and less like a fact. Naturally, I began to question myself and I wondered if this unexpected user behavior was something that I should have predicted or not.
So, I set up a meeting with the team to get some answers and soften the initial shock. Even though I cannot remember the whole conversation, one thing stayed with me. When I asked, “Why do you want to re-enter the information manually now after all these years?” this was the answer I received:
“Because we realized that carrying over some information doesn’t speed up the process as much as we thought. And adding the information manually makes the decisions more intentional, because the more we use the system, the more we evolve along with it.”
This explanation left me both speechless and surprised. It actually made sense. I could understand the need for making intentional decisions –especially in the health-tech domain– and, at the same time, I could see how someone who has used a system long enough begins to understand its strengths and constraints.
At the time the original requirements were defined, increasing the speed of task completion felt reasonable. What wasn’t taken into account was that people also change after using a product for a long period of time. They “become" part of the system. They grow more proficient, understand it better, and over time their workflows and preferences evolve based on lived experience.
Users are trustworthy within the limits of their own current context.
When building a product, especially a health device that is used on a daily basis, it’s tempting to optimize early and trust what feels measurable and validated. Usability testing, clear requirements, and confident users can create the sense that the right decisions have already been made.
Often, expert confidence can be mistaken for clarity, and speed can be confused with productivity.
It wasn’t about ignorance or a bad decision.
It was about decisions that felt safe, validated, and professional, because users, metrics, and good practices were all aligned. –
– This article is part of the series I’m calling Designing in the Unknown, where I reflect on the realities of designing in a complex, high-stakes environment. In the series, I unpack moments, decisions, and tensions that shaped my work over time in the health-tech domain. –
