One of the best parts of my work as a designer is the design process itself. My ritual always starts with pen and paper, where I write down everything I know (and think I know) about an upcoming feature. Every question that pops into my head is written down religiously as I sketch. Arrows lead from one wireframe to the next, diagrams mark workflows, and dialog boxes and confirmation modals are carefully drawn with blue pen and colored markers in a college notebook.
This has always been my process, since I started my professional journey as a graphic designer back in the day. And this is the process I followed when I started in the health-tech startup. It was a familiar and calming habit that helped me manage my anxiety and fear of the unknown. Once things felt clearer and more structured (at least in my head) I would transfer the sketches into Figma and present them to other stakeholders.
What I didn’t realize back then was that this ritual wasn’t about clarity; it was about learning how to work when clarity was not fully formed yet.
Every week, I organized a one-hour “Weekly UI Demo”, where I presented updates, new features, and ideas. Everyone was welcome to join, share feedback, and brainstorm. The main goal of this gathering was to clarify ambiguities and decide next steps. More often than not, decision-making was delayed due to lack of information, priority changes, and technical or regulatory constraints. My approach was to keep track of everything by writing comments directly in the Figma file, effectively turning it into a living to-do list.
In addition to the weekly demo, I shared design solutions in our chat channel. I provided a short explanation of each option, explained my reasoning, and asked colleagues to vote on what made the most sense and why. Sometimes a handful of people would respond; other times, there was no response at all – an unavoidable outcome in asynchronous communication.
Being the solo designer in a health-tech startup meant I didn’t have the opportunity for peer reviews with other like-minded designers. It also meant that I, and only I, had to resolve shared assumptions and make decisions for the UX process before the design could move forward.
Decision-making was dispersed across asynchronous communication, technical constraints, and regulatory requirements among other things. My role was to continuously update the design and find a balance between implementation, user needs, and business strategy, while accounting for all of these constraints.
In a fast-paced environment, there is no such thing as stability: priorities shift, specifications unexpectedly change or remain undefined, access to users is limited, clients push their own ideas (often very different from actual user needs), and decisions are postponed, sometimes indefinitely. Many conversations ended with “we’ll revisit this later.”
One of the many responsibilities I had was to gather, document, and accept ambiguity by making deliberate trade-offs in the design, not by lowering quality (quality was never dropped), but by consciously balancing competing constraints in the interface and the system as a whole.
Creating design alternatives is relatively easy compared to making a decision and sticking with it despite ambiguity and missing information. This is a familiar pattern in the UX field, but when designing a health device, “we’ll revisit this later” is a red flag. It means the design must account for edge cases from the start and minimize the introduction of new usability risks.
Usability risks by default are a nightmare; use errors, close calls, operational difficulties, and potential use errors must be identified early according to IEC 62366, with the explicit purpose of documenting Hazard-Related Use Scenarios (HRUS) and the severity associated with each of them.
Every HRUS can have multiple risks assigned to it, depending on the root cause. A different root cause leads to a different design iteration, and each design iteration introduces new risks. Are residual risks acceptable? If yes, they must be justified. If not, a new design iteration is required, and the process starts again. It is a constant loop that makes decisions significantly harder.
A small text change on a button could be misunderstood by a clinician and lead to a delayed diagnosis. A poorly designed interaction could result in accidentally sharing a patient’s personal data – a HRUS with higher severity due to HIPAA.
Not to mention the need to consider the benefit–risk ratio for medical devices – an FDA guidance that had to be kept in mind for every decision.
Every design iteration reshaped the risk landscape.
So how to decide which design alternative is the best?
In practice, there was rarely a single clear answer. The decision was never about finding the perfect solution, but about choosing the option that could move forward safely under the current constraints, while keeping assumptions truly solid and decisions reversible.
Starting with pen and paper and writing down every question helped me identify early what needed to be fully addressed before “freezing” a design and moving to implementation. I never had the full picture; something was always missing. I had to adjust my approach and rely on professional judgment to move forward.
In the early years, making decisions amid ambiguity was a constant stressor because it was not theoretical, it was a fact. It took time to develop a process that could function under these conditions.
Gradually, I came to accept that ambiguity is an inherent part of the design process and that it never truly disappears. It was never a blocker; it was design material, and it needed to be treated as such.
That acceptance didn’t come easily. The designs I produced always carried risks that required testing. The moments when I received no feedback in the chat channel were the moments when I had to internalize the uncertainty, step back, and remove emotion from the equation.
My main responsibility as the sole designer was to contain, shape, and navigate ambiguity in the most responsible way possible. Uncertainty exists in every industry, but in health-tech the stakes are much higher. Holding ambiguity responsibly is not just about building a better product. It directly affects clinicians, patients, and the integrity of the system itself. –
– 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. –
