02 / Selected workDesign leadership · Organisational change

BlueSG

A UX practice built through proof, not mandate.

BlueSG had no consistent way to bring customer evidence into product decisions. I started with one measurable service problem, then used that result to establish research, critique and design-system practices that teams could repeat without depending on one designer.

Service DesignProduct DesignDesign Leadership
My role
Lead Product Designer — transformation strategy, research practice, facilitation, design system and team development
Scope
2023–2026
Focus
UX maturity · Design system · Research ops
Evidence status
Stage 4 is the achieved state and Stage 5 remains in progress. The NN/g model was used as a diagnostic framework, not as an external certification.
BlueSG product experience visual combining the mobility map, growth metrics and customer participation
Measured organisational and product impact
+12%rental conversion after app revamp
−25%development cost via tokenised components
1 → 4Stage 4 achieved; Stage 5 in progress
01 · Project overview

My role, the team and how success was defined

A short project brief before the detailed story: the setting, my responsibility, the people involved and the outcome we were working towards.

01Business context
A fast-moving B2C EV car-sharing business with a legacy app, complex operations and no established UX operating model.
02My ownership
I set the transformation direction while remaining hands-on across research, service design, product work and design-system delivery.
03Core collaborators
Head of Product, product managers, Engineering, Data, Marketing, Operations and the Customer Relations Centre.
04Success definition
Better customer outcomes, less avoidable delivery effort and repeatable evidence-led decisions that did not depend on one designer.
02 · Problem

What was happening—and why it mattered

Product decisions varied by team, customer feedback was not collected reliably and UX outcomes were absent from leadership reviews. Eight in ten feature requests had no user validation, while 35% of development time went into avoidable fixes.

  • 80% of feature requests had no user validation.
  • 35% of development time was spent fixing avoidable issues.
  • Developer-led decisions created inconsistent journeys and accessibility gaps.
  • No product KPIs captured UX outcomes.

One successful project created permission to change the way the organisation worked. The routines made that change last.

03 · Discovery evidence

Evidence that changed how I understood the problem

Behavioural, operational and qualitative evidence did different jobs. Together, they helped define what the team needed to solve before choosing a direction.

01Customer and CRC evidence

Churn research and support data showed that unresolved service issues were affecting trust as much as interface inconsistency.

Design implication

The first proof point needed to improve a real service outcome, not merely restyle the app.

02Delivery evidence

Teams repeatedly rebuilt patterns and spent 35% of development time fixing avoidable experience issues.

Design implication

Reusable components, design tokens and earlier critique could reduce downstream waste.

03Decision evidence

Most feature requests arrived without user validation and UX outcomes were absent from leadership reviews.

Design implication

Research gates and outcome metrics had to become part of prioritisation—not optional design activities.

04 · Maturity progress

Three stages achieved; the next remains in progress

The NN/g maturity model provided a way to assess behaviour, process and adoption; it was not an external certification. The stages below separate completed change from the work that is still underway.

01Stage 1 → 2Achieved

Start with a problem people already felt

The Customer Relations Centre gave us a visible customer problem and an operational measure. Churn research, interviews and a focused service-design intervention made the value of UX tangible before I asked teams to change their wider practice.

Evidence

Turnaround fell from 1.5 hours to 7 minutes; agent no-reply tickets fell 92%.

02Stage 2 → 3Achieved

Turn the result into a shared method

The CRC post-mortem showed management how research, collaboration and iteration led to the result. From there, we clarified cross-team responsibilities, set a shared voice and tone, and secured support for a broader research and design practice.

Evidence

Design moved from a cosmetic service to an evidence-led product capability.

03Stage 3 → 4Achieved

Make good practice easier to repeat

I introduced a practical Double Diamond SOP, discovery and design critiques, a shared research repository, an always-on participant panel, accessibility standards and a tokenised design system connected to delivery work.

Evidence

Research became reusable, UX metrics reached leadership, and tokenised components reduced development cost by 25%.

04Stage 4 → 5In progress

Move ownership beyond Design

The unfinished part is broader adoption: using customer evidence in more roadmap and operational decisions, helping other functions frame problems in the same way, and measuring whether the practices are actually used.

Evidence

Stage 5 is a direction of travel, not a completed maturity claim.

05 · Decision trail

The choices that shaped the work

The artefacts mattered when they helped the team choose. These are the questions, evidence and decisions behind the final direction.

01
Question

Where could design earn trust first?

Evidence

The contact-centre journey had visible customer pain and measurable operational performance.

Decision

Use a focused service-design win to demonstrate value before proposing organisation-wide change.

02
Question

Should the transformation be a process document?

Evidence

Documentation alone would not change daily product and engineering behaviour.

Decision

Pair the Double Diamond SOP with critiques, workshops, research participation and delivery gates.

03
Question

How could quality scale beyond one designer?

Evidence

Inconsistent UI, accessibility gaps and repeated build work came from fragmented ownership.

Decision

Create shared tokens, components and standards while spreading decision ownership across functions.

06 · Two connected lenses

One problem, viewed through service and product

The operating service and the interface formed one system. Each lens addressed a different part of the same problem.

Service Design

Shaping the ecosystem, hand-offs and operating model.

  • Mapped the organisation, hand-offs and customer-support service
  • Created a repeatable Double Diamond operating model
  • Established a continuous research panel and feedback loop
  • Made UX metrics part of leadership reviews

Product Design

Turning service decisions into clear, usable product behaviour.

  • Built a tokenised atomic design system
  • Introduced accessibility and readability standards
  • Created weekly critiques and reusable delivery patterns
  • Connected research evidence to the product roadmap
07 · Process

How the work moved from uncertainty to a decision

01

Earn trust with one measurable result

The first intervention focused on the contact-centre service, where customer pain and operational performance were already visible. Turnaround fell from 1.5 hours to 7 minutes and agent no-reply tickets dropped 92%.

02

Make the method visible

Post-mortems and stakeholder workshops connected the result to research, collaboration and iteration. We then established a shared voice and tone and a clearer cross-team cadence.

03

Build the supporting infrastructure

A Double Diamond SOP, weekly critique, research repository, participant panel and tokenised design system made the practice easier to repeat during live delivery work.

04

Spread ownership carefully

Customer evidence began to influence prioritisation beyond individual projects. Moving that responsibility further beyond Product and Design is the next stage, not a finished claim.

08 · Operating system

Practices that outlasted the project

Each maturity step left behind a repeatable practice. Together, they gave teams a more consistent way to use evidence in product and service decisions.

01

Double Diamond operating model

A practical SOP explaining when to research, where critique happens, who collaborates and what evidence is needed before delivery.

Structured · iterative · holistic · collaborative
02

Research repository and panel

A shared Miro repository and always-on participant panel made interviews, surveys, usability studies and beta testing easier to repeat.

Reusable insight instead of one-off project research
03

Tokenised atomic design system

Primitive, semantic and component tokens connected Figma decisions with reusable engineering patterns and incremental legacy-product change.

25% lower development cost via tokenised components
04

Critique and learning cadence

Weekly design critique, UX University sessions and regular collaboration rituals made quality and knowledge sharing part of the working week.

Quality became a team habit rather than a final review
05

Experience principles

Delightful, Empowering and Visible became shared experience principles, supported by POUR accessibility guidance and readability standards.

A clearer bar for product and content decisions
06

Leadership visibility

Product analytics, support evidence and UX outcomes were brought into management conversations so experience quality could influence prioritisation.

UX outcomes discussed alongside delivery and business outcomes
09 · Constraints and trade-offs

The constraints that shaped the work

These constraints affected the direction, the order of work and the compromises made with the wider team.

01

No established UX mandate

The tension

A large transformation proposal would have sounded theoretical before teams had seen design improve a real outcome.

My response

I began with a measurable CRC problem, shared the result and used that evidence to open a wider conversation about practice change.

02

Delivery could not pause

The tension

Teams still had commitments to ship while new research and critique habits were being introduced.

My response

We started with lightweight checkpoints at discovery and hand-off, then added rigour as the routines became familiar.

03

A legacy product could not be replaced at once

The tension

A wholesale redesign would have increased cost and delivery risk.

My response

The design system grew around active roadmap work, allowing reuse and accessibility improvements to accumulate over time.

10 · Evidence

What the evidence shows

92%fewer agent no-reply tickets
7 minsupport turnaround, down from 1.5 hours
−25%development cost via tokenised components
Stage 4structured UX practice

Stage 4 is the achieved state and Stage 5 remains in progress. The NN/g model was used as a diagnostic framework, not as an external certification.

11 · Outcome

What changed

01

Customer evidence now informs roadmap prioritisation.

02

Design and Engineering share a tokenised source of truth.

03

Critique, research and learning routines continue beyond individual projects.

04

UX outcomes are discussed with product leadership on a regular cadence.

12 · Reflection

What I learned and would do next

Strongest contribution

My main contribution was connecting an early service result to a repeatable product practice and the infrastructure needed to sustain it.

What I learned

Culture shifted faster when customer and business outcomes were visible, then reinforced through small routines that fitted the working week.

What I would do next

I would baseline adoption earlier and track research coverage, component reuse, accessibility and clear ownership of experience outcomes.

Next case study · BlueSG

Redesigning BlueSG’s customer support service