How I Design
"I don't start with wireframes.I start with the real problem —because the brief is almost never the real problem."
My process isn't a template I apply to every project. It's a way of thinking I've developed across 9 years of designing complex enterprise products — from a 15-year internationalisation problem nobody had cracked, to a POS platform serving 1,500+ organisations, to a data grid used by warehouse managers, finance teams, and payroll officers every single day.Every project is different. But the thinking behind every project follows the same disciplined sequence — discover the real problem, define the right opportunity, design with evidence, validate before committing, deliver with precision.Here's how I work.
Discover first. Always.The brief is never the real problem. Earn trust with evidence.Research beats opinion. Every time. Systems over screens.One pattern that scales beats twenty beautiful pages. Invisible is the goal. Great UX removes friction. It doesn't add decoration. Ground it in reality.Warehouse floors. Finance desks. Real users. Real pressure. Never stop at the interface.The best design decisions happen before Figma opens.
PHASE 1 — DISCOVER
I find the problem nobody wrote in the brief.
Most design briefs describe a symptom, not a cause. Stakeholders ask for more features when users actually need less complexity. They ask for a redesign when the real issue is information architecture. They ask for a new interface when the real problem is a broken workflow nobody has mapped in years.
Before I open Figma, I go looking for the real problem.
What I do in this phase:
I run stakeholder interviews — not to validate the brief, but to challenge it. I conduct user interviews and on-site observations, watching how people actually work rather than how they say they work. I shadow users in real environments — warehouse floors, retail counters, finance desks — because the gap between what people say and what they do is where the most valuable insights live.
I audit the existing product systematically — heuristic evaluations, workflow analysis, support ticket reviews, analytics — building an evidence base that tells me where the real friction is before I form any opinions about solutions.
From my work:
On the Pronto Xi i18n project, discovery revealed that the problem wasn't translation — it was a 15-year-old architectural failure where thousands of UI strings were hard-coded directly into the interface. Every previous attempt had failed because it treated a system architecture problem as a content problem. Discovery changed everything.
On the QuickBooks Gold and Platinum tier project, discovery revealed that users were paying for features they didn't know existed — not because the features were missing, but because the interface never surfaced them at the right moment. The solution wasn't more features. It was smarter contextual design.
PHASE 2 — DEFINE
I reframe the problem before defining the solution.
Once discovery is complete, I synthesise what I've learned into a sharp, evidence-based problem definition — one that the whole team can align around before any design work begins.
​
This phase is where most projects either succeed or fail. If the problem definition is wrong, every design decision that follows is wrong too.
​
What I do in this phase:
I build personas from research evidence — not assumptions or workshop exercises. Each persona captures real goals, real workflows, real frustrations, and a specific definition of success that guides every subsequent design decision.
​
I map current state journeys — not idealised flows, but the actual path users take today, including every workaround, every redundant step, and every moment of confusion. Then I map the future state — what the journey should look like, and what the gap between current and future tells us about where to design first.
​
I define success metrics before designing anything. What does "better" actually mean for this project? Faster task completion? Reduced support tickets? Higher feature adoption? Clearer KPI visibility? Getting specific about outcomes before designing prevents the common failure of shipping a beautiful product that doesn't move the needle.
​
From my work:
On the Pronto Xi POS project, define revealed three completely distinct user groups — retail cashiers, wholesale operators, and store managers — each with different goals, different workflows, and different definitions of success. That insight directly drove the architectural decision to build one platform with three role-based experience layers, rather than three separate applications.
PHASE 3 — DESIGN
I design systems, not screens.
Once the problem is defined and the success metrics are clear, I design. But not screens first — architecture first. Information architecture, user flows, interaction models, component logic — the structural decisions that will make or break the experience regardless of how the final screens look.
​
What I do in this phase:
I run design studios — collaborative working sessions with engineering, product, and business stakeholders — focused on system architecture before UI. These sessions surface technical constraints early, build shared ownership of design decisions, and prevent the painful late-stage discovery that a beautiful design isn't technically feasible.
​
I wireframe at low fidelity to validate structure and flow before investing in visual design. I prototype at the right fidelity for the decision being made — low-fi for flow validation, high-fi for usability testing and stakeholder alignment.
​
I build for the design system from the start — not as an afterthought. Every component I design is built to scale, with documented states, interactions, and governance guidelines. A component that works in isolation but breaks the system is a design failure.
​
I use AI-assisted design tools — Claude AI, Figma Make, and Cursor AI — as core parts of my workflow, accelerating ideation, generating UI variations, and moving from concept to testable prototype faster than traditional methods allow.
​
From my work:
On the Pronto Xi Data Grid project, the design phase began with a complete interaction architecture — mapping every possible user action within the grid before touching visual design. This produced the view management system, the contextual column controls, and the density controls that became the most-used features in post-launch feedback.
On the i18n project, the design phase produced seven interdependent system layers — dictionary architecture, module scanner, translation engine, administrator workflow, live preview, analytics dashboard, and one-click automation — before a single UI screen was designed. The interface followed the system. Not the other way around.
PHASE 4 — VALIDATE
I test assumptions, not just designs.
Validation isn't a checkbox at the end of the design phase. It's a continuous loop that runs from the first wireframe to the final prototype — catching wrong decisions early, when they're cheap to fix, rather than late, when they're expensive.
​
What I do in this phase:
I run moderated usability testing with real users on real tasks — not curated demos with friendly participants. I time task completion, observe where users hesitate, and note every moment where the interface forces them to think rather than act.
I conduct heuristic evaluations against established usability principles — systematically identifying violations that usability testing might miss because users have adapted workarounds.
I run A/B testing where the decision involves genuine uncertainty between two valid approaches — letting user behaviour determine the outcome rather than stakeholder preference.
I present findings to stakeholders as evidence, not opinion — framed in terms of business impact, not design taste. "Users completed this task 40% faster" is a business finding. "This layout looks cleaner" is a design opinion. I speak in business findings.
​
From my work:
On the Pronto Xi Data Grid project, usability testing across five task scenarios produced the finding that became the centrepiece of the entire redesign: users weren't making mistakes because buttons were in the wrong place — they were making mistakes because the interface gave them no confidence about what they were looking at. That insight, surfaced in testing, reframed the entire solution from UI improvement to decision-support system design.
PHASE 5 — DELIVER
I deliver designs that actually get built the way they were designed.
Delivery isn't handing over a Figma file and disappearing. It's ensuring that the design intent survives the implementation process — that what ships matches what was designed, and that the team has everything they need to build it accurately.
​
What I do in this phase:
I write detailed engineering handoff specifications — interaction states, edge cases, error states, responsive behaviour, accessibility requirements — documented clearly enough that engineering doesn't need to interpret or guess.
​
I conduct design QA reviews against implemented builds — comparing shipped code against design specifications and flagging deviations before they reach production.
​
I drive proof of concept testing in staging environments for complex system-level designs — working directly with engineering to validate that the architecture works as designed before full rollout commitment.
​
I maintain design governance documentation — component usage guidelines, design token references, pattern library governance — so the design system remains coherent as the product evolves after delivery.
​
From my work:
On the Pronto Xi i18n project, delivery included driving the POC in the test server — implementing the dictionary system, module scanner, and Google Cloud Translation API integration in the test environment to validate that the one-click automation worked end-to-end before any production commitment was made. That's the difference between a design that gets filed and a design that ships.
THE PRINCIPLE THAT CONNECTS EVERYTHING
Every phase exists to answer one question:
Are we solving the right problem, in the right way, for the right people?
When the answer is yes at every phase — that's when great products get built.
TOOLS & METHODS AT A GLANCE
Research & Discovery
Stakeholder interviews · User interviews · Contextual inquiry · On-site observation · User shadowing · Journey mapping · Heuristic evaluation · Support ticket analysis · Competitor benchmarking · Analytics review
Design & Prototyping
Information architecture · User flows · Wireframing · Interactive prototyping · High-fidelity mockups · Design studios · Design system components · AI-assisted design (Claude AI · Figma Make · Cursor AI)
Validation & Delivery
Moderated usability testing · A/B testing · Design QA · Engineering handoff · POC testing · Accessibility audits (WCAG 2.2 AA) · Design governance · Stakeholder workshops
This process has been applied across Intuit QuickBooks, Pronto Software, and 1,500+ enterprise organisations across Australia and internationally.