I help businesses use design
to create commercial value.

I have always been slightly uncomfortable with the idea that becoming more senior in design means becoming progressively further removed from the work.

The role obviously changes. I do not need to design every screen, build every prototype or make every artefact myself. In fact, doing that would usually be a sign that something was wrong with the team.

But I do think you need to retain a maker's instinct.

For me, craft has never really been about polish. It is about understanding the material well enough to use it to think.

My background has moved through graphic design, 3D, games, interfaces, mobile products and larger product and service systems. The tools have changed considerably. The useful part has been learning what happens when an idea has to stop being theoretical and become something.

Draw the thing. Build enough of it to see how it behaves. Put some real information into it. Show what happens before and afterwards.

Quite often, the problem becomes obvious.

That matters because businesses can spend an extraordinary amount of time discussing ideas at a level where everybody can agree with them.

A proposition sounds sensible. A strategy sounds coherent. A feature sounds useful.

Then somebody makes it tangible and you discover that three people had three different interpretations of what had apparently been agreed.

I would rather find that out early.

A rough prototype that exposes a bad assumption is more valuable than a beautifully presented argument that allows the assumption to survive for another three months.

This is also why I think senior design leaders need enough understanding of craft to judge the work properly. You do not need to make everything yourself, but you should be able to recognise when something has genuinely been resolved and when the presentation is doing rather more work than the thinking.

There is a commercial point to this as well.

The earlier an idea becomes tangible, the cheaper it is to challenge. Teams can make decisions with better evidence, engineering can see what is actually being proposed, and the business can stop investing in things that only work while they remain abstract.

So I still value the sketch, the prototype, the model and the detail.

Not because senior designers should spend their lives pushing pixels.

Because making things is one of the ways we find out what is true.

A rough prototype that exposes a bad assumption is worth more than a polished argument that allows it to survive.

Close essay

Products accumulate complexity.

That is not necessarily a criticism. Successful products grow. New customers arrive, new capabilities are added, markets change, technical constraints appear and different teams solve different problems.

The difficulty is that each decision can be perfectly reasonable on its own while the product as a whole becomes increasingly difficult to understand.

You see the symptoms eventually.

Navigation expands. Similar things have different names. The same action behaves differently in different places. Exceptions become permanent. Teams start designing around the structure they inherited rather than the problem the customer is trying to solve.

At that point, redesigning individual screens is unlikely to fix very much.

The issue is the model underneath them.

Every product has one. There are objects, relationships, states, permissions, hierarchies and rules. There is an information architecture whether it has been deliberately designed or has simply emerged over time.

Some of the more interesting work I have been involved with in environments such as Pipedrive and Orange has been about making that underlying structure visible enough to reason about.

What is this thing? What does the customer think it is? Where does it belong? What can somebody do with it? What happens when its state changes? How does it relate to everything around it?

These are deceptively simple questions.

In a large product organisation, answering them properly can involve product strategy, design, engineering, data, commercial decisions and quite a lot of organisational history.

The design leadership job is not to remove all of that complexity. Some complexity is real and needs to remain.

The job is to stop unnecessary complexity becoming the customer's problem.

That means establishing a sufficiently coherent model that teams can make local decisions without continually inventing new versions of the product.

There is an organisational benefit as well.

When product, design and engineering share the same mental model, discussions become much cleaner. Ownership is easier to establish. New capabilities have somewhere logical to fit. Trade-offs become visible earlier.

The product becomes something the organisation itself can understand.

That matters because inconsistency is expensive. It creates duplicated design and engineering effort, additional support, slower onboarding and more decisions that have to be revisited later.

Craft helps make an individual idea real.

The next level is making sure those individual ideas belong to the same product.

The aim is not to remove real complexity. It is to stop unnecessary complexity becoming the customer's problem.

Close essay

This sounds obvious, but quite a lot of poor customer experience comes from forgetting it.

Businesses divide themselves for good reasons. There are product teams, operations, technology platforms, support functions, commercial teams, policies, suppliers and different areas of ownership.

Customers do not experience those boundaries in the same way.

They experience one thing.

They buy something. They create an account. Something arrives. A payment is taken. A device connects. A notification appears. Something goes wrong. They contact support.

From inside the organisation those may be seven different systems with seven different owners.

From outside, it is Tuesday afternoon.

This becomes particularly clear with connected products and services.

Work around Ford and FordPass, including vehicle and charging experiences, involved systems where the interface was only one part of what the customer was actually experiencing. The vehicle, account, infrastructure, payment, data, physical environment and support model all had to make enough sense together.

You cannot solve that by designing a better screen.

You first need to see the whole service.

That is where journey maps, service blueprints, system maps and prototypes become useful. I am not particularly interested in the artefacts for their own sake. Their value is that they allow people responsible for different parts of a business to look at the same problem at the same time.

Quite often that reveals that the problem sits between areas of ownership.

The application has done what it was designed to do. The backend has returned the correct state. The support process has been followed.

And the customer is still stuck.

Those joins matter commercially.

Poor hand-offs create support demand. Confusing ownership creates delays. Repeated information creates frustration. Failed service moments damage confidence in the product itself.

The practical design question therefore becomes broader than usability.

Where does responsibility change? What information needs to survive that hand-off? What does the customer believe is happening? Which piece of internal complexity are we accidentally asking them to understand?

Sometimes what appears to be an interface problem turns out to be a policy problem. Sometimes it is data. Sometimes ownership is unclear. Sometimes two parts of the organisation have simply optimised their own piece of the experience independently.

Design is useful here because it can make the whole thing visible.

Once it is visible, the organisation can make a proper decision about it.

A service can fail in the gaps between several things that are all working exactly as designed.

Close essay

There are plenty of digital interactions where a slightly confusing moment is irritating but recoverable.

Moving money is different.

So are identity, security, onboarding and other situations where the customer is being asked to make a consequential decision.

In those environments, clarity is part of the product.

The customer needs to know what is happening, what they need to do, what has happened to their money or information, and what happens next.

If they do not, confidence disappears remarkably quickly.

Work in fintech environments such as Paysend reinforced this for me. Trust is not created by making an interface look reassuring. It comes from the behaviour of the product and the quality of the decisions behind it.

Language needs to be precise.

System status needs to be clear.

Actions need understandable consequences.

Errors need to tell somebody what has happened and what they can do about it.

There are also points where deliberately adding friction is the right design decision.

That matters because businesses understandably spend a great deal of time trying to remove friction. In many cases they should.

But friction and confusion are not the same thing.

If somebody is about to make an irreversible decision, send a significant amount of money or provide sensitive information, slowing them down for five seconds may be considerably better than optimising the interaction for speed.

The decision needs to be proportionate to the risk.

This is where design leadership becomes important because these products are rarely shaped by design alone. Product, engineering, compliance, legal, risk, content and commercial requirements all have legitimate constraints.

The job is not to pretend those constraints do not exist.

It is to find the cleanest route through them without transferring the organisational complexity to the customer.

That requires principles and decision discipline.

What does somebody need to understand before they proceed? What evidence do we have that they understand it? Where is uncertainty acceptable? Where does uncertainty create risk? What happens when the system cannot give a definitive answer?

Those questions are more useful than arguing about whether an individual screen feels simple.

A trustworthy product is not necessarily a simple product.

It is one that is clear about what it is doing.

Friction and confusion are not the same thing. Sometimes slowing somebody down is the responsible design decision.

Close essay

Small design teams can run remarkably well on informal systems.

People know each other. They talk constantly. Experienced designers notice problems and fix them. Standards exist because everybody remembers the previous conversation.

Then the organisation grows.

More designers join. More products appear. Teams move into different areas of the business. Managers arrive with different experience. The number of design decisions increases far faster than the leadership team's ability to review them.

At that point, relying on individual talent stops being a sensible operating model.

This has been one of the more important lessons for me from building and working with larger design organisations, including Pipedrive.

The question changes from how do I improve this piece of work? to what allows this organisation to produce good work consistently?

Design systems are part of the answer, but only part.

You also need standards, critique, role clarity, career expectations, decision rights, shared language and sensible operating rhythms.

Most importantly, people need to understand what good looks like and why.

I do not think the answer is more process.

There is always a danger that organisations respond to inconsistency by adding governance until nobody can move. That solves one problem by creating another.

The right amount of structure is the amount that allows good decisions to happen more reliably.

Sometimes that is a documented standard.

Sometimes it is a weekly critique.

Sometimes it is making ownership explicit.

Sometimes it is simply getting product, engineering and design into the same conversation before three different solutions have already been built.

The aim is not central control.

It is distributed judgement.

That distinction matters.

If every important design decision has to reach a design director, the organisation has not scaled design leadership. It has created a queue.

A stronger model gives teams enough context, standards and authority to make good decisions themselves, with escalation where the risk or uncertainty genuinely requires it.

That improves quality, but it also improves delivery.

Teams spend less time reopening decisions. Senior people can concentrate on the problems where their experience has leverage. Designers have clearer expectations and greater autonomy. Product and engineering have a more predictable design partner.

Eventually, the measure of design leadership is not the work produced personally by the leader.

It is what the organisation is capable of producing when they are somewhere else.

If every important decision has to reach the design director, you have not scaled design leadership. You have created a queue.

Close essay

I think we need to separate two things when talking about AI and design.

The first is production capability.

That has changed enormously.

Teams can generate copy, concepts, interfaces, code, research summaries and working prototypes in a fraction of the time previously required. Used properly, that is a substantial advantage.

I use these tools and I expect them to become a normal part of how product organisations operate.

The second question is whether producing more things more quickly necessarily produces better products.

It does not.

AI is extremely good at producing plausible material. That is both its value and one of its risks.

A weak proposition can now become a convincing prototype remarkably quickly. A questionable assumption can be surrounded by polished reasoning. Ten options can be generated where previously a team had time to think properly about three.

So the constraint moves.

When production becomes cheaper, deciding what is worth producing becomes more important.

That puts greater value on problem framing, evidence, context, trade-offs and quality judgement.

What problem are we actually solving? What evidence supports it? Is the output correct or merely convincing? What has been lost in the summarisation? What are the customer and commercial consequences? Who is accountable for the decision? And, occasionally, should we be doing this at all?

Those are human questions.

This does not mean putting a person into every trivial AI workflow. That would defeat much of the point.

The practical route is to understand where automation is genuinely useful and where judgement needs to remain explicit.

Repetitive production can be automated.

Exploration can be accelerated.

Alternatives can be generated cheaply.

Large amounts of information can be interrogated quickly.

But evidence needs provenance. Important decisions need ownership. Quality needs standards. Risk needs to be proportionate. Somebody needs to understand the consequences of what the system is recommending.

That is as much an operating-model question as a technology question.

Teams need to know where AI sits in the decision path, what can be delegated to it, what must be reviewed and who remains accountable for the outcome.

For design leaders, I think this brings the previous parts of the practice together rather neatly.

Craft gives us a way to make ideas tangible.

Product thinking gives those ideas a coherent model.

Service thinking connects them across organisational boundaries.

Clarity creates trust.

Leadership distributes the ability to make good decisions.

AI increases the amount that teams can produce.

Which leaves judgement.

And I suspect judgement, rather than production, is going to be one of the more valuable design capabilities of the next decade.

AI can generate more options. It cannot remove our responsibility for deciding which ones are worth pursuing.

Close essay