Skip to content
Thirty minutes, whenever suits

Design leadership, how I lead, and the system that runs without me.

Leading
Since 2018
People I lead
Design leaders, product designers, UX researchers, content designers on the product documentation, communication designers
Products
4
The signature

At NewStore the product designers all became PMs. I stayed, and rebuilt the team.

That left one discipline, product design, and me as the only person in it. Four product designers and a researcher first. By the time I was Director it was four disciplines, not one: product design, research, content and communication design. Design stopped being a service to product and engineering and became a partner to them.

In numbers
100+story maps run with product and engineering100+research sessions, every six weeks for eight years1 to 4disciplines, built out from product design
How I show up

Explorer, Guide, Enabler. My team can ask for the mode they need.

Rebuilding a function is one job. Being legible while you do it is another. Naming these three stopped the team guessing which version of me they would get on a given project, and let them ask for the one they needed instead.

Explorer
Hands on. Build it. Prove it out.

When retail partners kept hitting rendering problems in the point of sale app, I set up the environment locally and diagnosed them myself. Nobody else had the context, so I went in.

Guide
Set the standard. Let them drive.

On the core checkout workflows I defined the reliability bar we had to hit and left the route to the team. My job was to be unambiguous about the destination, not to drive.

Enabler
Unblock. Protect. Step back.

Arguing for the AI work that got customers reliable answers faster. Not doing it myself, but making sure the people doing it had the room and the resources.

A mode is one person in one room, though, and one person does not scale. Everything below this is what I wrote down so the room works when I am not in it.

Why it needed one

Everyone was doing their best. That was the problem.

When I was still designing rather than leading, the team was doing what most product organisations do when they scale fast. Nobody was failing at their job. The work was simply arriving without a shared system behind it, so quality was inconsistent and alignment was fragile, and both depended on who happened to be in the room.

So I built a design operating system. Not a set of rituals and not a folder of templates. Five parts, each answering a problem on that list, and each feeding back into the roadmap, the delivery pipeline and the team.

What was happening
  • Roadmap items with weak or uneven evidence
  • The same UX problems solved again and again
  • Alignment that depended on who was in the room
  • UX issues appearing only once customers complained
  • Designers unclear on what was expected and how to progress
  • No predictable research rhythm
Design OS
01Story mappingOne narrative before anyone builds
02Research rhythmEvery six weeks, whatever the roadmap does
03Feedback loopsThree horizons, not one
04OKRs and growthDiscipline, so creativity survives
05LevellingWhat good means, in writing
06MetricsOne owner per number, reviewed monthly
Everything feeds back intoThe roadmapThe delivery pipelineThe team
Five parts, each answering one of the problems above. None of them is a ritual on its own.
01A shared mental model

Story mapping, instead of a long argument.

Map the journey, reorder it by impact, slice it into increments that are worth shipping, and align product, engineering and design on the same narrative. I introduced it to replace long debates, feature-first thinking and roadmap ambiguity, and it became the backbone of how work started.

“His ability to drive UX strategy, lead with empathy, and build a cohesive design team made a huge impact on our product work.”
Jose MartinHead of Engineering
Goal
Reserve a product so it is there when I walk into the shop
Who is involved
CustomerStore associateClient services
Activities, and the steps under them
FindSearchCheck stockPick a store
ReserveChoose sizeLeave detailsConfirm
HoldNotify storePut asideSet a window
CollectGreetHand overPay or return
Above the line is release one. The rest is sequenced, not dropped.
In-store reservations, mapped. Product, engineering and design agreed one narrative before anybody estimated anything.
Before
  • A reservation flow treated as simple, with unclear scope
  • Product, engineering and design each reading it differently
  • No lifecycle clarity: states, timing, edge cases
After
  • One end-to-end narrative everyone had agreed to
  • Clear increments, highest value flows first
  • Dependencies and API gaps visible early
  • Launched on time, on an MVP everyone recognised
  • Fewer rounds of rework and realignment
  • Incremental development without resets
02Design as an insights engine

Research every six weeks, whatever the roadmap is doing.

Most organisations treat research as something you do when there is time. I made it a rhythm that runs regardless: every six weeks, exploratory or evaluative depending on what the roadmap needs. The point of a rhythm is that nobody has to argue for it.

“We collaborated on a Continuous Learning strategy that brought fresh user insights straight into the product, resulting in clear, measurable improvements to the user experience.”
David HawdaleSenior UX Researcher, reported to Henning
One cycle, then the next
wk 1
In-store visits
wk 2
In-store visits
wk 3
Remote interviews
wk 4
Prototype testing
wk 5
Prototype testing
wk 6
Data and insight review
and again, whatever the roadmap is doing
Exploratory or evaluative depending on what the roadmap needs. The rhythm is the part nobody has to argue for.
Before
  • Research as a sometimes activity, when there was room for it
  • No predictable research rhythm
  • Roadmap items with weak or uneven evidence
After
  • In-store visits with real associates in real workflows
  • Remote interviews to validate a concept or dig into a behaviour
  • Prototype testing before engineering commits
  • A data and insight review folded into every cycle
  • Workflow problems caught before they reached a build
  • Roadmap decisions carrying real evidence
  • Faster fixes on the friction people hit most often
03An early warning system

Three layers of feedback, at three different speeds.

A quarterly score tells you whether the product is getting better. It does not tell you that something broke this morning. So the system has three horizons rather than one, and the slow layer is the only one most teams have.

“He has a rare ability to zoom into the smallest design details while simultaneously steering bold, strategic bets. A real superstar player-coach.”
Mitun PandeyDirector of Product Operations
Real timeSomething just broke
Always onAn observation, any day
QuarterlyIs quality moving
The same quarter, at three resolutions. Most teams have only the bottom one, which is why they meet a problem after the customer has.
Before
  • UX issues surfacing only once customers had complained
  • A quarterly score as the only read on whether quality was moving
  • Blind spots across products that nobody owned
After
  • Quarterly satisfaction, for whether quality is moving
  • Real-time incident signals, for what just broke
  • Always-on qualitative input, for the things metrics miss
  • UX issues surfaced before they reached support
  • Fewer blind spots across products
  • Faster decisions, and customers who could tell they were heard
04Operational discipline

Creativity without a system burns people out.

Content design committed to the quality of the documentation and hit every published API. Product design committed to consistency and to the success rate of a single screen people use hundreds of times a day. Both are in the measures beside this, and both are the kind of number a design team is not usually asked for.

“He consistently pushed the limits of what his team was able to accomplish, always learning and sharing his knowledge to improve those around him.”
Levi BaadeProduct and Technology Builder
Team objective
Create and raise quality standards
60 to 80%
app consistency score
94.6 to 98%
PIN entry success, across every retailer
100%
of published APIs passed the content quality framework
15
merge requests raised by the design team itself, from none
Under it, per person
A quarterly growth goal, owned by the designer
A fortnightly one to one against the outcome, not the mood
One team objective, measured, with each person’s own goal hanging off it. Creativity without this burns people out.
Before
  • Goals set per person, per quarter, with no shared bar
  • No team level objective for design to be measured against
  • Progress discussed by feel, with no outcome to point at
After
  • Team OKRs for product design, content, brand and research
  • Weekly check-ins on progress and blockers
  • Individual OKRs as quarterly growth goals
  • Fortnightly one to ones, tied to outcomes rather than feelings
  • Smoother onboarding and fewer support loops
  • A more stable, more predictable product
  • Designers raising their own merge requests
05For every design role

Design only scales when people know what good means.

A levelling framework for product designers, content designers, UX researchers and communication designers, built on craft, mindset and context, and then aligned with engineering and product leadership so that complexity, scope, autonomy and impact meant the same thing to everyone.

“I learned so much from his empathetic and transparent leadership style. He created a space where feedback and ideas were valued, and that made a big difference for the team’s growth.”
Sarah den BoerProduct Designer, reported to Henning
JuniorMidSeniorLeadPrincipalCraftStructure, interaction, visual, storytellingMindsetCollaboration, original thinking, initiativeContextProduct, user empathy, technical knowledge
The same four columns for product design, content design, UX research and communication design, agreed with engineering and product so scope and autonomy mean one thing.
Design only scales when people know what good means and how to get there. Written down, it stops being a matter of whose manager you have.
Before
  • Promotions ambiguous
  • Expectations inconsistent between people
  • Designers unsure how to advance
  • Product and engineering partners with no shared reference
After
  • Clear expectations at every level
  • More objective performance conversations
  • One consistent bar across four disciplines
  • Designers progressing faster, and with more confidence
  • Less bias in who got promoted and when
  • Higher morale, and stronger work
  • A design organisation that matured rather than just grew
06Knowing whether it worked

A metric nobody owns is a number nobody moves.

The part I would defend hardest is the flagging. Any team can put a dashboard on a wall. Ours says out loud which of its own numbers it does not trust yet: a month of data missing because an analytics provider was down, a printer whose failure event was never instrumented, a completion rate that is probably measuring people forgetting to close a task rather than the task failing. A number you cannot defend is worse than no number, because somebody will make a decision with it.

What the team measures
  • EfficiencyHow long the work takes
  • ReliabilityWhether it works every time
  • AdoptionWhether it gets used at all
  • SatisfactionSurvey based, so quarterly and slow to move
  • Cost and revenueDerived, so only as good as what it divides
  • System adoptionWanted since the beginning, still not instrumented
37tracked
5owners
30parked
30 mina month
Every metric has one named owner and three possible states: owned, flagged as not yet trustworthy, or parked because we want it and do not measure it yet. The numbers themselves are NewStore’s and stay there.
Before
  • Quality argued by opinion, loudest voice first
  • Numbers that existed somewhere, owned by nobody
  • Nothing to point at when a release made things worse
After
  • One named owner per metric, not the team
  • Thirty minutes a month on why numbers moved, not on updating them
  • Three states per metric: owned, flagged, or parked
  • A metric flat for three months gets a plan or gets cut
  • Regressions found by the team before a customer reports them
  • Design arguments settled with evidence rather than seniority
  • Bad instrumentation found because somebody had to defend a number
What it produced

Four products, and the people who worked on them.

The Associate App, Omnichannel Manager, the platform documentation and newstore.com. Sixty thousand people at work every day, at 90+ companies in 40+ countries.

“He isn’t a typical design or UX lead. He can comfortably think like a product person, and is really on the cutting edge of generative AI and codegen, as his team all are too. He runs rings around some of the engineers in NewStore.”
Benjamin HoskinsChief Technology Officer, NewStore
“He builds design culture, influences how teams think, and helps shape the way we work. He is a builder, a mentor, and someone who always shows up with a strong sense of purpose.”
Phil GranofChief Marketing Officer
“The best design leader I have ever worked with. He has the Midas touch to make everything sharper, clearer and more impactful.”
Scott MatzaHead of Product
“He does not limit himself to his immediate scope. If he sees something that could be improved he steps in and takes initiative without fanfare, and he plays an active role in shaping the culture of the company.”
James LunanSolutions Engineer
If you got this far

I can build the function, and I can still do the work.

Eight years of it at NewStore, where I am still Director of Design, and products of my own alongside. If you are hiring someone to lead design, or to carry an idea from a conversation to a thing people use, both of those are on this site.

Book 30 minutes
Thirty minutes, whenever suits
henning@hwa.design

Smaller doors too: coaching someone building their own product, or taking yours apart with you and handing over how I solved the part you are stuck on.

What that covered here
01The function, from one discipline to four02The system that made the work repeatable03Four disciplines on one levelling framework04The products it shipped, and the numbers they moved05And the products I still design and build end to end