At Kormoan, we have found that product design briefs rarely remain as narrow as they first appear. A conversation may begin around UI, a prototype, or a set of screens, but once we start examining the product, the work often moves backwards before it moves forward. Product Discovery raises questions about the original requirements.

UX exposes workflows that need simplifying rather than redesigning. A design system reveals inconsistencies that individual screens were hiding. And engineering introduces constraints that sometimes change the design itself.This is why we have never found “we design screens” to be a particularly accurate description of what a digital product design company actually builds.

From the outside, the misunderstanding is understandable. Design is usually judged by what eventually becomes visible: wireframes, prototypes, polished interfaces, and carefully documented components. By the time someone sees those outputs, much of the difficult thinking has already disappeared behind them. A digital product is not simply a collection of screens. It is a collection of decisions about how a business, its technology, and its customers should interact. The interface is where some of those decisions become visible.

The work often begins before there is anything to design

Most product engagements arrive with more certainty than they actually contain. There may already be a roadmap, feature requirements, and strong stakeholder opinions. Engineering may have discussed architecture. Leadership may have a clear picture of what the finished product should become.

Then Product Discovery starts asking less comfortable questions. Who is this really for? Which problem matters enough for someone to change their behaviour? Which requirements come from customers, and which have accumulated internally? What does the first release genuinely need to prove?

One of the hardest conversations we have with teams is explaining that moving directly into UI can sometimes be the fastest way to make the wrong idea look convincing. Once an assumption becomes a polished prototype, it gains credibility simply because people can see it. Good Digital Product Design sometimes needs to slow that momentum before it accelerates it.

The goal isn’t to delay building. It is to make sure the thing being built deserves the investment that follows.

UX is where organisational complexity meets real behaviour

Companies understand their own complexity extremely well. They know why approvals exist, why information needs to be collected, and why one department depends on another. Over time, those structures naturally begin appearing inside the products they create.

Customers do not arrive with that context. They arrive because they want to accomplish something.

For us, UX is partly about deciding how much organisational complexity a customer should ever be asked to experience. A seven-step process may accurately represent what happens inside the business, but that does not mean the customer needs seven steps. An internal distinction between departments may matter operationally while being completely meaningless in an interface.

This becomes particularly visible in SaaS Product Design, where years of individually reasonable feature requests can produce collectively unreasonable complexity. What initially appears to be a navigation or visual-design problem often sits much deeper. Too many internal decisions have gradually been passed directly to users.

A cleaner dashboard cannot solve that on its own.

UI gives decisions a visible form

Eventually, the product needs a visible form. Typography, hierarchy, spacing, interaction states, and components begin turning the underlying experience into something people can actually use. But UI is not decoration applied after the serious thinking has finished.

A good interface helps people understand what deserves attention and what can remain quiet. In our work, this becomes particularly clear when an organisation initially asks for a visual redesign.

Once the product is examined more closely, navigation may reflect decisions made years earlier, important actions may have become buried, and similar features may behave differently. What looked like a UI problem turns out to be a product problem.

The same tension appears in Website Design & Redesign. Changing how an experience looks cannot repair a journey that no longer represents how customers understand the business. Sometimes redesigning what people see means reconsidering what sits underneath it first.

A growing product needs a system, not more isolated screens

Products rarely remain the size they were at launch. Capabilities expand, teams grow, and different designers and engineers make slightly different decisions about familiar interactions.

Individually, those differences seem harmless. Over time, they become the experience. This is where a design system becomes important. It is often described as a reusable component library, but we think its more interesting role is preserving decisions. It gives design and engineering a shared language so that the fundamentals of the experience do not need to be renegotiated every time something new is built.

This has also shaped the way we structure product work at Kormoan. Depending on what a product needs, an engagement can move from Product Discovery through UX and UI into design systems, engineering collaboration, and the complete product build.

What we have learned from working across those stages is that the gaps between them matter. A decision made during discovery can lose its meaning by the time it reaches engineering if nobody carries the context forward. A carefully considered interaction can be simplified during implementation until the interface still resembles the design, but the reasoning behind it has disappeared.

For us, continuity is not simply a smoother delivery process. It is part of designing the product.

AI makes continuity even more important

Artificial intelligence adds another layer to this responsibility. Products can now recommend, generate, predict, and automate rather than simply wait for direct instructions.

That changes more than the technology. This is where Design for AI and AI Product Strategy need to become part of product-design thinking rather than separate AI initiatives. Teams need to decide where intelligence genuinely reduces effort, when people need control, how uncertainty should be communicated, and whether an AI interaction improves the existing workflow at all.

We rarely agree with adding AI simply because the market appears to expect it. A chatbot placed on top of a confusing SaaS product does not resolve the underlying confusion. Sometimes, it gives the customer another decision: should I use the existing interface, or should I ask the AI?

The technology may be new, but the responsibility is familiar. Someone still has to decide which complexity belongs to the product and which complexity should reach the person using it.

The design file is not the product

“Design handoff” has always felt slightly misleading because real product development rarely contains such a clean boundary. Technical constraints appear during implementation. Real data exposes edge cases that prototypes did not anticipate. An interaction that felt obvious in Figma may behave differently once it becomes part of a working system.

Designers and engineers need enough continuity to respond without losing the thinking that shaped the experience. Sometimes a product design engagement concludes with validated flows, detailed interfaces, prototypes, and an engineering-ready design system. In other cases, the journey continues into the complete build.

Neither model is automatically better. What matters is whether the reasoning survives.

What a product design company really leaves behind

Perhaps our definition of product design at Kormoan has become less concerned with deliverables over time. A prototype, interface, or design system matters, but each is evidence of decisions made earlier. What matters more is whether those decisions survive from the first conversation through to the product people eventually use.

That changes how we think about the original question.

What does a product design company build?

Sometimes the visible answer is a prototype. Sometimes it is a new UX, a scalable design system, or a complete digital product. But there is another output that is much harder to put into a project folder: a clearer understanding of what the product should be and why.

Users will never see most of the decisions that created that clarity. They will simply experience their consequences. When those decisions remain connected, the product begins to feel coherent without users knowing how many disciplines were involved in making it.

That invisible continuity may be one of the most valuable things a digital product design company builds.

Final Thought

The most valuable product design work is often the part users never see. They do not see the assumptions challenged during discovery, the workflows simplified before UI, or the conversations between design and engineering that prevent an experience from losing its intent.

They simply notice when a product makes sense. That is why, at Kormoan, we have come to see product design as more than the creation of interfaces. It is the work of carrying clarity from an early idea through every decision that eventually becomes part of the product. The screens matter, but they are only where that thinking becomes visible.

Perhaps the real measure of a digital product design company is not how much it designs, but how little complexity it leaves for the user to understand.