Why mature Product Design is increasingly defined not by screens, but by the way we think about systems, people, consequences, and decisions.

For years, it was relatively easy to show what a designer does. You opened Figma. There were screens, flows, components, prototypes, a design system, and perhaps a journey map or a discovery diagram so that nobody assumed the designer had simply sat down and started moving rectangles around.

The problem is that the more complex the product becomes, the less this visible part tells us about the actual work.

The interface is the result. It is not the beginning.

Behind a single button there may be a decision about permissions. Behind a status, the logic of an entire process. Behind a table, the way several teams divide responsibility. Behind an apparently simple form, there may be legal requirements, technical constraints, a data structure, and a business process that, only a short while earlier, different stakeholders were still describing in three different ways.

Sometimes a calm, seemingly obvious screen is the final result of weeks of analysis, conversations, compromises, and removing problems that could easily have made that same screen far less obvious.

That is why I am becoming less interested in defining Product Design by what a designer produces. I am much more interested in which decisions a designer helps people make, and which decisions they need to understand before designing anything at all.

Because a product is not simply a collection of screens.

A product is a system of decisions.

The More Complex the Product, the Fewer Problems Fit Inside Figma

In a simple product, many problems really can be solved at interface level. A button is difficult to understand. A form is too long. The navigation is confusing. The user does not know what to do next. These are genuine UX problems, and there is no point pretending they are somehow too tactical to deserve attention.

Craft still matters. Good visual design matters. Information hierarchy, spacing, accessibility, microcopy, component behaviour, system states, and the quality of execution are all part of the product. Strategy is not a magical excuse for poor UI.

In complex systems, however, we quickly reach a point where improving a component does not solve the real problem. The user does not know what to do because responsibilities between roles have never been clearly defined. Data is difficult to understand because several parts of the organisation define the same object differently. A flow appears overly complicated because the underlying business process contains real exceptions and dependencies.

The team asks for another filter because nobody previously decided how search should really work. A manager wants a dashboard but cannot yet explain which decision they expect to make with it. Someone wants another status even though nobody has established what makes it meaningfully different from the previous one.

These are still design problems. They simply cannot be solved by moving a button eight pixels to the left.

This is where the part of Product Design that is harder to show in a portfolio begins — and often the part that has a greater impact on the quality of the final product.

Product Design Is a Discipline of Decisions

A designer makes decisions constantly. What should be visible, and what should be hidden? What should be simplified? What needs to remain complex because further simplification would remove context the user actually needs? Which information matters most? Which action should be available, to whom, and at what moment? What happens next? How should the system behave when something does not follow the ideal scenario?

But that is only the first layer.

In mature Product Design, designers do not merely make design decisions themselves. They also design the conditions in which other people can make better decisions.

A user has to decide what to do. A manager has to decide what requires attention. A Product Manager has to decide what we build now and what we deliberately do not build. Engineering has to decide which solution is technically viable and sensible. The business has to decide which trade-offs it is willing to accept. Sometimes somebody finally has to decide that the feature we have been discussing for three weeks should not exist at all.

The interface is therefore only one of the places where these decisions become visible.

Products Are Decision-Making Environments

This becomes especially clear in enterprise products. A user does not open the system simply to “have a good experience”. They come there to perform work: check a state, compare information, assess risk, approve or reject an outcome, hand something over, identify a problem, respond to an exception, document a decision, or understand why something happened.

The interface should therefore help them answer a set of fundamental questions. Where am I? What is happening? What matters? What requires my attention? What can I do? What should I do? What happens next? Can I undo this? Who will see my decision, and what will its consequences be?

This goes beyond usability. It is decision support.

Once a product serves multiple roles, teams, and parts of an organisation, design starts to resemble an architecture of collaboration. It is no longer enough to understand what one user needs. You have to understand what their decision means for the next person in the process.

The Organisation Is Part of the Product Too

Traditional UX is very fond of the singular user. Persona. Journey. Goal. Pain point. Task. There is a satisfying order to it that tends to disappear as soon as we enter a real organisation.

One person performs a task. Another approves it. A third handles exceptions. A fourth needs the report. A fifth must not see part of the data. A sixth later has to understand why the previous five people did what they did. Then a seventh person arrives and explains that the entire process works differently in their department.

An organisation is a system of people, responsibilities, and dependencies. It has hierarchies, conflicting interests, procedures, workarounds, and remarkably durable temporary solutions. Some have lived in Excel for years. Some live in Teams messages. Others exist only in the head of the person who has “always known how to do it”.

That is why many UX problems do not exist between the user and the screen. They exist between users.

Unclear ownership, broken handoffs, missing information, delayed approvals, different interpretations of the same status, or two people each convinced that the task belongs to the other person. A system can look excellent and still produce chaos with impressive efficiency.

If a product is supposed to support an organisation, a designer needs to understand more than the user. They also need to understand the relationships between users.

Complexity Is Not the Problem. Unstructured Complexity Is

For years, the industry has almost automatically equated good UX with simplicity. Fewer steps. Fewer fields. Fewer options. Less information. Less of everything.

Sometimes that is exactly the right direction. At other times, we end up with a beautifully clean screen on which the user still has no idea what is actually happening.

Not every system can be simple. Banking is complex. Healthcare is complex. Administrative processes are complex. Enterprise SaaS is complex. Products supporting multiple roles, dependencies, and exceptions are complex too.

We can structure that reality. We can layer it, guide attention, remove unnecessary elements, and reduce accidental complexity. What we cannot do is pretend that real dependencies have disappeared simply because we hid them from the user.

This is one of the most important distinctions between simplicity and simplification.

Good simplicity comes from understanding complexity. Bad simplification comes from ignoring it.

A mature designer should be able to recognise which of those two things they are doing.

The Most Important Design Decisions Often Do Not Look Like Design

Imagine changing a status in a system. It appears trivial: one label, perhaps a colour, perhaps a dropdown.

Now ask a few questions. Who is allowed to change the status? Can every person move it to every other state? Is there an expected sequence? What happens to the owner of the task after the change? Does anyone receive a notification? Is the change recorded in history? Does it affect reporting? Does it trigger another process? Can it be reversed, and if so, does reversing it require a reason? Are there automations that depend on that status?

The small dropdown stops being a UI problem. It becomes a system problem.

This is exactly why details matter to me. Not because a designer should obsess over every pixel, but because details reveal the consequences of system-level decisions.

That is where strategy meets reality.

A Designer Cannot Work Only from the User’s Perspective

Product Design exists between the user, the business, and technology. We repeat this so often that the triangle can start to feel like another introductory UX slide. In practice, however, this is where some of the hardest work begins.

The user may want complete control. The business may want automation. Engineering may point out that full automation would significantly increase cost or the risk of error. Compliance may then add another condition and explain that some decisions cannot legally be automated at all.

Suddenly, everybody is partly right.

There is no longer an “ideal solution for the user”. There is a network of constraints in which we need to find a solution that is usable, safe, technically viable, and commercially justified.

That is design work. Not removing every constraint, but making good decisions within constraints.

Stakeholder Management Is Not Something Separate from Design

There is one thing many designers learn much later than Auto Layout: you can be right and still get nothing implemented.

You can conduct research, have the data, design an excellent flow, and solve a real problem — and then reopen every decision made over the previous few weeks during a single meeting.

Designing within an organisation means working with people who have different goals, different knowledge, different responsibilities, different risks, and different levels of influence over the product. I do not see this as an annoying addition to “real design”. It is part of real design.

Designer maturity means, among other things, understanding when a decision is needed, who can actually make it, who should be consulted first, what context is still missing, and which question needs to be settled before another one can reasonably be opened. Not every meeting needs every stakeholder. Not every piece of feedback has the same weight. Not every opinion should result in a design change.

Sometimes a good designer defends the solution. Sometimes they find a compromise. Sometimes they change their mind because new information has appeared. At other times, they say: we do not yet have enough information to make this decision.

That is design too.

The Order of Decisions Matters

One of the most common sources of chaos is not necessarily a bad decision. It is a decision made at the wrong time.

We discuss status colours before agreeing on which statuses even exist. We design a dashboard before knowing which decisions the user needs it to support. We solve navigation while the information model is still changing. We argue over a component without having established the logic of the process behind it.

Sometimes the opposite happens. A fundamental decision is postponed for so long that other parts of the product are built on an assumption nobody has formally agreed to.

This becomes expensive because decisions have dependencies.

A good design process therefore cannot be reduced to research → ideation → design → testing → handoff. In reality, we first need to understand what we need to know and decide before we can reasonably decide what comes next.

I call this Decision Architecture.

Decision Architecture

I do not mean another impressive framework designed primarily to look good on a conference slide. Decision Architecture is a very practical way of structuring work.

For an important decision, we first need to define what we are actually trying to decide. This sounds obvious, yet many meetings end without an outcome precisely because people are discussing several different problems under one heading.

We also need to know who should make the decision. Not who has an opinion — everyone can have one — but who is responsible for the outcome. Then we need to identify what context is missing: research, data, technical constraints, business risk, or domain knowledge.

The next question is dependency: what needs to be decided first? If we reverse the order, we will probably return to work that looked finished several weeks earlier.

Every meaningful decision also has a trade-off. Speed may cost control. Flexibility may increase complexity. Automation may reduce transparency. More information may increase cognitive load. There are no meaningful solutions without cost; there are only costs we consciously choose and costs we accidentally ignore.

Finally, there are consequences. Not only on one screen, but across the system. What happens next? Who is affected? Can the decision be reversed? Will we know why it was made? What happens in an edge case?

These are design questions even when none of them concerns the appearance of a button.

Decision Debt: The Debt We Later Call “Complicated UX”

In technology, we know the concept of technical debt well. In design, we talk about design debt. I would add one more: decision debt.

It appears when an important decision has not been made, has been made without sufficient context, has been postponed until an undefined “later”, or when two parts of an organisation have solved the same question in different ways.

At first, nothing dramatic usually happens. The team keeps moving. It adopts an assumption, adds an exception, creates a special status, adds another field or another rule. Then comes a workaround. After that, an Excel file. Later, instructions appear in Slack or Teams. Eventually there is a weekly meeting whose main purpose is manually synchronising information the system itself cannot handle.

Chaos is a subject close enough to me that I have written a separate book about it. The longer I work with complex products, the more convinced I become that chaos rarely appears suddenly. It accumulates in layers. One ambiguity is added to another, an exception starts handling another exception, and a temporary solution develops a surprisingly long life.

A year later, everyone looks at the product and says, “The UX is so complicated.”

Maybe it is. But sometimes the interface has simply inherited years of postponed, contradictory, or poorly communicated decisions.

And that cannot be fixed by redesigning components alone. First, the decision debt has to be repaid.

Design Does Not End When Figma Is Approved

There is another uncomfortable truth: a solution that nobody implements has very limited value.

A design may look excellent in a presentation, receive approval, and later look impressive in a portfolio. Then it meets implementation, a legacy system, API limitations, deadlines, budgets, or a requirement nobody had considered before.

The question then becomes whether the designer created only a concept or whether they can also help that concept survive contact with reality.

This does not mean defending every element down to the last pixel. That would be closer to stubbornness than strategy. It means being able to recognise which parts of the solution are fundamental and which can change without destroying its purpose.

If everything is equally important, nothing is truly important.

A mature designer should know where there is room to negotiate and where a compromise stops being a compromise and starts breaking the logic of the solution.

Outcome Matters More Than the Artefact

Figma is a tool. A prototype is a tool. A journey map, workshop, research report, and design system are tools too. None of them is the goal in itself.

If a beautifully prepared artefact does not help the team make a decision, reduce risk, communicate more clearly, or move the product towards a better outcome, we may have an exceptionally well-documented problem while remaining exactly where we started.

As seniority grows, I become less interested in the number of deliverables. What matters much more is the ability to move a team from ambiguity to understanding, from understanding to decision, from decision to solution, and from solution to something that actually works.

AI Changes the Way We Work. It Does Not Remove Our Responsibility to Think

AI has made the discussion about the value of Product Design even more interesting. Production is becoming cheaper. We can generate copy faster, explore variations faster, analyse large amounts of information, create initial concepts, organise documentation, and obtain a first version of almost anything in much less time.

I use AI extensively, and I have written two books about it, including one focused on how to use it effectively in professional work. Interestingly, the more I use AI, the less convinced I become by the popular idea of working from libraries of “ready-made prompts” that are supposed to lead the user directly to the correct answer.

Not because prompts are useless. Because a good prompt does not remove the need to think.

AI Lowers the Cost of Answers, Not the Cost of Decisions

AI can answer a question extremely quickly. Someone still has to determine whether the right question was asked, whether the model received enough context, what the answer is missing, which assumptions it made, and whether a direction that sounds sensible on screen actually makes sense in the real product.

This matters particularly in design because a problem rarely ends on one screen. An answer may look convincing locally while ignoring relationships with the rest of the system, user roles, data, technical constraints, or business consequences.

AI can produce an answer very quickly. It does not bear the consequences if we accept it.

The designer does.

A Thinking Partner, Not an Autopilot

The most valuable use of AI for me is as a thinking partner. I can ask it to generate alternatives, identify edge cases, challenge an assumption, structure unclear information, compare several directions, or examine a problem from a perspective I had not considered before.

That can significantly widen the field of analysis.

But there comes a point when you need to close the AI and think independently.

It is remarkably easy to fall into a loop: question, answer, improved answer, alternative, comparison of alternatives, evaluation of the comparison, another version. After a while, you have an impressive amount of text and decreasing certainty about what problem you were originally trying to solve.

AI can accelerate movement. It does not guarantee that you are moving in the right direction.

My working model is therefore more iterative. A human defines the direction. AI helps expand the field of possibilities. The human evaluates. AI can help refine the selected direction. The human makes the decision.

Sometimes this cycle repeats several times. Sometimes the first answer is enough to realise that continuing the conversation with the model is no longer adding value. In that case, the best way to use AI is simply to stop using it.

The Most Dangerous Answer Is Not Always the Wrong One

Of course, AI can be wrong. Paradoxically, that may not be the biggest problem. An obvious piece of nonsense can be recognised and rejected.

Far more interesting are answers that are good enough: logical, elegant, well written, professional sounding, and convincing enough to make us stop asking the next question.

That is when it becomes easiest to give the tool more than execution. We can begin to outsource our own judgement.

And judgement is one of the most important capabilities in Product Design.

This is why I do not treat AI as an automatic problem-solving machine. I treat it more like an extremely fast collaborator capable of doing a considerable amount of work, but one that does not take responsibility for the consequences of its recommendations.

AI Does Not Remove the Need for Craft

I am also unconvinced by the extreme version of the argument that because AI can generate an interface, UI no longer has value.

Good interfaces still require quality. AI can produce something visually attractive and significantly accelerate part of the execution, but someone still needs to assess whether the information hierarchy is correct, whether the user understands the state of the system, whether the component behaves correctly in different conditions, whether the solution is accessible, whether it scales to real data, supports different roles, handles errors, and avoids hiding important information.

A mature Product Designer does not stop being a designer in order to become a strategist.

Strategic thinking needs to be supported by strong craft.

Otherwise, strategy ends as a presentation.

AI Raises the Bar Rather Than Removing It

If it becomes increasingly easy to create a competent screen, a competent screen alone tells us less and less about a designer’s capability. That does not mean designers will no longer be needed. It means it will become increasingly difficult to build professional value on production alone.

Understanding the problem, systems thinking, product architecture, working with ambiguity, asking the right questions, understanding consequences, negotiating trade-offs, and connecting user, technology, and business perspectives all become more important.

AI is excellent at generating possibilities.

Product Design, however, is not about having the largest number of possibilities.

It is about choosing the right one.

Seniority Is Not About Knowing Every Answer

Designer maturity is not about walking into a meeting and immediately announcing the solution. The longer I work with products, the more value I see in the sentence: “I don’t know yet. We need to establish X first.”

That is not a lack of competence. It is recognition of dependency.

A senior designer should not know everything. They should know what we still do not know, who can provide the missing context, which elements are facts and which are assumptions, which risks we are willing to accept, and when we finally have enough information to move forward.

It is a very different form of confidence. Not confidence in having the answer, but confidence in the process of arriving at one.

Strategic Product Design Begins Where Your Own Screen Ends

Strategic thinking does not mean producing more diagrams. Nor does it mean that a designer should simultaneously perform the work of a Product Manager, developer, analyst, and CEO.

It means understanding the wider system.

If I change this workflow, what happens next? If I simplify this screen, which information disappears? If I automate this decision, who loses control? If we introduce another role, how do permissions change? If we add this feature, who will maintain it? If the user makes a mistake, can the system recover? If the business decision changes six months from now, will the architecture survive it?

These are not questions above design.

They are design.

The Best Designers Design Conversations Too

There is another layer of work that never appears in screenshots. The way we talk about the product also affects the outcome.

Do we begin a meeting by presenting a solution, or by explaining which decision we need? Does a stakeholder see one hundred screens or three scenarios that expose the most important consequences? Do we present five equal possibilities, or one recommendation with clear reasoning and trade-offs?

It also matters whether we know what we expect from the meeting. Approval? Feedback? Data? A decision?

Meetings themselves can produce decision debt, particularly those ending with the immortal phrase: “Let’s think about it some more.”

Communication is therefore not a soft skill attached to design. It is one of the mechanisms through which design becomes possible at all.

It Is Not About Winning Every Discussion

This approach can easily create a caricature of the strategic designer: someone who enters the room, controls every stakeholder, and heroically defends their vision.

That is not the point.

The product is not the designer’s territory. Not all our ideas are good. Not every constraint is an obstacle. Not every compromise damages UX. Some of the most important information appears precisely because other specialists bring it into the conversation.

A developer may notice a consequence the designer missed. An analyst may challenge an assumption. A stakeholder may know about a business constraint that was previously invisible. A user may behave in a completely different way from the ideal flow we designed.

Strategic design therefore also requires humility.

We do not defend our solution at all costs. We defend the logic behind the solution for as long as we have good reasons to believe it is sound.

That is an important difference.

Product Design Does Not Need Fewer Details. It Needs a Better Connection Between Detail and Strategy

I do not want to choose between strategy and craft, system and interface, or big picture and detail.

Good Product Design needs both levels at the same time.

Strategy without detail does not know whether it works. Detail without strategy does not know why it exists.

It is often in the smallest parts of a system that we discover whether a large assumption survives contact with reality. A status, an error state, an empty state, a permission, a disabled action, an escalation, a confirmation, change history, or one piece of information arriving a few seconds too late may all look like minor implementation details.

Sometimes that is exactly where the entire strategy fails.

So What Is the Future of Product Design?

I do not think the answer is to move away from interface design. Nor do I think every designer needs to change their title to Strategic Designer.

Job titles come and go. Tools do too.

Not so long ago, knowing a particular application could itself be a differentiating skill. Today, many things can be generated in seconds. A few years from now, the toolset will probably look different again.

One part of our work, however, remains surprisingly stable. We still need to understand the problem, recognise the system, identify dependencies, notice conflict, gather the right context, give structure to complexity, make decisions, explain them, examine their consequences, revise them when better information appears, and move a solution to the point where it genuinely helps somebody.

That is what mature Product Design means to me.

Product Design Is Decision Design

The longer I work with products, the less I believe that the most important result of a designer’s work is the screen.

The screen is visible. The decisions that led to it usually are not.

You do not see the conversation that finally gave two roles clear responsibilities. You do not see the feature we deliberately chose not to build. You do not see the process simplified before Figma was even opened, or the conflict between requirements that was resolved before reaching the interface. You do not see the week spent discovering why three teams used the same status to mean three different things. You also do not see the moment when it became necessary to stop asking AI and analyse the problem independently again.

And yet those things often determine the quality of the final product.

That is why I increasingly think about Product Design as Decision Architecture. We design the conditions in which users can understand a situation and act. We help teams turn ambiguity into direction. We connect perspectives that do not naturally align. We give structure to complexity. We protect the essence of a solution while remaining willing to change its form. We use tools — including AI — to think more broadly and work more efficiently, not to escape responsibility for thinking.

Eventually, all those decisions become something very concrete: a flow, a system, a product, sometimes even one apparently ordinary button.

And perhaps that is why the best design often looks simpler than the work behind it really was.

Not because there was less thinking behind it. Because there was more.