Project Overview

A retail mobile app with an existing product that wasn't performing well. The client needed to understand what was actually wrong — not from gut feel, but from real user data. My role was to lead the research, surface the pain points, and translate findings into actionable design hypotheses.

Challenge

The product existed, but the team had no clear picture of why users were struggling. Without that understanding, any design changes would be guesswork. The task was to build an evidence base first — then figure out what to fix and in what direction.

Quantitative Survey

I started with a quantitative survey to establish the scale of the problem across the user base. Before going deep with interviews, I needed to know which issues were widespread and which were edge cases — and to have numbers that could later anchor the qualitative findings. The survey covered both user roles: Regional Managers and Store Managers. Alongside it, I ran a competitive analysis — not a feature matrix, but a qualitative read on where competitor apps were stronger and where they fell short relative to MD Audit.

What the data changed

The stakeholders came in with a clear brief: improve the home screen. That was the main tab, the first thing users see, the obvious place to start. The survey data complicated that. It turned out users were spending the majority of their time in the Tasks section — not the home screen at all. The home screen wasn't where the product was actually being used. That created an early hypothesis: if tasks are where users live, maybe they shouldn't be buried one tab away. Surfacing them on the home screen could solve an access problem users had already normalized. It contradicted what stakeholders assumed about usage patterns — and it gave us a concrete question to pressure-test in the interviews.

Custdev Interviews

With the survey data as a map, I ran in-depth custdev interviews across both roles. Regional Managers and Store Managers use the product differently and have different stakes in it — understanding both perspectives was essential. The goal wasn't to validate the survey point by point, but to get to the reasoning behind it: what users were trying to accomplish, where the app got in the way, and what workarounds they'd built on their own.

JTBD & Design Direction

After collecting data from both methods, I processed everything through the JTBD framework — translating raw observations and frustrations into concrete jobs the product needed to fulfill. Once the jobs were formed, I used them as direct input for design: each hypothesis for the redesign mapped to a specific job users were failing to get done. The concept for the app's main screen was built on this foundation, with every decision traceable back to something users had actually said.

From research to redesign direction

The combined output of the survey, competitive analysis, interviews, and JTBD synthesis was a set of concrete design hypotheses — specific, evidence-backed bets on what to change and why. Every hypothesis mapped directly to a real user problem, with a rationale traceable back to data. Together they defined the redesign direction: not a wishlist, but a prioritized brief the team could act on.

Two concepts for the home screen

The hypotheses fed directly into design. Two versions of the app's main screen were developed — each addressing the same core user jobs surfaced in research, but taking a different structural approach to the layout. Rather than a single prescribed direction, the team received two credible options to evaluate and choose from.

Outcome

After reviewing both concepts with the stakeholders, concept 2 was selected for rollout. The redesigned home screen — with tasks surfaced directly at the top level — was released to the full user base. Post-launch, two metrics were tracked against the problems research had identified most clearly.