I’m not writing this story because it has a clean lesson or a triumphant turnaround. I’m writing it because health-tech design is often discussed in terms of tools, processes, and clinical workflows, while the reality is far messier, especially when you’re early, alone, and learning as you go. This is an attempt to document what it felt like to step into that ambiguity, the assumptions I carried with me, and the moment I realized that uncertainty wasn’t a temporary phase, but part of the job itself.
When I applied to the health-tech startup, I approached it like any other role: an opportunity to bring my design practice into a new domain. The interview went well, I passed the design assignment (there was one after my first interview), and after the second interview, the offer came, along with excitement, hope, and fear.
Being the sole UX/UI designer at a health-tech startup came with a level of responsibility I underestimated early on. As a newcomer to the domain, I didn’t know what was truly expected of me (apart from my design skills), or how I could meaningfully contribute in such a complex and highly regulated space.
During onboarding, I was introduced to the bigger picture: how the system worked, how communication between intended users and the company was handled, how product development functioned, and what customer support might look like in the future. I met everyone: from engineers to data scientists, and clinical experts to QA, while trying to assemble a coherent mental model from fragmented explanations. Somewhere in between, I received a simple Sketch file with a scattergram and was told about the first feature I would design.
There was no design library and no existing assets. I had the freedom to build everything from scratch, without worrying about breaking anything because there was nothing to break.
Shortly after I started, I ran a workshop to bring everyone together and surface the knowledge that lived only in people’s heads. Nothing was documented at the time, and it was important to understand for whom the product was intended. I knew, in a general sense, that the primary users were clinicians, specifically neurologists, but that knowledge was insufficient to support decisions.
We ended up with more than five empathy maps for as many personas. With everyone’s help, we reached a point where we could clearly separate assumptions from facts. At the end of the session, we looked at the white papers taped to the walls and windows: yellow post-its represented facts, while colored ones marked assumptions rooted in common sense or what seemed useful.
I organized the results into structured chunks of information. I wrote down what each persona would say, think, feel, and do, along with their pain points and goals. And it worked; it gave me solid ground to begin analyzing the intended users.
How I would ultimately use that information, I had to figure out later. What I did instead was to trust the outcome completely and never question it, even though something felt off.
The first time I realized this trust was misplaced was during a meeting with a clinician. The session was an educational presentation on epilepsy, and it was the first time I heard that not all neurologists necessarily agree on a specific diagnosis.
I had never expected that two professionals could review the same video of the same patient having the same seizure, and yet arrive at different conclusions about the patient’s condition. A disagreement was possible, and this possibility had never surfaced during my workshop on empathy maps and personas. Naturally, it made me wonder what else I wasn’t aware of.
I started paying closer attention to the conditions shaping clinicians’ decisions, the real context of use. And I don’t mean the social, environmental, or technical context of use that’s related to the user experience. I’m talking about how clinicians decide the course of treatment for a patient. I knew that every input and action is shaped by experience, bias, constraints, and incentives that are often invisible to those outside of them, but knowing something conceptually is very different from validating it.
To make things worse, I faced a big challenge when I understood that I wouldn’t have access to as many clinicians as I had hoped or as often as I needed. It meant I would have to start designing without ever having the full picture.
My only tools were my design practice, personal judgment, whatever research I could conduct to learn more about epilepsy, and fragments of information I could gather online and from colleagues about clinical workflows.
Over time, I realized that my responsibility as the sole designer wasn’t just to create empathy maps and personas or design beautiful interfaces. It was not even about collecting requirements. It was about making decisions in their absence, and being able to justify them, defend them, and take responsibility for their consequences. In the health-tech industry, that responsibility carries extra weight, because the cost of misunderstanding is real and the margin for error is extremely small.
Over the years, I stopped treating requirements and feedback as the sole source of truth and started treating them as data; something that could be interpreted, weighed, and sometimes contradicted. Clarity didn’t come from interviewing more clinicians, or asking better questions alone, but from accepting that answers, however few or many, could be incomplete, conflicting, or even wrong.
Looking back, the biggest mistake wasn’t putting my trust in the assumptions gathered during that workshop. It was that I didn’t trust the quiet voice in my head telling me something felt misaligned. I didn’t yet have the language to express that concern in a way others could understand, or to show that what I was sensing wasn’t intuition alone, but a signal that my understanding was still forming, and that it deserved time, scrutiny, and a voice to fully develop. –
– This is the first article in a series I’m calling Designing in the Unknown, where I reflect on the realities of designing in a complex, high-stakes environment. In the next pieces, I’ll unpack moments, decisions, and tensions that shaped my work over time in the health-tech domain. –
