How I work

The products I've designed are different. The way I approach them isn't.

Whether it's enterprise software, AI systems or board games, product design is ultimately the practice of reflecting how people understand the world, work together and make decisions.

Practice 01

Sitting in ambiguity

Understanding the system before designing the interface.

Navigating ambiguity before interface design Hidden systems and mental models feed behaviour and workflow, which in turn shape the interface. Most product work begins at the interface; I tend to start at behaviour and mental models. INTERFACE WORKFLOW BEHAVIOUR MENTAL MODELS HIDDEN SYSTEMS most product work begins here I tend to start here

I love interface design but I rarely start there.

Especially in complexity, I start with assumptions, behaviour and hidden systems - because that's usually where the interesting and persistent problems live.

Practice 02

Building shared understanding

Designing conditions for understanding between teams to emerge.

People often think of design as the interface. But that's far downstream of what I think is one of design's most valuable outputs: shared understanding.

Good products don't emerge because one person has the best idea. They emerge when a group of people finally see the same problem in the same way.

That's why I spend so much time facilitating workshops, creating frameworks, sketching models and building playful exercises. They're not activities that happen around design - they're often the design work itself.

RabbitMQ offsite workshop board RabbitMQ offsite workshop board detail Brain dump-o-matic workshop activity Workshop facilitation snapshot Workshop facilitation snapshot Workshop facilitation snapshot

Product as Play

Over the years I've designed and developed a library of play-based workshop activities that I've used across strategy, product discovery and innovation work.

I use games not because they're fun but because the framing of play is psychologically powerful and neurologically useful. When we play…

  • Certainty is temporarily suspended
  • Fear of failure rescinds
  • People become more curious
  • Hierarchy softens
  • Ideas become easier to challenge
  • Understanding emerges faster
  • Learning is retained longer

It's a critically overlooked tool.

Eventually I found I was being asked to create workshop material faster than I could explain why they worked - so I built a simple framework for others to design them too.

Collection of playful product strategy activities and games
From the library
Meaningful Play canvas for designing learning outcomes in workshop activities
Meaningful Play - the basic canvas I teach (and use myself) whenever I need exercises with genuine learning outcomes, not just engagement.
Practice 03

Naming hidden things

Giving language to overlooked things so they can be discussed.

Being a language graduate and deeply interested in linguistics and semiotics, I give words careful consideration.

That's why one of the most powerful design tools I've discovered isn't visual, it's linguistic. Here's how it works:

Name it into existence From immersion in a messy domain through noticing, naming, and shared mental models to better organisational decisions. 1 Immersion in messy domain 2 Identify hidden, normalised or unquestioned phenomena 3 KEY STEP Give it a name 4 Name becomes a shared mental model 5 Organisational decision-making improves thanks to more visible and consistent thinking

Giving something a name doesn't simply make it easier to reference. It creates a shared mental model that people can interrogate, build on and ultimately use to make better decisions. Some examples of this practice can be viewed as critical moments in my case studies.

In discovery cases, a name is required to literally bring something novel to life. But I've found that even when something is fully known, teams can recognise a phenomenon long before they have a shared way of talking about it.

Shared uncertainty can be investigated. Private uncertainty tends to become politics.

This isn't branding. Or a fondness for memorable phrases. Language changes what groups are able to think about together.

Once something has a name, it stops being a vague feeling and becomes an object that can be questioned, challenged and improved.

Practice 04

Partnering intentionally with AI

Using AI to accelerate exploration while protecting human judgement.

AI doesn't replace my thinking. It multiplies the number of conversations I can have with my design.

Rather than treating AI as an answer engine, I increasingly use it as a thinking partner.

Sometimes it's a researcher. Sometimes a critic. Sometimes a prototyper. Sometimes an engineer. Sometimes I'll make it argue with me until I understand my own thinking more clearly.

That shift has changed my design process far more than any particular model or tool.

Thinking with AI

My favourite tool I built that I keep coming back to is my virtual design crit room, "populated" with my design heroes from differing disciplines (and principles).

I give them a problem or a mockup or a hypothesis and then watch them unpack it. It explicitly upends the question-answer relationship of most AIs and I had to carefully craft the instructions to avoid normal instincts to round off or conclude investigation.

Design Crit Room custom GPT landing page

A custom GPT where I can watch my design heroes argue over my design decisions.

Design Crit Room GPT configuration panel
Round 1 of a design crit conversation
Round 2 continuing the design crit

I rarely ask AI for the answer. I ask it to produce multiple incompatible ways of thinking about the same problem.

I call these techniques "self-disruptive flows" and I find they're essential for maintaining a critical and engaged relationship with AI.

Building with AI

Cursor has also fundamentally changed where my design process ends. Instead of stopping at mock-ups, I increasingly build working products - and while that's fun in and of itself, I do that because interactive software is a much better thinking medium than static pictures.

This can be evidenced in the creation of this portfolio:

Before

Homepage chaos-to-clarity concept - early scaffolding

After

Homepage chaos-to-clarity concept - finished journey

The homepage chaos-to-clarity concept took a long time to get right; Cursor's first pass gave me the scaffolding and information I needed to direct and finetune my thinking.

Before

Event card illustration - early exploration

After

Event card illustration - finished artefact

Each illustration was treated as a story that could be told in different ways before fine-tuning the best story into the finished artefact.

Designing the design

Occasionally the design problem isn't the product; it's the absence of a good thinking tool. In those moments I'll happily spend an hour building a disposable tool if it lets me understand the problem more deeply.

On the homepage, I eventually needed motion-tracking debug and manual keyframe editing to ensure a smooth transition in the headline.

Font keyframe tuner for homepage headline motion
A UI tool to expose motion keyframes in a way that both human and machine could read - after too many "a bit to the left" prompts.
Disposable triage UI for case study image selection
A disposable triage UI to gut-rate case study images and export JSON with rationale - because narrowing assets couldn't be done without changing the case study structure.

Closing thoughts

AI, productive friction and epistemology

The biggest shift recently for me has been philosophical rather than technical.

As execution becomes cheaper, judgement becomes more valuable. We hear that a lot.

Ironically, the judgement that is becoming increasingly valuable is earned through the very frictions that AI is becoming increasingly good at removing.

That's why I think part of becoming an "AI-native designer" is recognising when to accelerate and when to slow down. Because some frictions are great candidates for automating around while others are secretively generative in other areas.

That phenomenon probably deserves a name.

I'll work on that…

Back to top