FitFuel
Solo UX researcher and designer, end to end
Role
Applied case study for a fictional early-stage startup
Project Type
Tools
Claude (research, drafting, and documentation)
Figma Make (interactive prototyping)
Lighthouse (accessibility scanning)
axe DevTools (accessibility scanning)
3 weeks
Timeline
Deliverables
Primary research report, personas and journey map, decision-ready design package, WCAG 2.2 AA accessibility audit
Context
FitFuel is a fictional AI-enhanced fitness and nutrition app, built as a four-week applied case study for an early-stage startup. The team had a hypothesis, not a validated strategy: that busy professionals might be an underserved audience for a more adaptive kind of fitness support. They wanted AI to play a real role in the product, adaptive planning, progress insights, supportive copy, not just tracking, and they wanted every decision behind it professionally defensible. The product space touched workout planning, nutrition support, habit formation, and accountability. They were also genuinely willing to change direction if the research didn't support their idea.
Role
I led this project solo, end to end: research direction, primary research, synthesis, opportunity mapping, a decision-ready design package, and a WCAG 2.2 AA accessibility audit. I worked from interview transcripts the client had already collected, using Claude as a research and production partner throughout, though every decision that shaped the product stayed mine. I designed and prototyped the adaptive planning flow as an interactive experience in Figma Make. Two commitments anchored the work: every insight carried a validation status, and every reversal, renaming a persona, removing an assumption, got documented rather than smoothed over.
Results
Research reframed the brief entirely: the real barrier to consistency wasn't motivation but capacity, and people were disengaging in a sharp boom-bust pattern rather than a slow fade. That led to a focused opportunity, Adaptive, Context-Responsive Planning, and a working prototype built around it. The accessibility audit surfaced a systemic contrast failure and missing heading markup, along with a clear, honest list of what still needs a second pass.
I delivered five evidence-based recommendations and a design package with a fully traceable line back to the research, including a transparent account of what's proven and what's still open.
The Problem
The client came in with a belief, not a validated strategy. They suspected busy professionals were an underserved audience for a more adaptive kind of fitness support, and they wanted AI to play a real role in that: adaptive planning, progress insights, supportive copy, not just step tracking. What made this a real design challenge, and not just a build job, was what they asked for alongside the idea. They wanted the work professionally defensible: no unsupported market claims, no unchecked AI output, no narrow default personas, no design rationale that couldn't be traced back to evidence. They were also genuinely willing to change direction if the research didn't support their hypothesis.
That combination put the burden on research to actually settle the question before design started. My job in the first weeks wasn't to design a fitness app. It was to find out:
• Was “busy professional” a real, underserved segment, or just a comfortable default?
• Was the actual barrier to consistency time, or something closer to motivation, confidence, or health constraints that a generic fitness app never asks about?
• Did personalization need to respond to a stated goal, or to the shape of someone's actual day?
• What would make AI involvement in a health decision feel trustworthy instead of invasive?
• Whose needs were the default fitness-app assumptions quietly leaving out, older users, disabled users, people returning after injury, people outside conventional body-goal narratives?
The central tension: the client's confidence in the busy-professional hypothesis was outpacing the evidence for it. My job was to close that gap before it shaped a product built for the wrong person.
The Process
I brought a collaborative, evidence-based process to this project. Two commitments anchored all four weeks:
• Every insight carries a validation status. Findings were tagged Validated (grounded in primary research), Partially Validated, Practitioner Judgment, or External Evidence. External benchmarks never quietly borrowed the credibility of validated research. Hypotheses only made it into final deliverables when they pointed toward a specific next research step, not just to show my work.
• Reversals get named out loud. When I changed a decision, whether renaming a persona, removing an unsupported income assumption, or splitting a hypothesis that turned out to be blending two different people, I documented the change and the reasoning behind it. I didn't smooth it into a tidy final version.
Claude was my primary AI collaborator across every phase of this project: research synthesis, first-pass persona and microcopy drafting, structuring the accessibility audit findings, and later assembling final documentation. I built my workflow around a prompt library, and I tailored each prompt to the specific outcome I was after before I submitted it. Every prompt required a validation log and a source trail for each claim, so I could check the work instead of taking it at face value. I also instructed Claude to push back on my questions and assumptions, which helped me catch any weak reasoning early and kept the final results grounded in evidence.
AI never functioned as a source of truth. The decisions that actually shaped the product stayed mine: what counted as evidence, what got prioritized, what got reversed.
The Research: Real Transcripts, Not Assumptions
Research combined AI-assisted desk research with primary interview analysis, run through structured prompt sequences rather than open-ended requests. For each phase, market scoping, competitive identification, feature and sentiment analysis, thematic synthesis, and persona refinement, I ran the lesson's specified prompts in sequence and reviewed each output before moving to the next step.
I also directed several concrete course corrections along the way: confirming which competitors warranted deep attention, excluding wearables from the competitive set, requesting that user and practitioner interview data be analyzed separately rather than pooled, and commissioning a clustering-failure audit on the thematic synthesis (checking for over-clustering, under-clustering, surface clustering, and mismatched theme names) that led to real revisions, not a pass/fail formality.
The Insights
Immersing myself in the data surfaced patterns that changed the brief in genuinely useful ways. None of these held up as a single, tidy finding on the first pass. Each one sharpened, or in some cases split apart, once I pushed the synthesis harder than a first read would have.
Boom-bust cycling. Three of five interviewees described an identical pattern: starting hard, then dropping off completely, rather than gradually drifting away. That's a different design problem than a slow fade. I kept it as its own theme rather than folding it into the broader "life gets in the way" story, because the fix people proposed themselves, a small session that still counts as a full win, showed up independently across all five.
Tired, not lazy. The barrier people described wasn't a lack of motivation. It was capacity: energy, bandwidth, the real cost of showing up. All five interviewees said some version of it. I initially let that read as one clean insight, until I ran a clustering audit on my own synthesis and found it was flattening four different root causes, a chaotic schedule, structural overload from caregiving, cognitive unpredictability, and physical illness, into a single "tired" label. Those four causes don't all take the same design fix.
Trustworthy AI. People had a specific, describable line for what made AI feel like a helpful presence versus an overstepping one: explain its reasoning, default to caution when unsure, hand off to a human for anything injury- or mental-health-adjacent. I'd initially credited some of that specificity to the two practitioners in the sample. When I asked for user and practitioner data to be separated and re-checked, it turned out users had articulated those same conditions in their own words, which meant the trust requirement was user-validated, not borrowed from expert framing.
Nutrition-specific patterns. What first looked like one shared preference for "light-touch" nutrition guidance turned out to be four different people avoiding food tracking for four different reasons: eating-disorder safety, decision fatigue, a bad past experience, and a screen-reader accessibility barrier. I only caught that once I asked whether the theme had been clustered by topic instead of by actual motivation, the same design instinct held (don't force tracking) but with a much more specific set of reasons behind it.
Persona Development
I began with interview transcripts the client had already collected, which gave me primary access to real user language instead of guesses. I uploaded the five target user interview transcripts directly to Claude and gave detailed instructions on how to draft the persona document.
Once the persona and journey map artifacts were drafted, I reviewed and edited the persona deck by hand, adding a photograph to each profile and relabeling fields before treating the deck as final and folding it back into the consolidated report. I used Adobe Firefly to create the images, since they pull from stock photos and are safe for licensing. Even at a drafting stage where it wasn't strictly necessary, my own AI ethics policy carries here: I don't pull images from individuals whose likenesses were used as training data without their consent.
Sections initially included, such as income, were left blank. Despite my ability to look up the median salary for each persona's specified field, I chose not to fabricate that detail into the personas based on information the interviews themselves didn't provide. This is something worth revisiting later, when the project reaches the point of establishing the financial dimension of app execution, but it isn't an immediate concern at this early stage.
Persona development stayed grounded in the transcripts, not generic fitness-app archetypes. Every trait and behavioral cue traced back to something a real interviewee said. That discipline surfaced two catches:
Catching an averaged persona. What I'd initially called the "Returning Routine Builder" turned out to be two mechanically different people I'd unintentionally blended into one. Splitting them apart was a bias check I ran on my own synthesis, not a client note, and it's exactly the kind of catch that keeps a persona from quietly steering design toward someone who doesn't actually exist.
Removing an unsupported income assumption. An early persona draft included income estimates that read as plausible detail. When I checked them against the transcripts, no interview had actually disclosed income. I pulled the estimates rather than leave them in because they "felt right."
Two personas were also renamed, to Renee Marsh and Theo Alvarez, as part of genuinely refining who they represented, and I built that reasoning into the weekly report itself rather than leaving it in a private process file.
Three personas carried forward:
Jordan Reyes (primary), shaped directly by the boom-bust cycling pattern.
Renee Marsh, renamed and refined as her motivations became clearer through the transcripts.
Theo Alvarez, whose screen-reader-first needs made the accessibility work later feel essential rather than procedural.
Journey Mapping
I asked for the journey map to follow the exact 5×5 framework from this week's lesson: five stages (Awareness, Consideration, Onboarding, Core Use, Retention) crossed with five attributes (Actions, Thoughts, Emotional State, Pain Points, Opportunities), rather than a looser or improvised structure. That specificity mattered. A generic journey map format would have let vague, generic pain points slip through; naming five deliberate attributes per stage forced every entry back to something the research actually supported.
Jordan Reyes was the right choice for this first map, and not by default. Jordan represents the busy professional segment that was the project's original starting hypothesis, so grounding the first journey map in that persona kept the deliverable tied to the brief's own priorities rather than drifting toward whichever persona happened to be most colorful. More importantly, Jordan's defining pattern (a fixed plan breaking against an unpredictable week) was the single most validated finding across the entire research set, appearing independently in all five user interviews. Mapping her journey meant every stage of the map connected back to the strongest evidence I had, not the thinnest.
The map itself confirmed something worth carrying forward: Jordan's trust concerns don't start at onboarding, they start at Awareness, in the skepticism of "is this just another app I'll abandon in three weeks," and they resurface hardest at Retention, where a single guilt-driven notification is enough to undo weeks of good adaptive behavior. I reviewed the completed map against that expectation and didn't need to send it back for revision, which told me the framework had done its job: it surfaced a real, sequenced risk (trust eroding at the edges of the journey, not just the middle) rather than a flat list of generic app-onboarding friction.
Design
The Week 3 design brief centered on that opportunity, brought to life in an interactive prototype built in Figma Make. Working in Figma Make meant prompting it directly rather than manually placing every element, and getting the tool to actually reflect FitFuel's brand and audience took real, repeated correction. I fed it the brand voice documentation and persona information directly, but the first outputs defaulted to a generic, bright, upbeat aesthetic, closer to a template wellness app than anything grounded in the "tired, not lazy" research or the direct, quietly confident voice I'd already defined. I pushed back and insisted on revisions more than once before the output actually reflected the brand instead of the tool's own defaults.
Imagery took a similar amount of iteration. I initially tried building a background image in Adobe Firefly, but the file wouldn't import into Figma Make, which forced a change of plan partway through. That constraint turned out to be useful. Continuing to iterate directly inside Figma Make surfaced its own color system, and Claude helped produce candidate typography and color palette directions based on the brand voice documentation, which I evaluated against Figma Make's own system before settling on a final pairing that fit the brand more precisely than the original imported image likely would have. What came out the other side of that back and forth were decisions that each trace to a reason, not a preference:
Brand voice grew directly out of five convergent rejection patterns in the research. I landed on "direct and quietly confident," warmth expressed through competence and respect rather than upbeat cheerfulness, a deliberate move away from the performative tone the tool defaulted to and that so many fitness apps default to as well.
Effort-tier labels ("Express / Standard / Full") were flagged and replaced. I caught this contradiction twice: it quietly implied a hierarchy of effort that fought against the "tired, not lazy" insight, so I resolved it with parity language instead.
"Next Week" forward-projection copy was removed from the reflection screen. That language added a subtle pressure working against the sustainability goal at the heart of the project, so I removed it rather than softening it.
Photography became a real design lever, not decoration. I chose candid, natural-light, genuinely diverse imagery, intentionally not stock or posed fitness photography, in service of the inclusion the brief asked for.
Typography. Atkinson Hyperlegible Next was chosen specifically for its accessible letterform design, not for visual trend.
Accessibility Audit
I want to be direct about this section rather than let the format oversell it. Usability testing was optional at this stage, and I didn't run it. What I have isn't “tested with real users and it held up.” It's a structured accessibility audit, a narrower kind of validation, and I'm naming that distinction clearly because blurring it would be exactly the kind of unsupported claim I built this whole process to avoid.
What I actually did: a WCAG 2.2 AA-target accessibility audit, using Lighthouse and axe DevTools, screen by screen across all 11 screens. WCAG (the Web Content Accessibility Guidelines) is the standard most digital products are measured against for accessibility, and “AA” is the mid-tier compliance level most organizations target.
What it surfaced:
• A systemic contrast failure on the secondary text color. It measured a contrast ratio of 2.74 to 2.79:1 against the 4.5:1 minimum required for readable text (WCAG 1.4.3), affecting text across the product rather than one isolated screen.
• Bold, display-styled text on two screens that reads visually as a heading but carries no semantic heading markup (WCAG 1.3.1), meaning a screen-reader user would miss that structure entirely.
• A recurring sidebar contrast failure generated by the prototyping tool's own auto-generated navigation chrome. I flagged this as a tooling constraint and excluded it from remediation scope rather than quietly claiming it as resolved.
What's still genuinely open:
• The keyboard navigation pass was done incorrectly the first time. I pulled it rather than report it, and it needs a proper redo before I'd call this audit closed.
• A manual VoiceOver pass is partially complete. Specific findings, particularly around “group” announcements and navigation button behavior, need a second look from someone more fluent in assistive technology before I'd count them as confirmed rather than my own read.
• axe DevTools defaults to an older standard (WCAG 2.1 AA), so the newer WCAG 2.2-specific criteria, focus visibility, target size, and dragging movements, are unverified, not passed.
I see this as a scope call made honestly under real time constraints, with a clear line between what's proven and what's still open.
The Reflection
AI moved nearly every stage of this project faster. It synthesized research, drafted copy, and ran accessibility scans. But almost every decision that actually mattered was a place I overrode, qualified, or reversed a first-pass AI output. The effort-tier labels, the forward-looking copy, the persona split: none of those were AI catches. My job was deciding what to trust, which is the same instinct I bring to every client relationship.
AI never functioned as a source of truth. Every validation tag, every reversal, and every recommendation traces back to my own judgment about what the evidence actually supported. The return on that shows up less in hours saved and more in what a solo practitioner was able to produce at a defensible standard: a full research report, a decision-ready design package, and a WCAG-target accessibility audit, each with a documented evidence trail, inside a four-week timeline.
The repeatable part of this workflow isn't the tool, it's the discipline: tag every claim by validation status, name every reversal instead of absorbing it, and treat AI output as a draft to interrogate rather than an answer to accept.
Let’s Connect!
Schedule a free 1:1 virtual coffee chat with me to discuss your UX design needs.
