User experience mindset

On direction

The dominant pressure in tech right now is for speed. Engineering teams are asked to ship faster. AI tools are compressing delivery cycles. Throughput is up across the board. All of this is good news. The problem is that the conversation about what we’re shipping, and why, has not kept pace with the conversation about how quickly.

A team running fast in the wrong direction will arrive at the wrong place faster than a slower team. This isn’t a complicated observation, but it’s the one product organisations most consistently fail to act on. They treat the velocity question as solvable through better tooling, and the direction question as something that will work itself out. It doesn’t.

Providing direction is the most valuable thing a mature UX function can do. It means answering, with the team and the leadership, the questions delivery alone can’t: which problems are worth solving, who exactly we’re solving them for, and what success will look like in the lives of those people. When those answers are clear, delivery speed becomes useful. When they aren’t, more delivery compounds the confusion.

On the unit of work

The standard way of measuring product work is by what gets shipped. Features delivered, tickets closed, releases pushed. These are easy to count, which is why they dominate dashboards. They are also, by themselves, almost useless as indicators of whether the work mattered.

Shipping a feature isn’t the achievement. The achievement is the change in customer behaviour the feature was meant to produce, which then translates into the business outcomes you care about. The only way to produce that change in behaviour is a change in the customer’s experience. Did this user’s life get easier? Did this customer find what they needed faster than before? Did the thing we set out to solve get solved? Those are the questions that should follow every release. When the team can’t answer them, the team has a bigger problem than its backlog.

Reorienting a team around outcomes for the user rather than the fact of delivery changes a lot of things. It changes what gets measured, what gets prioritised, what gets celebrated. It also tends to be uncomfortable, because outcome-driven work makes it visible when shipped features didn’t change anything. That visibility is exactly what the team needs. Most product organisations are full of features that didn’t work and quietly got absorbed into the system, never properly examined, because nobody was looking at the results.

On knowing customers

The most consistent gap I find inside product organisations is between how well the team thinks it understands its customers and how well it does, at the level required to make confident product decisions and stand behind the business outcomes those decisions are meant to produce. Teams have data: usage analytics, support tickets, satisfaction scores. They have personas, sometimes from years ago, sometimes recently refreshed. They have an internal sense, often confidently held, of who their users are and what they want.

Almost none of this is the same as understanding customers. Real understanding comes from sustained attention to small numbers of real people in their contexts: watching them use the product, listening to what they say when they aren’t being asked the right questions, observing the moments that lead into and out of the product as much as the product itself. This is slow, expensive in attention, and impossible to scale through dashboards. It is also the only thing that produces the kind of insight that reshapes a roadmap.

Aggregate experience scores, NPS, CSAT, SUS, CES, and the rest, are worse than useless. They feel legitimate because they’re easy to collect and produce a trackable number. The claim underneath, that customer experience can be compressed into a single value that means something, does not survive examination. Two products with identical NPS scores can have completely different things going on underneath. The score moves up and the team has no idea what changed; it moves down and they don’t know either. Once the score becomes a target, the team starts optimising the score, which usually means making it more flattering rather than making the experience better. The metric ends up measuring how good the team has become at gaming it.

Companies that build durable competitive advantage through experience are almost always the ones that take qualitative customer understanding seriously. It is the work most companies skip, because it is harder to justify in a budget meeting than a survey platform. That is exactly why it is valuable.

On the role of design

The version of design I keep encountering inside companies is the executional one. Product decides what’s needed, engineering decides how to build it, design decides what it should look like and how it should work for the user. This is design as the polish layer. It is still the version most non-design executives have in mind when they think about UX, and it consistently underuses what design can contribute.

Design’s most valuable contribution comes before execution. What is the problem here? Whose problem is it? Is it the right problem to solve? Is this the right way to solve it, or the first plausible way we thought of? Designers doing strategic work ask these questions before the build starts. The answers shape what gets built, well before anyone decides how it should look.

This does not mean designers should run product strategy single-handedly. It is an argument for running it jointly with their counterparts: with product, who carry the view on which directions are viable for the business; with engineering, who carry the view on what is feasible and at what cost; and with the customer-facing teams, who are closest to the users and their experience. Design brings the methods for working out, systematically, what is right for the user. The other functions bring what design needs to turn that into something the company can build and sell. The strategic decision is what comes out when these views are brought together.

On working across functions

Strategic UX work does not happen inside a design team. It cannot. The work requires understanding that no single function has: the customer, the business, the technical reality, the operational constraints, what support tickets and sales calls keep saying.

In practice, the cross-functional condition has to be set up on purpose. Heads of product, design, engineering, and customer-facing teams have to be in the same room: regularly, and as the unit of strategic decision-making rather than as a stakeholder courtesy. This is harder than it sounds. Functions have their own pressures, their own metrics, their own cultures. Aligning them around a shared picture of where the product should go takes structure and patience.

Most of the work I do, particularly the UX Strategy Programme and the UX Strategy Sprint, is about creating the conditions for this kind of work. The structure is the thing. Without it, even the best-intentioned cross-functional efforts dissolve back into siloed conversations within a few months.

On UX maturity

A UX practice is a property of the organisation rather than of the design team. It means the whole company has a shared, current understanding of who the customers are and what their experience is like. It means strategic decisions get made with that understanding in the room. It means qualitative research is a habit the organisation runs on rather than a service that occasionally gets requested.

Most companies are nowhere near this. A few teams build up real customer understanding while the rest of the organisation runs on outdated assumptions and confident guesses, and the gap between them gets treated as a personnel issue rather than a structural one. Closing that gap is slow work, and it is the work that produces durable advantage. Companies that do it become difficult to displace, because they operate from a depth of customer understanding that takes years to build.

This is the underlying purpose of the UX Leadership Residency: senior UX leadership in place long enough for that maturity to start growing. Maturity grows over time. It cannot be installed.