—:—

Case study

iOS Refresh

Two very different customers were using the same app badly for the same reason: they could not find anything. An 89-issue audit, a three-month sprint, and one null result that turned out to be the most useful finding.

Client
THE OUTNET — YOOX Net-A-Porter
Role
Mid Product Designer — Design Lead
Timeline
3-month sprint
Platform
iOS, with Android alignment
Method
UX audit · Firebase A/B testing
  • +67% Filter usage per session
  • +104% Sort usage per session
  • 89 Usability issues triaged

The problem

Fragmented navigation on both sides of the customer base

iOS users across both customer segments struggled to find products efficiently. Navigation was fragmented, Search and Wishlist were buried, and the patterns diverged from Android for no reason a customer would ever understand or forgive.

Understanding

Two customers, one app

The segmentation work mattered because the two groups fail differently. Designing for the average of them would have served neither.

Established Affluents

Fashion-literate, high income, brand-led. They arrive knowing roughly what they want and expect the browsing experience to feel effortless and quietly premium. Friction reads as cheapness.

Style Strivers

Younger, trend-driven, discount-motivated. They browse widely, compare hard, and rely on filtering and sorting to find the thing worth having at the price they want.

Discovery

89 issues. Two personas. One audit.

  1. 01 / 03

    Analytics — where people were actually struggling

    Working with the analytics team in Bologna, we mapped the real navigation behaviour. Strong interest in “Just In”, but with confusion attached: repeat taps on the same item, and returns to Categories after failing to find anything. Search and Shopping Bag saw low engagement despite carrying the conversion.

  2. 02 / 03

    UX audit — 89 issues, ranked by severity

    A full heuristic evaluation plus a content and functionality inventory across iOS and Android. Baymard’s severity and impact model turned the findings into a prioritised backlog that Engineering, QA and Product could all work from — and a vague “improve the app” brief into an evidence-based roadmap.

    Information architecture, current and proposed
    Product detail page, annotated
  3. 03 / 03

    Usability testing before development, not after

    An interactive prototype of the PLP to PDP journey, tested in structured sessions with roles assigned in advance. It surfaced confusion around filter feedback, sort confirmation, touch targets and low-stock notifications, and those findings shaped the next iteration directly. Friction found at this stage is far cheaper than friction found in code.

Hypothesis

What we bet on

Restructuring the bottom navigation, improving filter and sort accessibility on the product listing page, and introducing a sticky Add to Bag on the product detail page would drive higher engagement and conversion across both segments.

Three changes, tested independently through Firebase so each one had to earn its place.

Design

Three changes, three different answers

  1. 01 / 03

    Restructured bottom navigation

    Consolidated Search, Categories and Designers; moved Bag and Wishlist into the bottom bar where a thumb can reach them. Brought the pattern into line with Android so the two apps stopped contradicting each other.

  2. 02 / 03

    Sticky sort and filter on the PLP

    Kept the two primary listing actions permanently accessible, with clearer iconography and elevation. This is where the +67% and +104% came from — the tools were always there, they were just out of sight once you started scrolling.

  3. 03 / 03

    Sticky Add to Bag on the PDP

    Tested and returned no significant uplift. Making the button more visible did not make anyone more likely to press it.

Reflection

The null result was the finding

The sticky Add to Bag returning nothing was the most valuable thing the test produced. It ruled out visibility as the constraint, which meant the PDP problem was about confidence or missing information — whether the shopper believed the item was right, would fit, and could go back.

That reframed the next quarter of work. A positive result on the button would have sent us optimising a control that was never the bottleneck.

Takeaways

What I took from it

  • Rank findings by severity to the customer, not by cost to the team, or the backlog quietly sorts itself into whatever is easiest.

  • Test the three changes separately. Shipped together, the sticky Add to Bag would have been credited with the navigation win.

  • A null result is a result. It is only wasted if nobody changes their mind because of it.