Review-based diagnosis of repeated-use difficulties

The complaints fit a repeated-use design cost better than a learning curve

So I would test a compact logging view before assuming users just need time to adapt.

MyFitnessPal · Independent UX research · AI-enabled · automated review analysis → design diagnosis → prototype test plan

Competing explanations for redesign complaints

In April 2026 MyFitnessPal replaced its long-standing Diary with a new Today screen, and complaints spiked. The analysis distinguishes complaints about adapting to unfamiliar controls from complaints about additional actions or unavailable functions.

Learning-related difficulty

May respond to practice or guidance

Repeated-use design cost

Motivates testing a change to the interaction

The current MyFitnessPal Today screen, from the App Store listing
Current Today screen. App Store listing image, October 2026.

App-store review corpus and temporal samples

9,200 reviews collected, a 950-review study sample, and a baseline before the redesign

English-language Google Play reviews per week

Bars: reviews per week. Labels: share of a random 100 reviews per period about the redesign or an interface change.

9,200public app-store reviews collected (Google Play and App Store)
950drawn as the study sample and coded
about an interface change in Jan–Feb
about the redesign, Apr 20 to May 3

Diagnostic, not a population estimate

Review participation is self-selected, and dissatisfied users may be more likely to post. The reviews document reported difficulties but cannot establish their prevalence among all users.

Collecting 9,200 reviews and coding 950

Review sampling, independent model coding, and adjudication

9,200 reviews

Google Play and App Store, Dec 2025 to Oct 2026

›

Eric

Research decision

Distinguishing learning-related complaints from repeated-use interaction costs

›

Eric, AI-assisted

Sampling and coding framework

Random samples for complaint frequency among Google Play reviews, enriched samples for identifying and examining problem types. Coding categories specified before analysis.

›

Automated (Claude)

Independent coding and resolution

Two models code 950 reviews. A third resolves disagreements by rule.

›

Second AI check (GPT)

Evidence check

Caught the screened sample. Central result moved to the random sample.

›

Eric

Inference and recommendation

What the evidence supports, what to prototype, what to test next.

Eric's decisions Eric, AI-assisted Automated Second AI check
92% agreement between the two coders before resolution 289 of 950 reviews resolved by rule 1 command reruns the workflow, sample to slides Details in the appendix

Reported problems

Difficulties reported in app-store reviews

Current Today screen with numbered callouts 1 2 4

App Store listing image of the current Today screen. Callouts locate reviewers' complaints. Removed functions (3) are not visible here.

  1. 1
    More navigation for common tasks
  2. 2
    The day no longer fits at a glance
  3. 3
    Reviewers reported restrictions on copying, moving, and bulk editing
  4. 4
    Daily budget harder to inspect

The complaints converge on one repeated-logging need: see the day quickly and make common edits with few steps.

Percentages: share of negative redesign reviews in the larger content sample, Apr 20 to Oct 6 (n = ). mention years of use.

Design cost versus learning curve

The complaint pattern fits a design cost better than a learning curve

Learning-related complaints may diminish as users gain experience with the redesigned interface. Complaints about additional required actions or unavailable functions may persist despite familiarity. Review timing can distinguish these explanations only imperfectly because individual exposure histories are unknown.

Random sample: complaints that name a specific design cause

Launch period, Apr 20 to May 3 n =
design cost
learning curve
Apr 20 to Oct 6 n =
design cost
learning curve

A complaint can include both. The larger content sample shows the same pattern (appendix).

Product implication. Do not rely on habituation as the default response. Test a more compact logging path.

Coding decision. Accidental copies remained classified as learning-curve complaints under the original codebook. Their appearance in later reviews is also consistent with a possible control-placement problem. Because exposure duration is unknown, the later reports do not rule out learning-related explanations. I retained the original category and reported the alternative interpretation separately.

Limits of review evidence

Findings from reviews and outcomes requiring direct measurement

Can conclude

Complaints that name a specific cause are dominated by design costs in repeated logging, from the launch period on.

Cannot conclude

  • How many users are affected
  • Whether logging or retention changed
  • How long each later reviewer had the redesign ( of later reviews do not say)
  • say they will leave, but intention is not churn

Those unknowns define the next study.

Proposed changes

Optional compact day view for repeated logging

Current Today screen
Current: meals collapsed below the fold
Thu, Oct 8Compact view
2,074Goal
−
976Food
+
310Exercise
=
1,408Remaining
Breakfast412 cal · P 24 C 48 F 12
Oatmeal, 1 cup154
Blueberries, ½ cup42
Greek yogurt, 170 g216
Lunch564 cal · P 38 C 52 F 20
Turkey sandwich420
Apple, medium95
String cheese, 1 stick49
Dinner—
2 selected

Design mock. Illustrative food and numbers.

  • Every meal expanded, more of the day at once, calories and macros on each meal Answers 1 and 2
  • Budget in one place: goal, food, exercise, remaining Answers 4
  • Copy, move, and delete as direct actions on selected items, days, and meals Answers 3
  • Copying yesterday separated from opening a meal, with undo Answers accidental copies

Design hypothesis, not a validated improvement: an optional compact mode may reduce navigation and increase visible information without compromising comprehension.

Comparative usability study and behavioral analysis

Proposed test of logging effort, accuracy, and comprehension

Usability benchmark with established loggers

People with 2+ years of use who log 5+ days a week. Each uses the current design and the prototype. Alternate which they see first.

TaskWhy this task
Check everything logged todayGlance, navigation
Find calories remaining after exerciseBudget
Copy yesterday's breakfastRemoved functions
Delete or move itemsRemoved functions
Open a previous meal without copying itAccidental copies

Measures: time, taps, errors, accidental copies, how easy each task felt.

Product data, in parallel

If the product records when each user received the redesign: compare each user's logging before and after their own change date, with attention to long-tenure users, and account for baseline trends and other changes around the rollout.

Decision this study supports

If the compact view improves the tasks without comprehension costs, offer it to frequent loggers. If it offers no advantage, reconsider the design, not conclude that reviewers needed more time. The usability result and the logging result answer different questions.

Separate outcomes: task effort and comprehension in the comparative usability study, and changes in logging behavior in product telemetry.

Appendix

Sampling, coding agreement, and temporal comparisons

Share of all reviews about the redesign (random sample)

100 Google Play reviews per period. 95% Wilson intervals. Exposure timing unknown.

Design cost vs learning curve by period (larger content sample)

Among complaints naming a cause. Codebook labels: structural, relearnable. 95% Wilson intervals.

Two-coder agreement, 950 reviews, before adjudication

Relevance92% · κ .86
Names a cause, a task, or neither92% · κ .86
Individual task codesκ .66 to .92
Resolved by the third model289 of 950

Coders: Sonnet and Haiku. Adjudicator: Opus. Pipeline: tools/pipeline.py. Content sample = random sample plus 70 keyword-screened reviews per period from March, at least 10 words each.