Meetings are part of daily life in any company. In the health-tech company I was working, we had many different kinds, usually at the office and, after Covid, increasingly remote.

Each meeting had its own agenda depending on who organized it and what the desired outcome was. The purpose of my weekly UI meeting was to bring together stakeholders from engineering, QA, medical, and data science to share perspectives, brainstorm ideas, and set priorities.

In the startup world, there is always pressure around deadlines and resources. There are constant trade-offs between business strategy and which feature should be shipped next, so having a meeting like this helped keep people aligned.

During the design cycle where requirements are collected, priorities are set depending on many factors: implementation difficulty, design complexity, the priority of the user need, and how it affects the business and sales. A designer’s job is to see the big picture of the feature and determine the value it brings to the end user, while other stakeholders can visualize the outcome and understand the value it brings to the product. For that reason, a feature should always be designed as a whole.

However, in an agile environment, it’s a standard practice to ask whether a new feature can be split into smaller pieces and implemented incrementally across different releases.

In theory, the logic is simple. The first part is implemented in release X, the second part in the next release, the third part in the release after that, and so on. In practice, priorities shift frequently, and there is a strong chance that the second part of a feature will be pushed two or three releases later.

In these kinds of situations, the outcome is often confusion and frustration for end users. The first implemented part may work as intended, but it becomes almost useless without the second part.

So the feature is technically functional, but function without context is not enough.

At the same time, each group in the organization sees the product through a different lens.

The business thinks in roadmaps: what will be delivered by the end of the quarter and what impact it will have on revenue.

Engineering thinks in feasibility and technical constraints. They are the machinists behind the product and have the final say on what can be implemented, how fast, and why something may not be possible.

Clinicians and medical professionals expect the system to be clear, easy to understand, and easy to use. Most of all, it should bring value to their work, not only in terms of productivity, but also in terms of quality, trustworthiness, and reliability in moments that truly matter.

And a startup as a whole, operates almost always in survival mode. It needs to move quickly to stay competitive, demonstrate ROI to secure funding, and solve problems caused by internal constraints such as limited personnel or lack of specialized expertise.

All these perspectives operate simultaneously, each pursuing its own priorities. Alignment between them is often fragile, not because communication is absent, but because each group is optimizing for different outcomes.

Everyone owns a piece of the process. The user, however, experiences it as one.

So, who is responsible for the final experience?

As the sole designer, my role was to design every feature coming from user feedback, internal suggestions, or brainstorming sessions with colleagues.

My approach was always holistic, but I frequently encountered constraints that were outside my control. There were times when I had to compromise and say, “this is good enough for now.” Not because I believed it was the best solution, but because many times I was not part of the strategic trade-offs that shaped those decisions.

Sometimes I was asked to solve an implementation problem in the user interface, even though the underlying issue was not a usability problem at all.

During those moments, I pushed back and argued that the real issue was not the interface but the system behavior behind it. Most of the time, I was heard, understood, and even agreed with. But I was still outnumbered because the constraints carried more weight. I had to comply with decisions that did not fully make sense from a usability perspective.

Internally, that was frustrating. When a better solution exists but the system is unwilling to pursue it, it creates tension between what should be done and what is realistically possible.

Over time, I learned to let go of that frustration and began anticipating the constraints before they were presented. It was the only way to remain effective. I realized that I was not simply designing screens. I was designing within a system of constraints, ownership gaps, and resource decisions.

I was responsible for only a small part of the product and I managed to keep my principles intact. I continued designing features as complete experiences and advocating for better implementations so that users could actually benefit from the product.

If the feature had shipped together as originally intended, there likely would have been no frustration or negative feedback. There would simply have been value: a clear, reliable flow that allowed medical reviewers to complete their work efficiently.

After all these years, I still don’t have the answer to the question. What I do know is that for the experience to remain coherent, alignment across the product chain is essential.

Looking back, I can see that design decisions are rarely just design decisions. They are not about colors, buttons, or menus. They reflect how a team aligns, prioritizes, and takes ownership. –

– 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. –