About

Why this work

Nobody opens a reporting dashboard for pleasure. The people I design for have a job to finish, and my screens are the thing standing between them and finishing it. They are never going to admire the interface. The best thing they will ever say about it is that they stopped noticing it.

That framing decides almost everything else. It means I optimise for the four hundredth use rather than the first. It means the most valuable move is usually to remove a step rather than add a feature. And it means the work is not done when the screen looks right — it is done when someone gets through it without stopping to think.

It is also why I am still interested after thirteen years at one company. Complex B2B software is where design still has the most left to give: the problems are unglamorous, nobody is going to feature them on Dribbble, and the difference between a good decision and a lazy one is measured in hours of somebody's week.

What I actually do

The job has three parts and they feed each other.

The design system. One canvas, one typeface, a fixed accent system, a set of insertable components and a token set that everything renders against. The point is not the library. The point is that the system is enforced by the tools people already use, so being on-brand is the path of least resistance rather than a rule someone has to remember and someone else has to police.

The product work. Data-dense interfaces for expert users: dashboards, reporting, configuration — the kind of screens where the hard part is deciding what not to show. Information architecture, flows, interaction models, and the high-fidelity UI at the end of it. Getting this right takes understanding the business well enough to know which numbers actually change a decision.

The internal tools. This is the part most design leaders do not do, and it is where I spend my most interesting hours. When the same problem keeps arriving at the design queue, I would rather remove the queue than staff it. That instinct is what produced the AI presentation platform, and it is the single highest-leverage thing I have done here.

How I build

I build in code rather than handing over static mockups, and it changes the conversation entirely. Instead of arguing about a Figma file, people use the thing and tell me what is wrong with it. Opinions become evidence, and the decision gets made in a day instead of a fortnight.

The clearest example is the internal presentation platform. I designed the product, wrote the code, wrote the design-system rules it renders against, and built the measurement system that tells us whether it worked. A developer reviews what I write and promotes it to production. It is written up in full in the case studies, including the part I got wrong.

Working this way also means I can be honest with engineers about cost. When I propose something, I have usually already found out what it takes to build, which is a much better position to argue from than conviction.

How I lead

I lead a small design team, and the way I think about the job is that my work is to make the system good enough that nobody on it is spending their week on rework. Consistency should be free. Judgement is what people should be paid for.

I work closely with engineering, sales, marketing and leadership — at an 80-person company you do not get to specialise, and I would not want to. Being close to the business is what makes it possible to argue for the right thing in the company's own language rather than in design vocabulary, which is the only version of that argument that has ever worked for me.