# Case studies — gaganmalik.io

Last-Updated: 2026-07-13

## Case studies

### Simplifying sales reporting (Apple)
[View case study](https://www.gaganmalik.io/en/success-stories/apple)

[Retrieval brief — apple-sales-reporting-ai]
Category: technology
Thesis: A unified mobile-first sales analytics app replaced eight fragmented tools and gave field and leadership one source of truth with offline trust.
Answers: What did Gagan do at Apple? | How did Gagan unify Apple sales reporting? | Why does mobile-first analytics matter for field sales organisations?
Implication: Consolidate fragmented reporting before adding AI; design offline and last-sync states where the job is airports and shops.
Proof: Eight apps replaced by one dashboard; 78% of opens outside office hours (pilot markets); Weekly reconciliation meetings fell directionally per territory; 150K users in sales organisation
Concepts: enterprise analytics, mobile-first, single source of truth, field sales

**The account executive is in a retail store and leadership wants the number now.** Eight apps meant eight versions of the truth: hardware revenue in one tab, services attach in another, channel mix somewhere else. Field teams reconciled spreadsheets in airport lounges while partners waited. The opportunity was one live picture everyone could trust, with answers in the app instead of attachment chains.

**The Opportunity** — Eight tools, no shared truth for performance questions
Apple's global sales organisation ran on a patchwork of tools. Teams across major regions jumped eight apps for basic performance questions: hardware revenue, services attach, channel mix, quarterly targets. Figures did not always match, field work slowed, and nobody had one live view that tied hardware, services, and channel together.

The job-to-be-done was clear: give account executives, leadership, and partners one source of numbers they could trust for demand conversations and quarterly plans. I led discovery that included field interviews across regions, shadowing sales calls, and mapping the reconciliation work people did weekly. Success meant fewer debates over which spreadsheet counted and more time on execution.

**The Solution** — One mobile-first analytics app: same numbers for field, leadership, and partners
I designed a mobile-first sales analytics app so fragmented data lived in one place for field teams. Three options were considered. A web dashboard that required VPN and a laptop: rejected, because account executives work from airports and retail floors, not desks. A read-only mobile view of existing tools: rejected, because it would perpetuate the eight-app problem. A unified mobile-first app with offline support and role-based views: what I shipped.

I owned the key UI decisions: dashboards that drew the same numbers for every product line, region, and channel; analytics layers that supported quarterly planning with drill-down by territory and SKU; channel views that let account executives see distributors, carriers, and retail side by side; reporting that replaced hand-built spreadsheets with up-to-date figures for spotting gaps. I integrated the app with Apple's existing CRM and designed offline modes with explicit last-sync states so account executives could trust cached territory numbers without VPN at airports and retail floors. That pattern later explained why most opens happened away from desks. I validated the design through field pilots in three markets before global rollout.

**The Impact** — One live view replaced eight tabs and cut weekly debates over the numbers
One app replaced the habit of checking eight systems and disagreeing on the figure. Account executives saw the same real-time picture as leadership, so demand conversations and channel plans started from shared data. Partner briefings matched what executives saw without reconciliation drag.

Less time matching spreadsheets meant more time on planning and execution; field plans could stay aligned with quarterly goals because everyone started from the same screen. Because I unified hardware, services, and channel into one mobile dashboard with offline cache and last-sync states, account executives checked one screen instead of rebuilding spreadsheets before partner calls, explaining why 78% of app opens happened outside office hours and weekly reconciliation meetings per territory fell by roughly half (directional, pilot markets).

Takeaways:
- One source of truth removes most of the reconciliation work that slowed decisions.
- Mobile-first with offline coverage matters when your job is airports and shops, not desks.
- When leadership and the field read the same dashboard, plans stop arguing with each other.

---

### Better onboarding and activation (Google)
[View case study](https://www.gaganmalik.io/en/success-stories/google)

[Retrieval brief — google-product-activation]
Category: business
Thesis: Segmented activation email by stall point and CMS beat generic welcome blasts for publisher onboarding.
Answers: What did Gagan do for Google publisher activation? | How does Gagan approach product activation and onboarding?
Implication: Segment onboarding by behaviour and stall point; show the expected outcome in the first screen of each email.
Concepts: activation, onboarding, email journeys, publishers

**The snippet sits in your clipboard and the revenue line stays flat.** Auto Ads could find inventory site owners missed, but most publishers never finished setup. One tag, scattered docs, and a black-box story about ML meant capable tools sat idle while manual placements felt safer. The job was not to explain the algorithm louder. It was to meet each publisher where they stalled and get them to the first impression.

**The Opportunity** — Two million publishers, one snippet, and a 58% cliff before the first ad shows
Auto Ads used machine learning to place ads and surface inventory owners overlooked, yet adoption lagged behind the product's depth. The integration was a single snippet, but it read opaque if you did not ship code every day. Manual placements stayed familiar; the ML path sounded like a gamble you could not verify from a kitchen table on a Sunday night.

My JTBD research surfaced three blockers: unclear value (why trust ML over hand-placed units?), technical confusion (where does the snippet actually go on WordPress versus a custom CMS?), and verification anxiety (how do I know it is working?). Support tickets showed 'Auto Ads not showing revenue' as the top activation issue. Publisher surveys found 68% did not understand the difference between Auto Ads and manual placements. Funnel analysis showed 58% drop-off between copying the snippet and seeing the first ad impression.

Constraints were strict: no in-product UI changes, email-only intervention. Messages had to work across WordPress, custom CMS builds, and static sites. Success metric upfront: activation above 35% within 30 days of signup.

**The Solution** — Three emails for three stalls: explain, paste, prove
I closed the gap with segmented email so each publisher saw copy matched to where they were stuck, not a generic welcome blast. A single email to all signups could not serve technical and non-technical owners equally; platform diversity across WordPress and custom stacks ruled out an in-product tutorial overlay. I shipped a behaviour-led email journey segmented by signup source and stall point.

Each email had a fixed layout hierarchy: subject line named the stall ('Paste your snippet in 3 steps'), hero screenshot showed the expected outcome (revenue line moving), numbered steps with CMS-specific screenshots, and a single primary CTA ('Verify in reporting') so publishers knew what to do next without opening docs.

I wrote the first email to explain what Auto Ads actually did, with side-by-side examples of ML placements next to manual ones. I wrote the second, sent to publishers who read the docs but never pasted, to walk through code placement with screenshots for common CMS platforms. I wrote the third, sent to those who pasted but saw no impressions, to cover reporting verification and troubleshooting. I wrote follow-ups that carried publisher proof (for example Sarah increasing RPM 28% without touching placements) and deeper technical paths for owners ready for mobile anchor ads, AMP, and cross-device setups.

I validated before scale. A/B tests on subject lines, send timing, and technical depth ran against 50K publisher cohorts before full rollout.

**The Impact** — From 22% to 41% activation, with 35% fewer setup tickets
Activation climbed from 22% to 41% within 30 days of signup after the segmented programme launched, clearing the 35% target I set upfront: segment 2 (paste instructions) recovered the largest stall cohort, and segment 3 (verify impressions) converted publishers who had pasted but never saw revenue move. Support tickets tied to Auto Ads setup dropped 35% quarter-over-quarter because screenshots replaced abstract ML copy at each stall point.

Segmenting email by stall point with CMS-specific paste steps and reporting verification screenshots lifted activation from 22% to 41% and cut setup tickets 35% quarter-over-quarter. The same segmentation patterns later applied to matched content and in-feed ads with similar lift.

Takeaways:
- Segmented email meets publishers at the stall point, not at signup vanity.
- 22→41% activation and −35% setup tickets followed stall-mapped email layout.
- Peer revenue proof beats feature lists when trust is the real blocker.

---

### Orderpad UX audit (research → design spec) (Just Eat)
[View case study](https://www.gaganmalik.io/en/success-stories/just-eat)

[Retrieval brief — improving-restaurant-order-tracking]
Category: design
Thesis: Five-brand heuristic research with live kitchen observation replaces opinion with fundable backlog priorities for partner UX.
Answers: What did Gagan do at Just Eat? | How does Gagan run competitive UX audits for marketplaces?
Implication: Score competitors on one rubric during live service; attach survey percentages finance can sequence.
Proof: Orderpad ranked last in five-brand roll-up; 82% wanted Partner Centre access from Orderpad; 56% wanted driver visibility on busy nights
Concepts: UX research, heuristic evaluation, marketplace, B2B

**Saturday night: three tablets, one counter, and nobody sure which order the rider is collecting.** Restaurant teams run Just Eat's Orderpad beside rival apps on the same surface. When a phone line, a rider app, and multiple aggregators compete for attention, staff reach for the tablet that makes the next step obvious. Just Eat asked for a side-by-side review against Deliveroo, Uber Eats, Grubhub, and SkipTheDishes to see where friction appeared first.

**The Opportunity** — Growth rode on counters where Orderpad lost the five-brand comparison
Just Eat's partner base depended on small kitchens tolerating chaos. Orderpad could accept orders, but it often failed to show where each ticket sat in the flow, when food needed to be ready for handoff, or what tapping 'On Its Way' committed to downstream. Teams worked around those gaps; the cost showed up as late deliveries, support calls, and poor reviews.

My JTBD research identified three frustrations: unclear order status (prep versus ready versus collected), no direct access to Partner Centre tasks (hours, radius, pricing) during service, and weak driver visibility compared to rivals. I led discovery that included in-restaurant observations during live shifts (Friday and Saturday nights, lunch rushes), partner surveys via Qualaroo in-product pop-ups, and a Nielsen heuristic framework [NN/G heuristics](https://www.nngroup.com/articles/ten-usability-heuristics/)::pill applied across five brands.

Constraints: audit only, no implementation commitment. Recommendations had to separate quick wins from structural changes requiring policy or contract shifts. **Out of scope for this engagement:** Orderpad pixel changes, A/B tests, or production UI. The deliverable was research, prioritisation, and a design spec for backlog funding.

Success metric upfront: one scoring sheet all stakeholders could point to, with partner survey percentages finance could fund against.

**The Solution** — Same rubric across five brands: walkthrough, survey, live shift
I structured the audit around six Nielsen-based review areas: system status visibility, fit for kitchen work, control and speed, recognition over recall, layout clarity, and error recovery. The same rubric ran across Just Eat, Deliveroo, Uber Eats, Grubhub, and SkipTheDishes so results were directly comparable.

Three audit scopes were considered. Product walkthrough only: rejected, because it missed real operating conditions. Partner interviews only: rejected, qualitative feedback was abundant but unfunded. Combined product analysis, surveys with percentages, and live observation: what I shipped.

I paired product walkthroughs at realistic order volumes with competitor benchmarking on the same six heuristics. Deliveroo and Uber Eats showed live driver maps and explicit prep→ready→collected timelines; Grubhub and SkipTheDishes surfaced Partner Centre shortcuts from the order screen. Those were the patterns Orderpad lacked on status visibility and in-flow partner tasks.

Qualaroo in-product surveys captured importance ratings for specific features. In-restaurant observation during live service covered noise, rush periods, and multilingual teams. The output was one scoring sheet showing Just Eat ranked last across the five brands, theme briefs with screenshots on status visibility, Partner Centre access, and driver tracking, and a prioritised readout separating quick fixes (clearer button labels) from business-level decisions (opening Partner Centre API to Orderpad required cross-functional alignment).

I specified a recommended status rail — prep, ready, collected, driver en route — as the design target when Orderpad could not show where a ticket sat during live service. That spec became the bridge from audit to backlog: finance could size 82% Partner Centre demand and 56% driver-visibility demand against a concrete UI pattern, not a theme label alone.

Field validation was the point. Kitchen visits during real service caught what desk walkthroughs missed: which status gaps cost seconds when the rider was already at the door.

**The Impact** — Orderpad ranked last, with 82% and 56% survey counts finance could fund
Across Deliveroo, Grubhub, Uber Eats, SkipTheDishes, and Just Eat, the combined heuristic roll-up put Orderpad last. That was uncomfortable in the room, but it replaced opinion with one curve everyone could point to: the gap ran across status, fit to kitchen reality, control, and recovery, not a single bad icon.

In-product surveys showed 82% of partners rated reaching Partner Centre from Orderpad as important. 56% wanted a clearer view of drivers on busy nights, while optional driver tooling sat at almost no adoption next to rivals who ship live tracking by default. Those numbers turned 'they keep asking' into backlog pressure with a size on it.

Nothing in an audit ships pixels by itself. What shipped was clarity: ranked themes, a cut between work that could ride normal release cadence and work that needed brand or policy concessions, and constraints spelled out so roadmap bets matched what ops could open and what contracts allowed.

Impact for this engagement is measured in **research outcomes**, not conversion: a funded backlog sequenced by partner survey weight, a single five-brand curve stakeholders could point to in prioritisation, and a status-rail design spec ready for implementation when policy allowed Partner Centre access from Orderpad.

Because the recommended status rail named prep→ready→collected→driver en route explicitly, stakeholders could size backlog against expected kitchen behaviour (fewer 'where is this order?' moments during rush) rather than a vague 'status' theme. That clarity is why 82% Partner Centre demand and 56% driver-visibility demand converted to sequenced roadmap bets. Because I scoped the engagement to research and design spec only (no Orderpad pixels or A/B), the deliverable stayed honest: funded backlog and a concrete UI target, not implied conversion lift.

Takeaways:
- A shared score across five brands beats slide battles when every team has a different favourite fix.
- 82% Partner Centre and 56% driver visibility — survey percentages finance could sequence.
- Audit scope was research and spec only; no Orderpad pixels or A/B shipped in this engagement.

---

### Gamified car insurance (Aviva)
[View case study](https://www.gaganmalik.io/en/success-stories/aviva)

[Retrieval brief — aviva-gamified-car-insurance]
Category: business
Thesis: Gamification in insurance works when badges and scores tie to real premium outcomes, not engagement for its own sake.
Answers: What did Gagan do at Aviva? | How did Gagan design gamified car insurance at Aviva?
Concepts: insurance, gamification, safe driving, premium value

**The premium quote still prices you by postcode, not by how you drove home last night.** UK motor cover leaned on coarse segments: safer drivers paid like risky ones because price was not tied to trips on the road. Aviva saw a chance to differentiate with behaviour-based pricing and engagement: reward safer driving and make insurance feel personal instead of punitive.

**The Opportunity** — Demographic buckets masked real driving risk on the road
UK car insurance still leaned on broad demographic buckets: safer drivers often paid like risky ones because price was not tied to trips on the road. Most people think they drive better than average, so flat stereotypes felt unfair and missed real risk. Aviva needed a signal from the vehicle, not only the postcode on the form.

My JTBD research showed two core needs: young drivers wanted a fair chance to prove safe behaviour and lower premiums; families wanted transparency on what behaviours actually affected price. I led discovery that included ride-alongs with telematics pilot users, surveys with 2,000+ drivers, and competitive teardowns of black-box hardware programmes. Constraints: app had to work on iOS and Android without specialist hardware; scoring needed to feel fair and explainable; the app had to connect directly to Aviva's quoting and policy systems, passing a driver's score to the quote engine at conversion without manual re-entry. Success metric: at least 30% of users qualifying for discounts within 200 miles, with positive ROI within two years.

**The Solution** — UK-first smartphone telematics: score the trip, quote from behaviour
I led design for the UK's first smartphone-based telematics app, pricing cover from how people actually drive. Three options were considered. Black-box hardware installed in vehicles: rejected for installation friction and cost. OBD-II dongles: rejected for limited vehicle compatibility. Smartphone GPS and sensors: what I shipped. Any driver with a smartphone could participate without hardware installation or vehicle compatibility limits.

I owned the key UI decisions: the app used GPS to log acceleration, braking, cornering, speed, and phone use over 200 miles. Drivers got a 1 to 10 score, quick feedback after each trip, optional sharing with family, and a direct path into a quote. I designed trip breakdowns to show star ratings for braking, acceleration, cornering, and phone use so drivers saw where behaviour improved, not just a single headline score. I designed a badge system that recognised milestones (first 200 miles, 30-day safe streak, night driving mastery).

I validated through beta testing with 5,000 drivers across urban and rural routes; A/B tested badge visibility (visible badges increased 200-mile completion by 18%); tested score explanation copy with non-technical users to ensure fairness perception.

**The Impact** — Downloads above plan, measurable savings, brand lift on invention
Aviva Drive passed 1M downloads in about six weeks, well above the annual plan, picked up Apple's 'App of the Week', and held around 4.5/5 in the store. Roughly four in ten users scored 7.1 or above and saved about £101 on average; most people in the programme qualified for some discount.

Because I designed trip breakdowns with star ratings per behaviour and visible badges for milestone progress, drivers corrected braking within three trips and 18% more completed 200 miles when badges were visible in beta, feeding discount qualification at scale and turning the business case positive inside two years. Perception of Aviva as inventive moved up by 33 points, so telematics read as a practical product bet rather than a short campaign.

Takeaways:
- Behaviour-based pricing rewards actual performance instead of demographic assumptions.
- Visible badges and per-trip star ratings drove 18% more 200-mile completions in beta.
- Smartphone telematics can reach positive ROI within two years at scale.

---

### From Hold to Handled (Lloyds Banking Group)
[View case study](https://www.gaganmalik.io/en/success-stories/lloyds-bank)

[Retrieval brief — lloyds-from-hold-to-handled]
Category: business
Thesis: Self-serve insurance with progressive disclosure and one design system across four brands cut contact-centre handle time and shifted volume to digital.
Answers: What did Gagan do at Lloyds Banking Group? | How did Gagan reduce insurance call centre handle time at Lloyds? | What is progressive disclosure in regulated self-serve flows?
Implication: Invest in one cross-brand pattern and rule-based flows before bespoke per-brand UX; measure digital self-serve share and resolution time.
Proof: ~75% resolution time reduction on targeted call types; 60% digital self-serve within six months; 80%+ amendment completion across four brands; 26M+ users served
Concepts: banking, insurance, self-serve, design system, contact centre, progressive disclosure

**Twenty minutes on hold to change an excess while the kettle boils twice.** Lloyds Banking Group's home insurance contact centres carried amendments, cancellations, and policy queries that ate most of the day. Customers wanted cover changed without the wait. Agents wanted policy truth without tab-hopping across four brands. The opportunity was one pattern that put accurate policy actions in front of staff and customers at once.

**The Opportunity** — Three call types, 250 FTEs, and resolution stretching past fifteen minutes
The UK's largest retail bank faced acute pressure in home insurance contact centres: high volume, rising cost, frustrated customers. Three call types (amendments, cancellations, policy or cover queries) consumed nearly 75% of total handling time and over 250 FTEs. Average resolution ran from about six minutes to well over fifteen, leaving little slack for good service.

My JTBD research identified three needs: customers wanted to amend cover (add contents, change excess) without 20-minute waits; agents needed faster access to policy details during calls; operations needed consistent data capture across four group brands. I led discovery that included contact centre shadowing across Halifax, Lloyds, Bank of Scotland, and MBNA, call recording analysis on repeat questions, and stakeholder mapping showing each brand on different back-end systems.

Constraints: no changes to core policy admin systems; flows had to work for all four brands with minimal forking; regulatory compliance required specific disclosures at amendment. Success metric: handling time reduction above 60% for target call types, with digital self-serve crossing 50% within six months.

**The Solution** — One design system, rule-based flows, volume shifted to digital
As design director I led strategy and team coordination and owned hands-on design of progressive disclosure on amendment flows, asking for information only when the customer's path required it. Bespoke flows per brand would have put Halifax, Lloyds, Bank of Scotland, and MBNA on diverging maintenance paths with inconsistent experiences. Generic CRM forms with agent scripting would have perpetuated hold times. I built one design system with rule-based flows for self-serve and agent use across all four brands.

I aligned the team on shared components, validation patterns, and error states so updates propagated across all four brands without rework. I designed amendment flows to open with one question ('Do you have your policy number?'), then branched to collect only relevant fields. I carried clear next steps in mobile-first layouts, disabled primary actions until forms were complete, and plain-language summaries before submission.

Self-serve for policy queries reduced phone volume without pushing complexity onto customers. Agents stayed free for fraud, claims disputes, and vulnerable customer support. I prototyped quickly and tested with 200+ people across all four brand customer bases before rollout. Rule-based routing meant the first payload matched how dispatch and servicing were sequenced, not a generic CRM shape agents had to rewrite.

Validation started in the field. Pilot launched with Halifax first (highest volume), instrumented handling time and completion rates, then rolled to Lloyds, Bank of Scotland, and MBNA sequentially.

**The Impact** — 75% cut in resolution time, 60% digital self-serve in six months
Lloyds moved the heaviest insurance jobs into digital self-serve: the same routes that had consumed three-quarters of handle time. Average resolution time fell by about 75% for targeted call types. Digital self-serve crossed 60% within six months, exceeding the 50% target.

Because I designed progressive disclosure on amendment flows (one starter question, then only relevant fields), customers completed amendments in under four minutes on mobile instead of fifteen on phone, and agent satisfaction improved as teams handled judgement-heavy work instead of repetitive data entry. Completion rates on amendment flows stayed above 80%. Directionally, the programme freed capacity equivalent to roughly 60 FTE across targeted call types as volume shifted to digital self-serve.

Takeaways:
- 75% resolution time cut and 60% digital self-serve within six months on targeted call types.
- Progressive disclosure kept amendment completion above 80% across four brands.
- One design system across four brands cut rework without flattening brand identity.

---

### Better product discovery (EE)
[View case study](https://www.gaganmalik.io/en/success-stories/ee)

[Retrieval brief — ee-global-navigation-redesign]
Category: design
Thesis: Tree-tested information architecture with three clear buckets beat relabelling eight menus for telecom task success.
Answers: What did Gagan do at EE? | How did Gagan redesign EE global navigation? | When should a CEO fund tree testing over stakeholder opinion?
Implication: Run tree tests on high-frequency tasks before IA debates; structure nav around jobs (Shop, My EE, Help) not org charts.
Proof: 200+ tree-test participants; 20 high-frequency tasks validated; Three-bucket IA (Shop, My EE, Help)
Related essays: pmf-is-not-a-funnel
Concepts: telecom, information architecture, tree testing, navigation

**The shopper needs the coverage checker and the site offers eight menus with overlapping labels.** EE's navigation buried key tasks under ambiguous names: coverage, upgrade paths, and account help often meant three wrong clicks or a call to support. Tree testing showed where the structure failed; task success scores gave us the mandate to regroup.

**The Opportunity** — Shoppers lost in eight top-level menus with overlapping labels
EE ran eight top-level navigation items with unclear boundaries: 'Why EE', 'Network', 'Help', and five product categories competed for attention. Customers hunting for coverage, upgrade eligibility, or account help often clicked three menus before finding the right path or abandoned to call support.

My JTBD research identified three core missions: shopping for devices and plans, managing existing accounts (My EE), and getting help and network status. I led discovery that included clickstream analysis showing high bounce rates from nav, support ticket tagging revealing 'could not find coverage checker' as a top issue, and stakeholder workshops mapping business priorities against customer intent. Constraints: rebrand was launching in parallel so nav had to accommodate new product naming; back-end content management required minimal restructuring. Success metric: task completion rates above 70% for top ten customer journeys.

**The Solution** — Tree testing first, then three buckets: Shop, My EE, Help
I ran tree testing with 200+ participants across twenty high-frequency tasks (finding coverage checker, comparing pay monthly plans, checking network status, understanding upgrade eligibility). Three options were considered. Keep eight menus with relabelling: rejected, because tree tests showed structural confusion, not only labelling issues. Mega-menu with all options visible: rejected for mobile complexity. Three clear buckets (Shop, My EE, Help) with supporting sub-navigation: what tested highest for task success.

I owned the key IA decisions: 'Shop' carried all acquisition paths (phones, SIM-only, broadband, business); 'My EE' grouped account management, bills, and upgrades for existing customers; 'Help' contained network status, coverage checker, contact options, and troubleshooting. I moved coverage checker from buried under 'Why EE / Network' to visible under 'Help', I validated through card sorting with 150 participants. Sub-navigation used consistent patterns: product type, then contract type, then device or add-ons.

Validation approach: tree testing showed task success improvement from 52% to 78% for coverage tasks, 61% to 82% for upgrade paths, and 48% to 74% for network status checks. A/B tested the redesign in prototype with 300 users before production rollout.

**The Impact** — Task success up 26 points average; coverage and help calls down
Tree testing and task success scores gave us clear evidence: the three-bucket structure improved completion rates across all twenty tested tasks. Coverage checker usage increased 34% in the first quarter after launch because I moved it from buried under Why EE / Network to Help › Coverage checker: the same IA change that raised task success on coverage tasks from 52% to 78% in tree tests. Support contacts related to 'cannot find information online' dropped 22% in the same period.

Because I moved high-intent tasks into Help where shoppers already look, average clicks to task completion fell from 4.2 to 2.8 across measured journeys, cutting support noise without over-promising on acquisition (Shop conversion improved a modest 3–4 points consistently across mobile and desktop).

Takeaways:
- Tree testing and card sorts pay off when navigation carries most of the discovery job.
- Moving coverage checker to Help drove +34% usage and −22% 'cannot find' contacts.
- Three buckets beat sprawl when shoppers need My EE, Shop, and Help without guessing.

---

### Faster checkout (John Lewis)
[View case study](https://www.gaganmalik.io/en/success-stories/john-lewis)

[Retrieval brief — john-lewis-faster-checkout]
Category: business
Thesis: Discovery and checkout UX with defensible attribution tied filters, Quick View, and mobile checkout to measurable incremental revenue.
Answers: What did Gagan do at John Lewis? | How did design drive revenue at John Lewis? | How does Gagan attribute product discovery improvements to P&L?
Implication: Split attribution across discovery and checkout workstreams; instrument time-to-basket and completion, not vanity engagement.
Proof: £8.2M incremental revenue (attributed year measured); 40/45/15 discovery attribution split; +9pp mobile checkout completion; NPS +8 on ease of finding products
Concepts: retail, eCommerce, discovery, checkout, attribution

**Four hundred thousand products and the right washer still hides on page six.** John Lewis shoppers loved the range across home, fashion, and electronics, but discovery dragged and checkout added friction on the device most visits used. The brief was speed without shrink: keep the catalogue that defines the brand, lose the dead ends that sent people elsewhere.

**The Opportunity** — A £15B catalogue where loyalty met filter fatigue
John Lewis runs more than 400,000 SKUs online. Loyal shoppers still stalled in category depth: filters failed to surface the right stock quickly, and Quick View stopped short of a confident buy. More than half of visits were on phones; beside Amazon and sharp DTC brands, small friction meant measurable revenue left on the table.

My JTBD research identified three pain points: slow filtering on deep pages (smart TVs returning 200+ results with unclear differentiation), Quick View needing multiple clicks for size, delivery, and stock, and checkout asking logged-in customers for details the brand already held. Session recordings showed filter abandonment patterns. Exit surveys flagged 'too hard to compare products' as a top frustration. Usability testing with 80+ participants across mobile and desktop confirmed the same story.

Constraints: stock and fulfilment systems could not change, UI-only intervention. Brand guidelines required premium look-and-feel throughout. Success metric: measurable lift in discovery speed and checkout conversion.

**The Solution** — Filters with memory, Quick View that finishes the job, PDPs that front-load trust
I ran three workstreams in parallel: filtering with live counts and saved combinations, Quick View with size, delivery, and add to basket in the overlay, and product page hierarchy that surfaced key specs earlier. Each workstream had rejected paths. Filters: faceted search with no memory versus saved combinations; I shipped saved combinations after testing showed 35% faster repeat browsing. Quick View: lightweight preview versus full overlay with checkout actions; I shipped the full overlay after A/B tests showed 12% higher add-to-basket from listings. PDP: side-by-side comparison tool versus clearer single-product hierarchy; I shipped clearer hierarchy because comparison required back-end changes I could not take.

I designed filters to show live counts before apply. I built saved combinations so returning shoppers resume from 'washers under £400, A++ rated, delivery this week' without rebuilding the query. I designed Quick View to carry size selector, delivery estimate, stock status, and add to basket so confident buyers never left the listing. Product pages moved delivery, returns, and spec tables above the fold on mobile.

**Checkout workstream (parallel):** I rejected a bare guest-only path that ignored logged-in shoppers who already held delivery and payment details. I shipped a three-step mobile checkout with logged-in prefill, inline validation on address and payment errors, and a visible order summary before pay, so the second JTBD (checkout speed) had its own rejected alternatives, not only discovery fixes.

I validated each stream separately. A/B tests ran at 50K+ sessions per workstream before combining. Instrumented funnels attributed revenue lift to specific changes.

**The Impact** — 35% faster discovery, £8.2M incremental revenue, attribution you could defend
Filtering and Quick View cut time-to-product by about 35%, measured as median clicks from category entry to add-to-basket. Listing and product page work lifted engagement and basket size. Attribution split cleanly: improved filters contributed approximately 40% of the discovery speed gain, Quick View 45%, clearer PDP hierarchy 15%. The programme landed around £8.2M incremental revenue in the year I measured: discovery work (filters + Quick View) drove the majority via faster time-to-basket.

Because I shipped logged-in prefill and inline error recovery on a three-step mobile checkout, mobile checkout completion rose 9 percentage points in the same instrumentation window; that represents the checkout workstream contribution alongside discovery attribution above. Post-launch surveys showed NPS improvement of 8 points for 'ease of finding products'.

Takeaways:
- Live counts and saved filter combinations cut restart friction on ranges too large to browse blind.
- £8.2M incremental revenue with defensible 40/45/15 discovery attribution split.
- Checkout prefill and inline errors added +9pp mobile completion in the same window.

---

### Predictable spend forecasting (Vodafone)
[View case study](https://www.gaganmalik.io/en/success-stories/vodafone)

[Retrieval brief — vodafone-mobile-connectivity]
Category: technology
Thesis: Plain-language IoT spend forecasts, named cap owners, and docs that match UI vocabulary reduced bill shock and integration friction.
Answers: What did Gagan do at Vodafone? | How did Gagan design IoT spend management at Vodafone? | How should finance and ops read IoT cost forecasts?
Implication: Forecast in finance language with fleet/site breakdowns; align API and UI vocabulary before scaling integrations.
Proof: 58% drop in unexpected spend escalations in two quarters; Cap integration onboarding 4h to 45m; 50M+ users on platform
Concepts: IoT, forecasting, developer experience, bill shock

**The invoice lands on a Tuesday and three teams chase the same spike.** On Vodafone's IoT platform, cost stayed opaque until billing closed. Finance wanted a forecast. Ops wanted attribution. Developers wanted guardrails in production. By then the period was history. The job was earlier signal: plain-language forecasts, caps with a next step, alerts operators could act on, and docs that matched the UI word for word.

**The Opportunity** — Operational spend, rear-view visibility
Spikes came from rollouts, misconfigured devices, roaming, firmware shifts, and fleet usage, not one-off bugs. After billing closed you could explain what happened. You still could not reliably forecast the bill, set guardrails early, or catch drift in time to act.

Bill shock eroded trust and finance slowed expansion sign-offs. Ops burned time on spikes without clean attribution or a fast path to root cause. When setup and docs were hard to use, automations never shipped and good controls stayed slideware.

My JTBD research with 30+ IoT programme owners across automotive, utilities, and logistics identified three needs: finance wanted forecasts grouped by fleet, site, or cost centre, not only API IDs; ops wanted alerts that named actionable slices ('Site 4 roaming overage', not 'threshold exceeded'); developers wanted docs using the same vocabulary as the UI so integrations shipped without round-trips. Billing spike post-mortems and developer onboarding observation confirmed the gaps. Constraints: monthly billing cycles could not change; forecasting had to handle weak signals without false precision; caps needed clear ownership and audit trails. Success upfront: reduce 'billing surprise' escalations by 50% within two quarters.

**The Solution** — Plain-language forecasts, caps with ownership, docs that match the API
I designed forecasting to answer 'What will we likely spend this period?' in language finance teams already use. Three directions were on the table. Exact predictions with confidence intervals: rejected, because false precision eroded trust when reality diverged. Historical average only: rejected, because it missed rollout and configuration changes. Plain-language forecast ('Likely £12K to £15K this month based on current usage and planned rollouts') with breakdowns by fleet and site: what I shipped.

I structured breakdowns to follow how teams already group fleets and sites, not API schema forced onto reporting. Weak signals were labelled clearly ('based on three days of data' versus 'forecast') instead of presented as exact. I mirrored real ownership in caps: warn before a hard stop, show what next when a threshold crossed (pause devices, request increase, review usage), and keep a simple log of who changed what.

Anomalies stayed short and actionable: 'Site 4 roaming overage: 240 devices connected to non-home networks', with links to the device list and usage breakdown teams already use. I aligned developer docs vocabulary with the UI: 'spending cap' in both places, not 'Create a spending threshold' in the API and 'Set a cap' on screen. Quickstarts and copy-paste examples cut integration friction.

I validated with eight IoT programme teams across verticals, A/B tested forecast phrasing with finance users (plain language versus confidence intervals), and ran developer onboarding sessions. Time to first successful cap integration dropped from 4 hours to 45 minutes.

**The Impact** — Steer while the period is still open
Teams shifted from 'what happened last month' to what's coming, where caps apply, and what changed. Finance could plan earlier. Ops could act before close. Programme owners could grow fleets with fewer invoice surprises.

Plain-language forecasts grouped by fleet and site, cap warnings with named owners, and docs aligned to UI vocabulary ('spending cap' in both places) drove billing escalations tagged 'unexpected spend' down 58% in two quarters, clearing the 50% target. Developer onboarding for cap integration fell from 4 hours to 45 minutes.

Takeaways:
- 58% drop in 'unexpected spend' escalations — plain forecasts and named cap owners.
- Docs↔UI vocabulary match cut cap onboarding from 4h to 45m.
- Forecast copy must match how finance groups fleets and sites, not only engineering IDs.

---

### Service requests made faster (Welsh Water)
[View case study](https://www.gaganmalik.io/en/success-stories/welsh-water)

[Retrieval brief — welsh-water-trusted-field-operations]
Category: design
Thesis: Structured digital intake with branching triage cut callbacks and routed emergencies without burying them behind billing queues.
Answers: What did Gagan do at Welsh Water? | How did Gagan improve Welsh Water service request intake?
Implication: Separate civic-emergency intake from billing in UX and routing; capture location and severity on screen one.
Proof: Callbacks for incomplete tickets 40% to 11%; 3M+ people served
Concepts: utilities, service design, triage, digital intake

**Water is pooling on the pavement and the hold music has been playing for nineteen minutes.** Welsh Water serves around three million people [Welsh Water](https://corporate.dwrcymru.com/en/about-us)::pill across most of Wales and adjoining areas. A burst on a main does not wait for a billing query to finish. Neither should the person reporting it.

**The Opportunity** — Three million served, one queue for meter reads and mains bursts
Welsh Water already operated at full civic scale: storms, bursts on large mains, and heavy capital work were normal operating noise for a supplier serving around three million people [Welsh Water](https://corporate.dwrcymru.com/en/about-us)::pill. Contact centres carried that load alongside everyday customer work.

My JTBD research surfaced three triage problems. Most contact was billing and accounts: it deserves a straight answer but does not need a crew. Leaks and supply hits showed up less often in totals but felt urgent when water crossed the pavement or the shower dropped to a trickle. Both reasons landed in the same phone queue.

Contact centre call analysis showed about 20 minutes average wait during busy periods: tolerable for a meter question, a poor match when water is leaving the pipe. Field dispatch shadowing revealed 40% of tickets required callbacks to fill location or severity gaps. Customer interviews echoed the same frustration: 'I reported a leak and waited on hold.'

Constraints shaped the programme. Self-serve meant guided digital journeys plus robotic process automation into back-office and work-management systems (this predated reliable LLMs). Automation had to integrate with existing trunk repair, sewer inspection, and reinstatement dispatch. Emergencies could not hide behind complex forms. Success upfront: move high-stakes reporting (leak, burst, no water) onto digital intake that captured clean, structured reports automation and dispatch could trust.

**The Solution** — Guided intake and RPA, not a chatbot pretending to understand
I ran a design sprint with product, operations, and content to agree what to build first: guided flows that walk someone through reporting a leak or another service request, capturing location, severity, anything unsafe on site, and photos when useful, with plain-language next steps on screen. Three options were considered. Generic webform with free-text description: rejected, because it perpetuated ambiguity and callback loops. Chatbot-style conversation: rejected, because the programme predated reliable LLMs and customers needed fast triage, not conversation. Guided journey with branching questions and structured payload: what I shipped.

I scoped flows so residents could finish a high-stakes request without starting on the phone. Branching removed ambiguity before dispatch: 'Is water coming from the ground or a building?' routed mains bursts differently from internal leaks; 'Is the leak on a pavement, road, or private property?' determined crew type; 'Is anyone at risk?' (traffic, electrical hazard) triggered emergency escalation. Location capture used postcode search, map pin, or what3words (Welsh Water coverage includes rural areas where postcodes are coarse). Photos were optional but encouraged for severity assessment.

Behind the scenes I designed a structured payload (location coordinates, severity tier, risk flags, photo metadata, property type) that rules-based routing and RPA could pass into trunk repair, sewer inspection, and reinstatement queues without agents rewriting fields. The first payload matched how those job types were sequenced in dispatch, not a generic CRM shape. Plain-language copy paired with field-realistic job data so automation had something reliable to act on. I stopped at MVPs on purpose: enough to prototype and user-test, without treating one workshop as a production launch.

Forty residents tested prototypes against realistic scenarios ('You see water on the pavement outside your house, report it'). I observed completion rates and confusion points, iterated copy and question order, then piloted with one regional contact centre before national rollout.

**The Impact** — Callbacks down from forty per cent to eleven, crews dispatched twenty-eight per cent faster
The aim was practical: less ambiguity when a request arrives, fewer callbacks to fill gaps, and dispatch seeing what crews need on the first screen. Agents kept doing what only people should do (vulnerable customer support, complex billing disputes). Automation took predictable steps that had been burning minutes and mis-keys.

Because I designed branching intake with structured location, severity, and risk fields on first submit, callback rates on digital leak reports dropped from 40% to 11% and average time from report to crew dispatch shortened 28% for digitally submitted requests. Satisfaction scores and capital programmes shift with regulation and weather; the durable bet was narrower: when intake is structured, people spend less time on hold for emergencies that should never have waited behind billing volume.

Takeaways:
- Callbacks on digital leak reports 40→11% after branching intake replaced free-text ambiguity.
- 28% faster report-to-dispatch when structured payload matched crew job types.
- High-stakes reporting needs its own front door, not a longer queue behind billing.

---

### One workspace for team collaboration (Presto)
[View case study](https://www.gaganmalik.io/en/success-stories/presto)

[Retrieval brief — presto-automated-monetisation]
Category: technology
Thesis: Workspace AI needs one object graph across boards, docs, and assistant so status, knowledge, and answers share the same truth.
Answers: What did Gagan build at Presto? | How should workspace AI share context with Kanban and docs? | Why do assistant pilots fail when chat is separate from deliverables?
Implication: Unify projects, tasks, and citations before scaling agent features; measure shared-truth perception across surfaces.
Proof: 78% of teams reported board, Spaces, and assistant agreed on state; 42% drop in context-switching in beta
Related essays: against-one-click-coding, search-finds-pages-chat-finds-answers
Concepts: workspace AI, agent orchestration, object model, SaaS

**The assistant opens with 'I can't see that workspace' while the board already shows the sprint.** Presto Platform (askpresto.com) shipped Kanban boards, rich-text Spaces, and an AI assistant with Ask, Plan, and Create. In practice they behaved like three tools on one login: status on the board, knowledge in Spaces, answers in chat that never shared the same objects. Stand-ups became reconciliation. Reporting became screenshots. The job was one governed workspace where context rode with the work.

**The Opportunity** — Three surfaces, three truths, one tired programme lead
Teams tracked delivery on the board, wrote specs and notes in Spaces or a wiki, and opened generic chat when they needed help. Context did not carry across. Assistant threads were ephemeral. Reporting pulled from the board while decisions lived in Spaces drafts managers stitched together by hand.

My JTBD research across 40+ delivery, product, and engineering teams surfaced three integration gaps: board assignments and Spaces pages referenced the same projects but shared no object model; assistant runs disconnected from deliverables; reporting told one story while the knowledge base told another. Workflow shadowing during sprint planning and reviews showed the cost in repetition and mistrust. Competitive analysis of Notion, Linear, Asana, and ClickUp set the bar for what 'integrated' had to mean.

Constraints were non-negotiable: role-based access (viewer, editor, admin); assistant responses that cited workspace sources; no breaking existing workspaces mid-rollout. Success upfront: more than 70% of teams reporting that board, Spaces, and assistant agreed on project state.

**The Solution** — One object graph for boards, Spaces, reports, and the assistant
I designed end to end on a shared shadcn Maia system with role-based access. Keeping separate surfaces with manual links would have perpetuated context switching. Embedding docs inside board cards would have trapped knowledge inside board hierarchy. I built a shared workspace object model where boards, Spaces, and assistant all referenced the same projects, tasks, and people.

I structured workspaces and boards to carry assignments, due dates, priorities, and lanes so status stayed on the board, not in spreadsheets. I built Spaces with Notion-style rich text for knowledge and drafts; I designed Create mode and the draft drawer to land AI output on real pages, not ephemeral chat replies. I designed the assistant with Ask (quick questions), Plan (multi-step reasoning), and Create (draft generation), with mentions (@person, @project, @space), workflow templates such as weekly status summary, and models curated per workspace.

I designed reporting with day, week, and month views: completed tasks, blocked items, assignment distribution, all from the same board data teams already updated. I put home cards and the composer on the first screen: weekly actions, integration prompts, recent work visible at a glance.

I validated in the field, not in a deck. Twenty teams ran a three-month beta. Instrumented context-switching frequency dropped 42% against the prior separate-tools baseline. Alignment perception ('board and Spaces agree on status') climbed from 38% to 76%.

**The Impact** — One project name, one status, one place to trust the assistant
Teams stopped treating the board, knowledge base, and chat as three competing truths. Fewer reviews opened with a recap nobody had time for. Fewer assistant replies started with a request for context the workspace already held. Managers read movement in reporting instead of stitching a story from side channels and screenshots.

Create mode with citations to board tasks and existing pages moved assistant output from discard to ship. Seventy-eight per cent of teams reported that board, Spaces, and assistant shared the same truth, clearing the 70% target and underpinning beta retention and paid-seat expansion conversations (directional; specific revenue figures under NDA).

Takeaways:
- 78% of teams reported shared truth across board, Spaces, and assistant — above 70% target.
- Create mode with citations turned assistant output from discard to ship.
- Reporting earns trust when it pulls from the same assignments the board already tracks.

---

### Expert travel guides (Telegraph Travel)
[View case study](https://www.gaganmalik.io/en/success-stories/the-telegraph)

[Retrieval brief — telegraph-travel-waitrose]
Category: design
Thesis: Editorial authority wins in travel apps through trip-shaped itineraries, offline use, and expert picks—not scraped listings at scale.
Answers: What did Gagan do at Telegraph Travel? | How do media brands compete with Google in travel products?
Proof: 130K app downloads first year; 47% second-trip return within six months; 73% rated editorial quality above free alternatives
Concepts: media, travel, offline, editorial product

**The gate closes in twenty minutes and your signal dies.** Travellers do not reach for another list; they reach for judgement they can trust. Lonely Planet earned that over decades. Google-class trip tools earned it on convenience and scale. The Telegraph Travel Guides app had to earn shelf space beside both: Telegraph judgement, packed for the pocket, readable when roaming is expensive and the next decision cannot wait.

**The Opportunity** — Shelf space beside Lonely Planet authority and Google-scale convenience
The competitive bar was never 'another travel app.' Readers already held Lonely Planet up for authority and Google-class surfaces for map-first convenience. My job was to show why Telegraph belonged on the home screen when someone lands tired, abroad, and has thirty minutes to decide what to see.

My JTBD research surfaced three non-negotiables: trusted picks (shortlisted hotels, honest walk routes, food writing with a point of view, not scraped filler), usable in transit (offline reading, maps that work without signal, quick decisions on a small screen), and a credible reason to choose Telegraph over brands they already know. I ran traveller interviews in airports and hotels at real decision moments, tore down Lonely Planet, Google Maps Explore, Tripadvisor, and Airbnb Experiences, and surveyed Telegraph Travel readers: 68% wanted expert picks in app form.

Constraints were tight. Content had to come from Telegraph Travel journalism, not scraped listings. The app had to work offline. Monetisation could not trash the brand with intrusive ads. Success upfront: more than 40% of active users returning for a second trip within six months.

**The Solution** — Twenty-nine deep guides, not a database pretending to be editorial
I put Telegraph Travel judgement into the product structure itself: authored picks, trip-shaped itineraries, and maps you could trust without signal. Three directions were on the table. User-generated content with Telegraph curation: rejected, because it dilutes the authority readers pay for. A full destination database with Telegraph reviews layered on: rejected, scope and maintenance would bury the desk. Twenty-nine destinations [Telegraph 2015](https://www.telegraph.co.uk/travel/news/Telegraph-Travel-Guides-app/)::pill at launch with deep Telegraph coverage per city: what I shipped.

I paired content and UX craft in the same room. I structured destinations and days out from Telegraph journalism: expert hotel picks, restaurant shortlists, walk routes, sights, each with timing, transport, and booking links where it helped. I shaped itineraries around how people actually move ('One day in Rome: ancient and modern', 'Weekend in Barcelona: Gaudí trail'), not abstract bucket lists. I designed maps and saved guides to work offline so navigation did not depend on roaming. I kept copy Telegraph Travel throughout: honest, opinionated, written for readers who already know a city has more than one cathedral.

I made positioning deliberate: Telegraph authority and tested routes against Lonely Planet breadth; Telegraph curation against Google scale where everything is listed and nothing is chosen. I led app store messaging with expert-led, offline, no ads.

I validated in the field, not in a lab. Sixty travellers used prototypes during real trips while I watched in-situ behaviour. I A/B tested itinerary formats (step-by-step versus overview-first). Instrumentation showed 82% saving at least one guide for offline use, which confirmed offline was not a nice-to-have.

**The Impact** — Judgement that survives the second trip
The Guides line turned reputation into a planning ritual travellers could pack. Downloads reached 130K [Telegraph 2015](https://www.telegraph.co.uk/travel/news/Telegraph-Travel-Guides-app/)::pill in the first year post-launch. Telegraph Travel reached 1.1M readers across web and app surfaces.

Itineraries structured as trip-shaped day plans with offline save drove 47% of active users back for a second trip within six months, clearing the 40% target. Seventy-three per cent rated editorial quality above free alternatives; readers who saved offline itineraries were more likely to reopen the app for a second destination, linking the structure to repeat use rather than one-off downloads.

Takeaways:
- 47% returned for a second trip within six months — offline itineraries drove repeat use.
- 130K downloads year one; 29 deep destinations beat a scraped database.
- Against Lonely Planet and Google, editorial IP has to live in structure and copy.

---

### Loyalty for food lovers (Waitrose)
[View case study](https://www.gaganmalik.io/en/success-stories/waitrose)

[Retrieval brief — waitrose-loyalty-food-lovers]
Category: business
Thesis: Premium loyalty competes on food identity and transparent personalised value, not points dashboards that commoditise the brand.
Answers: What did Gagan do at Waitrose My Waitrose? | How should premium retailers design loyalty without Clubcard-style points?
Proof: 4.6M active My Waitrose members; Offer clarity 42% to 68% after personalised offer cards; +12% repeat visits among active members vs non-members
Concepts: loyalty, retail, personalisation, premium brand

**The card is in your hand and the offer on screen makes no sense.** Four and a half million people scan My Waitrose every week for coffee, treats, and the feeling that Waitrose knows what they cook. The Partnership had scale on its side. The experience still had to earn the next visit before someone gave up at the till.

**The Opportunity** — Seven per cent more members on a food brand that cannot win on points alone
John Lewis Partnership's 2024/25 annual report puts the scale in plain sight: My Waitrose grew 7% to 4.6 million active members [JLP report 2025](https://www.johnlewispartnership.co.uk/~/media/Files/J/john-lewis/corp/documents/john-lewis-plc-ara-24-25-signed.pdf)::pill while more customers shopped with the Partnership's brands. Waitrose sales reached £8.0 billion [JLP report 2025](https://www.johnlewispartnership.co.uk/~/media/Files/J/john-lewis/corp/documents/john-lewis-plc-ara-24-25-signed.pdf)::pill. The business invested £150 million in lower prices [JLP report 2025](https://www.johnlewispartnership.co.uk/~/media/Files/J/john-lewis/corp/documents/john-lewis-plc-ara-24-25-signed.pdf)::pill since 2023, relaunched Waitrose No.1, refurbished stores, and pushed on-demand grocery sales up 110% [JLP report 2025](https://www.johnlewispartnership.co.uk/~/media/Files/J/john-lewis/corp/documents/john-lewis-plc-ara-24-25-signed.pdf)::pill.

The experience bet sat underneath those headlines. My JTBD research surfaced three shopper missions: everyday value (free coffee, treats, savings people grasp before the till), food discovery (recipes, seasonal ranges, counters, member events), and transparent personalisation (offers tied to purchase history without opaque targeting). Member surveys showed 73% valued free coffee and treats but only 42% understood how personalised offers worked. Exit interviews named 'too complicated to use offers' as a top barrier. Service design mapping traced the friction across online, app, and in-store touchpoints.

Constraints were non-negotiable: offers had to work across every channel without Partners learning a second script; personalisation had to comply with data privacy and feel explainable; the value story had to stay premium. Success upfront: active member growth above 5% annually, with offer redemption rates improving.

**The Solution** — Free club for food lovers, not another points race
My Waitrose works when membership connects three loops, not when it behaves like a bolt-on scheme. Three directions were on the table. Points-based loyalty like Tesco Clubcard: rejected, because it commoditises the brand and competes on scale Waitrose cannot win. A points dashboard UI: rejected, because it trained shoppers to chase balances instead of food identity. Premium subscription with an upfront fee like Amazon Prime: rejected, because it adds a barrier at entry and does not match Partnership values. Free membership with everyday rewards [My Waitrose](https://www.waitrose.com/ecom/mywaitrose/become-a-member)::pill, food identity, and transparent personalised value: what I shipped.

I designed everyday reward to keep the reasons to scan visible: free tea or coffee, treats with a hot drink, selected savings (20% off wine, seasonal produce), and offers people understand before they reach the till. I wrote expiry, usage ('Scan your card at checkout'), and terms in plain language so Partners and customers resolved questions without manager calls.

I turned membership into a food-lover club: recipe inspiration tied to seasonal ranges, counter highlights (fishmonger picks, cheese pairings), Waitrose No.1 discovery, member tastings, cooking classes, supplier stories, and competitions. Communications led with food ('This week's seasonal star: British asparagus'), not generic retail ('Save 15% on vegetables').

I made personalised value and relevance legible. Offers explained why they appeared ('Based on your purchases: 10% off organic chicken this week'), when they expired (countdown in app and email), and how to use them (online code, scan in store, automatic at till). Customers could see offer history and opt out of categories.

I grounded validation: service design blueprints mapped touchpoints across coffee run, top-up shop, weekly shop, and entertaining missions; prototypes tested offer clarity with 120 members across age groups; pilot stores instrumented redemption and satisfaction before national rollout.

**The Impact** — 4.6 million members, clearer offers, twelve per cent more repeat visits
Post-launch member surveys showed offer clarity rising from 42% to 68% ('I understand why I received this offer') after the personalised offer card pattern shipped with explicit why/expiry/how copy. Repeat visit frequency increased 12% among active members versus non-members in the same measurement window: the loyalty-attributable behaviour shift I can defend separately from headline Partnership P&L.

Offer cards with explicit why, expiry, and how-to-use copy moved offer clarity from 42% to 68% in member surveys. Repeat visits rose 12% among active members against non-members in the same window. My Waitrose reached 4.6 million active members [JLP report 2025](https://www.johnlewispartnership.co.uk/~/media/Files/J/john-lewis/corp/documents/john-lewis-plc-ara-24-25-signed.pdf)::pill, up 7%, within broader Partnership growth (Waitrose sales £8.0B, operating profit +£122M: context, not loyalty-only attribution).

Takeaways:
- Offer clarity 42→68% after personalised offer cards with why/expiry/how copy.
- +12% repeat visits among active members — loyalty-attributable, separate from P&L.
- Rejected points-dashboard UI; food identity and transparent value beat balance chasing.

---

### Better team collaboration (Eutelsat OneWeb)
[View case study](https://www.gaganmalik.io/en/success-stories/eutelsat-oneweb)

[Retrieval brief — eutelsat-oneweb-engineering-docs-workflow]
Category: design
Thesis: Template-led engineering intake, named review owners, and live document state cut version drift when launch windows do not wait.
Answers: What did Gagan do at Eutelsat OneWeb? | How does design ops help satellite engineering documentation?
Proof: Pack completeness 61% to 89% with template intake; 38% fewer review round trips in pilot
Concepts: design operations, documentation workflow, satellite, review routing

**Launch windows do not wait while two disciplines cite different revisions.** Satellite programmes pull together spacecraft, ground sites, suppliers, and regulators. When iteration speeds up, parallel changes multiply. Signatures wait on the wrong pack. Programme leads pull status from mail instead of one clear picture. The job was collaboration that matched how satellite work actually happens: visible owners, live state, audit trails reviewers could trust.

**The Opportunity** — Strong engineering, fuzzy version truth
Eutelsat OneWeb's published fleet counts run to [650 satellites](https://www.eutelsat.com/system/files/2025-10/DOC_Group_URD-Eutelsat-2024-25_EN_301025.pdf)::pill in low Earth orbit, [70 teleports](https://www.eutelsat.com/satellite-network/geo-leo-multi-orbit-satellite-network)::pill on the ground, and [510 engineers](https://www.eutelsat.com/system/files/2025-10/DOC_Group_URD-Eutelsat-2024-25_EN_301025.pdf)::pill in the workforce figures Eutelsat reports for FY 2024–25.

The painful pattern was familiar: two disciplines referencing different revisions, signatures waiting on the wrong pack, programme leads chasing answers across threads instead of reading one status view.

My JTBD research identified three workflow gaps: new specs and change packs started from blank folders with no standard structure; review routing was opaque (who owns the next step?); document state scattered across email, shared drives, and PLM with no single source of truth. Workflow shadowing across three satellite programmes, stakeholder interviews with systems engineers, programme managers, and quality leads, and an audit of rejection reasons at review gates showed 62% were 'incomplete pack' or 'wrong revision cited'.

Constraints: existing PLM and document management systems were not changing (workflow had to integrate, not replace); specialists could not be forced through a big-bang tool swap during launch windows; regulatory compliance required specific review checkpoints. Success upfront: reduce review round-trips at integration and acceptance gates by at least 30%.

**The Solution** — Templates, routing, and live status beside the repositories teams already used
I shaped automation around real programme rhythms: structured starting points, routing that respected roles and boundaries, review checkpoints only where policy required them. Three directions were on the table. New centralised document repository to replace existing PLM and shared drives: rejected, because migration mid-programme was unrealistic and specialists resisted tool swaps. Email-based workflow with manual tracking: rejected, because it perpetuated the opacity problem. Lightweight automation layer integrating with existing repositories and surfacing metadata and hand-offs: what I shipped.

I designed template-led intake with named sections (scope, interfaces, test evidence, sign-off checklist), required fields that blocked submission until complete, and standard revision naming. The routing view showed live states (Draft, In review, Changes requested, Approved) with a named owner label at each gate (author, discipline lead, systems engineer, quality reviewer, programme approval). Notifications stayed short and pointed to the live artefact ('Spec 4201 Rev C ready for your review' with direct link). Hooks into existing repositories so status reflected what people actually filed: when a document moved to the PLM system of record, workflow metadata updated automatically.

I proved each flow with a pilot programme first (one satellite build stream), instrumented review round-trips and time-to-gate-approval, then widened stream by stream. Pilot showed 38% reduction in review round-trips and 22% faster time through integration gate; scaled to five additional programmes over six months.

**The Impact** — Less reconciliation, more engineering judgement
Teams spent less time debating which file counted and more time on the technical decision itself. Template-led intake with required sections and named owners at each review gate raised pack completeness from 61% to 89%. That shift cut review round-trips 38% in pilot and dropped gate cycle time 34% across programmes using the automation.

Programme leads could scan document state at a glance instead of chasing answers across threads. Post-pilot surveys showed 82% of engineering leads reporting 'workflow reduced reconciliation overhead'. The lasting shift was cultural: paperwork treated as part of the mission rhythm, not an admin sideshow after the real work was done.

Takeaways:
- Pack completeness 61→89% after template intake with required fields and named gate owners.
- 38% fewer review round-trips in pilot; 34% faster gate cycle time at scale.
- Automation sticks when it sits next to existing repositories instead of inventing a new source of truth overnight.

---