Design systems is where I started, but the work has grown into something broader. I spend as much time thinking about how teams build products as I do on the products themselves. There's no fixed process, just whatever moves the work forward.
Make it easier for teams to build better products, not just make things look better.
Before touching anything in Figma, I try to understand what's actually going on. That means looking at the product as a whole, how different teams are working, and what constraints exist. The UI is usually the last place where problems show up. They tend to start somewhere further back.
Most problems aren't screen-level problems. They're system-level problems.
I prototype early, but not in the static wireframe sense. I build things that actually work, with real inputs and close to real data. AI coding tools let me move fast enough that a working prototype takes roughly the same time as a detailed static spec.
When something behaves like the real product, you find out a lot faster whether the idea actually holds up.
Every piece of work I do needs to fit into something bigger. When I'm designing a component, I'm already thinking about how it'll behave in contexts I haven't designed for yet. Defining states and edge cases early sounds like extra work, but it removes a lot of back-and-forth once things are in development.
A good solution solves the problem. A great solution scales beyond it.
I share work early, even when it's rough. Waiting until something is polished before showing it usually just delays the feedback you actually need. Working prototypes communicate better than static mocks, so I lean on them to align with engineers and researchers as things develop.
Product work is only part of it. A lot of my time goes into making the design process itself more effective. That might mean an internal tool, a documentation system, or automating something that was being done manually. The aim is more autonomy for the team, not more things to manage.
Design isn't just about creating outputs. It's about improving the system that creates them.
Introducing a new tool or way of working means nothing if no one adopts it. I put real effort into the rollout: workshops, documentation, and working examples that make it obvious why the change is worth making.
Design systems are never done. I treat them the same way I'd treat any product: something that needs to keep evolving as the organisation changes. The hard part isn't building the system, it's keeping it useful over time without it becoming rigid.
Individual screens are symptoms. The system is where the actual problems live.
A static mock can't tell you if an idea works. A working prototype usually can.
A solution that only solves one problem isn't really a solution.
I'd rather build something functional than hand off a spec and hope for the best.
My job is to make other designers faster, not to become the bottleneck.