Design

Big systems. Small fixes that add up.

My day job is untangling services that grew without a plan. These are the stories behind some of them, with the mess left in.

Where I've worked

15+ years across service design, UX, research and software.

  1. Danske BankChief Designer
  2. FLAGS SoftwareHead of Design
  3. ReviiVRCo-founder, AR/VR agency (15 people)
  4. EON RealityUX lead and global trainer
  5. BarclaysSenior Lead Designer
  6. Novartis & GlaxoSmithKlineSix years of healthcare design

My process

From understanding people to delivering better services.

Good service design isn’t about making a journey map look impressive. It’s about understanding what people need, figuring out what’s getting in their way, and working with a team to make the whole experience better.

I work from discovery to delivery and beyond. I combine service design, UX/UI, research, technology and project management to turn complex problems into services that are useful for people, feasible to build and valuable to the organisation.

The process gives us direction, not a script. I adapt it to the problem, the people involved and what we learn along the way.

  1. Understand the problem.
  2. Design the right thing.
  3. Build it well.
  4. Learn from what happens.

  1. Discover

    Before designing a solution, understand what’s really happening.

    Every project starts with curiosity. What are people trying to achieve? Where does the experience break down? What do customers, employees and the business see differently?

    I combine qualitative and quantitative research to understand the context, not just the interface. That means talking to people, observing real behaviour, reviewing existing data and mapping the wider service ecosystem.

    What I do

    • Align with stakeholders on goals, constraints and research questions.
    • Conduct interviews, contextual research, surveys and usability reviews where appropriate.
    • Analyse analytics, support tickets, feedback and existing research.
    • Map customer journeys, touchpoints, actors and backstage dependencies.
    • Identify accessibility needs, assumptions, risks and knowledge gaps.

    What comes out of it

    • Research findings and evidence.
    • Current-state journey maps and service ecosystem maps.
    • A prioritised set of user problems and opportunities.
    • Shared understanding of what we know, what we don’t know and what to investigate next.

    The principle: Research should reduce uncertainty and change decisions. If it doesn’t, we need to ask better questions.

  2. Define

    Find the right problem before committing to the wrong solution.

    Research creates possibilities. Synthesis helps us decide which ones matter.

    I bring together user needs, business objectives, technical constraints and operational realities to frame a problem the team can act on. I challenge assumptions, make trade-offs visible and help stakeholders agree on what success looks like.

    What I do

    • Synthesise research into themes, needs, behaviours and unmet needs.
    • Identify root causes rather than treating symptoms.
    • Frame opportunities and write clear problem statements.
    • Map assumptions, dependencies and risks.
    • Prioritise opportunities using evidence, impact, effort and strategic fit.
    • Define measurable outcomes and establish a baseline where possible.

    What comes out of it

    • A clear problem statement and design challenge.
    • Prioritised opportunities and agreed scope.
    • Design principles and hypotheses to test.
    • Success metrics, constraints and decision criteria.

    The principle: Alignment isn’t everyone agreeing on everything. It’s making sure everyone understands the problem, the evidence and the decisions ahead.

  3. Design

    Explore possibilities. Make them tangible. Find out what works.

    This is where ideas become experiences people can react to.

    I work across service design and UX/UI, exploring how the end-to-end service should work and what that means for individual interactions. I move between broad system-level thinking and detailed interface decisions, making sure the two support each other.

    What I do

    • Co-create concepts with users and multidisciplinary teams.
    • Explore alternative service models and experience directions.
    • Map future-state journeys and service blueprints.
    • Sketch flows, information architecture, wireframes and interface concepts.
    • Design accessible, consistent UI patterns and reusable components.
    • Prototype important interactions and test risky assumptions early.

    What comes out of it

    • Future-state service journeys and blueprints.
    • User flows, wireframes and interactive prototypes.
    • Design principles, interface patterns and component requirements.
    • Validated concepts and a prioritised backlog of improvements.

    The principle: Don’t fall in love with the first idea. Make the idea testable, learn from it and improve it.

  4. Validate

    An opinion is a starting point. Evidence helps us decide.

    Before investing heavily in a solution, I test whether it works for the people who need it. The method depends on the question: sometimes we need usability testing; sometimes we need to validate the service proposition, operational model or technical feasibility.

    What I do

    • Define hypotheses and clear research questions.
    • Test prototypes and critical user flows with representative participants.
    • Evaluate usability, accessibility, comprehension and task completion.
    • Combine observed behaviour with qualitative feedback and relevant product analytics.
    • Work with engineering and product teams to assess feasibility and delivery risk.
    • Iterate, retest and document unresolved issues.

    What comes out of it

    • Usability findings and prioritised issues.
    • Evidence for or against key hypotheses.
    • Improved designs and documented decisions.
    • A clearer understanding of remaining risks and what needs further validation.

    The principle: Test the riskiest assumptions first. Finding a problem before launch is progress, not failure.

  5. Deliver

    Design only creates value when it works in the real world.

    A great concept is only part of the job. The service has to survive contact with real users, real systems, deadlines, dependencies and operational constraints.

    I work closely with product managers, engineers, researchers, content designers and business stakeholders to translate the intended experience into something that can actually be delivered.

    What I do

    • Break the solution into prioritised, deliverable increments.
    • Clarify requirements, acceptance criteria, edge cases and error states.
    • Document interaction behaviour, responsive layouts, accessibility requirements and component specifications.
    • Collaborate with engineers on feasibility, design decisions and implementation trade-offs.
    • Maintain design consistency through shared components and design-system practices.
    • Review implemented experiences, test critical journeys and resolve design gaps.
    • Track dependencies, risks, decisions and scope changes with the team.

    What comes out of it

    • Delivery-ready designs and implementation guidance.
    • Prioritised tickets and clear acceptance criteria.
    • Agreed milestones, dependencies and release scope.
    • Design QA findings and resolved implementation issues.

    The principle: A design isn’t finished when the mock-up is approved. It’s finished when the intended experience works for people in the actual service.

  6. Measure & Evolve

    Launch is the beginning of the feedback loop.

    Once a service is live, we can learn from what people actually do rather than relying entirely on what we expect them to do.

    I use outcome measures, behavioural data and ongoing feedback to understand whether the service is improving. Then I help the team decide what to fix, what to scale and what to investigate next.

    What I do

    • Compare performance against the agreed baseline and success measures.
    • Review adoption, task completion, error rates, customer satisfaction and operational indicators where relevant.
    • Gather feedback from users, support teams and service operators.
    • Identify friction, unexpected behaviours and emerging opportunities.
    • Prioritise improvements based on impact, evidence and effort.
    • Feed learning back into discovery, design and the product roadmap.

    What comes out of it

    • An evidence-based view of service performance.
    • A prioritised improvement backlog.
    • Recommendations for iteration, investment or further research.
    • Shared learning that improves future product and service decisions.

    The principle: Measure outcomes, not just outputs. Shipping more features isn’t the same as making a service better.

How I work across every phase

The process is supported by a few practices that keep the work grounded and moving forward.

  • People first.Involve users and service teams early, respect different needs and design for accessibility and inclusion.
  • Think in systems.Connect interfaces to the processes, people, policies, channels and technology behind them.
  • Work collaboratively.Bring product, design, engineering, research and operations into decisions early enough to influence the outcome.
  • Make evidence visible.Separate what we know from what we assume. Record decisions, explain trade-offs and revisit hypotheses when the evidence changes.
  • Build for reality.Consider feasibility, maintainability, security, privacy, performance and accessibility throughout design and delivery—not as a final checklist.
  • Keep delivery manageable.Make scope, ownership, milestones, dependencies and risks visible. Deliver in increments and adjust when new information changes the plan.
  • Learn continuously.Share findings, measure outcomes and treat every release as another opportunity to improve.

A process, not a straight line

  1. Discover
  2. Define
  3. Design
  4. Validate
  5. Deliver
  6. Evolve

The sequence provides structure, but real projects rarely follow it perfectly. Testing may reveal a problem with the original brief. Engineering may expose a service dependency we hadn’t considered. New research may change the priorities.

That’s expected.

I move between activities based on risk, evidence and the decisions the team needs to make. I aim to involve the right people at the right time, avoid unnecessary process and make progress without pretending we have all the answers.

My goal is simple: help teams make better decisions, build the right things and create services that work for the people who depend on them.

Companies I've designed for

  • Danske Bank
  • Novartis

Privacy notice