Ways of Working
How the work gets done
The habits behind every product I lead, from the first conversation to the release after next.
Overview
Eleven habits, one way of working
Every project starts with a clear decision and ends with a system that keeps improving. In between, research keeps the team honest, craft makes complex products feel calm, and AI speeds up the thinking. Each area below is a habit my teams practise on every project.
- 01FoundationTurn a tangled brief into a decision the room can make.
- 02ResearchGround every choice in how people actually behave.
- 03AestheticsUse visual craft to make complex products feel calm.
- 04ExperienceDesign for real moments, under real pressure.
- 05CollaborationBring business, product and engineering in early.
- 06AIUse AI to think faster and test sooner.
- 07ModularityBuild products that grow in phases.
- 08Design SystemsGive every team the same building blocks.
- 09AccessibilityMake every product usable by everyone, by default.
- 10DeliveryHand off cleanly and ship what we designed.
- 11PerformanceMeasure what changed after launch.
01 · Foundation
Turn ambiguity into a decision
Enterprise problems arrive tangled. I untangle them into choices a room can actually make.
In practice
- The problem in one sentence everyone recognises
- The decisions in order, one at a time
- A direction tangible enough to argue with
Before any screen, I ask what the business is trying to change and what it costs if nothing changes. That framing turns a feature request into a problem worth solving.
While stakeholders explain a system, I map the flow in my head and ask about the points where it breaks. Red flags surface in the first meeting, well before the last sprint.
02 · Research
Design as behavioural science
Every pattern earns its place through evidence.
In practice
- Field and contextual research
- Usability testing
- Behavioural and cognitive principles
Research starts where the work happens: with the people who use the product, in the places they use it. Teams watch people use the product, note where they hesitate, and bring that evidence into every design review.
Findings go into a shared synthesis, so product, engineering and data teams design for the same people. Research continues after launch too: concepts are tested at every sprint, and pilots run with real users before wider rollout.
03 · Aesthetics
Craft that makes complexity feel calm
Visual quality is part of usability. A clean, consistent interface makes dense information easier to read and act on.
In practice
- A clear hierarchy, with what needs action first
- Whitespace and type that give data room to breathe
- Consistency across every screen and release
I hold a high bar for visual quality and consistency, and I coach designers to treat every visual choice as a decision with a reason behind it. One designer on my team credits me with showing how whitespace alone can make a design feel clean, professional and purposeful.
The craft has to serve people and the business at the same time. Visuals are tested with real users and refined to meet real deadlines, with the vision intact.
04 · Experience
Designed for real moments
People use these products between store visits, on a factory floor, or at 3am with a newborn. The experience has to fit that moment.
In practice
- Journeys mapped around stages and emotions
- Progressive disclosure: the next step first, the detail after
- Support that builds confidence as people learn
I design for the state people are in as well as the task in front of them. That can mean organising a product around the stages people go through, with the tone and level of detail changing at each one.
I also watch for over-guidance. Products that steer people through every step can leave them stuck when something unexpected happens, so my teams design support that people can gradually rely on less.
05 · Collaboration
Partners in the room from day one
Almost none of the work happens alone. It happens with product owners, engineers, analysts and executives, on products no one owns by themselves.
In practice
- Engineering and data teams involved from the start
- Weekly reviews that keep stakeholders aligned
- Open brainstorms that bring the whole team into hard problems
I run design as a shared process. Engineers join early, so every solution is buildable, and regular reviews keep the work moving with stakeholders’ confidence.
The payoff is fewer surprises late in delivery. One business partner described my team’s ability to capture their needs and craft a design with very few edits.
06 · AI
AI as a thinking partner
AI runs through the whole journey, from reading the brief to testing ideas before release. People still make the calls.
In practice
- Requirement & ecosystem analysis
- Research & data synthesis
- Rapid prototyping and assumption testing
My teams use AI to understand business scope and ecosystems faster, synthesise KPIs, system logs and large sets of interviews, sharpen content and catch what might have been missed, and build quick prototypes that test assumptions before anything ships.
On the product side, I’ve led five AI and LLM projects at PepsiCo, exploring GPT-powered workflows with people kept in the loop. The rule is the same in both: use AI where it adds real value to users, and leave it out where it doesn’t.
07 · Modularity
Built to grow in phases
Enterprise products keep changing after launch, and every market works a little differently.
In practice
- Capability zones mapped to clear user intents
- Phased rollouts with few dependencies
- Measure, learn, iterate
I structure products as modules that each serve one clear intent and connect to their own services. Teams can then ship in phases, start small and add capability without rebuilding what’s already there.
When research time is short, the structure carries the weight: clear intents and phased delivery leave room for the product to keep learning.
08 · Design Systems
One set of building blocks
A shared design system lets many teams ship consistent products quickly.
In practice
- Reusable components and token-based theming
- Documented interaction standards
- Design-to-code workflows with engineering
When a product moves to a new platform, the team extends the design system for it, with platform-native components and standards engineering can reuse.
At PepsiCo, I’ve also piloted Builder.io to streamline design-to-code workflows, so designers and engineers work from the same source of truth.
09 · Accessibility
Accessible by default
Global teams work in different conditions and with different abilities, so accessibility is built in from the first sketch.
In practice
- A WCAG 2.2 accessibility-first framework
- ADA-compliant patterns in the design system
- Accessibility checks in every design review
I introduced a WCAG 2.2 accessibility-first framework at PepsiCo, expanding usability for diverse global teams. The standards live in the design system, so every team gets them without extra effort.
The habit goes back to my early healthcare work, where designs for major US providers had to meet strict accessibility compliance.
10 · Delivery
Shipped the way it was designed
A design only counts once it’s live, so my teams treat delivery as part of the design work.
In practice
- Design runs a sprint or two ahead of build
- Annotated handoff in Figma, with specs, states and edge cases
- Design tracked in the same sprints as engineering
- Design QA on built screens before every release
Running design a sprint or two ahead means engineers always have reviewed work ready to pick up, and releases stay predictable. Handoff files are annotated in Figma with specs, states and edge cases, and design tasks sit on the same sprint boards as engineering, so everyone sees the same progress.
Before anything ships, designers review the built screens against the design and log what’s off. Small gaps get fixed while they’re still small, and the product people use is the product we designed.
11 · Performance
Measured long after launch day
I want to know whether a product actually worked, so my teams measure it against where we started.
In practice
- A baseline before design starts
- Pilots instrumented with heat maps, click tracking and error logging
- Satisfaction and adoption tracked against the baseline
- Findings fed into the next release
Pilots run with real users before rollout, instrumented with heat maps, click tracking, error logging and stress tests in real conditions, and what we learn goes into the final refinement.
After launch, satisfaction and adoption are tracked against the baseline, and the product keeps improving based on how people actually use it.
Building something complex? Let’s talk.