snapkin
The habit · Decision 10 of 12
How much setup is worth asking for
Setup should produce a useful starting plan and explain what using the app will involve. The number of screens that best achieves that is an open product question.
Written and maintained by Mattias Geniar. Last updated .
- What the app does
- Uses body measurements, activity, goals and dietary constraints to prepare a plan. The current setup has twelve steps for loss, eleven for gain and maintenance. Goal and pace are adjacent, after the inputs needed for a personalized calculation; optional target weight and explanations remain collapsed.
- How sure we are Thin , One small study, or an engineering choice.
- There is no Snapkin experiment establishing the best length. Subscription case reports and tutorial usability studies measure different outcomes.
Which answers actually change something
Sex, birth year, height, current weight and activity feed the current target calculator. The objective changes its calorie adjustment and protein rule; pace changes the calorie adjustment. These answers become saved profile data when setup is submitted to the authenticated account, with current weight recorded as a weighing. Before that, setup keeps a local draft and requests a calculated preview.
Diet and its optional note are saved and passed to the meal analyser and coach. Target weight is saved too, but currently changes the estimated time to a target, rather than the daily calorie or protein target. It is now optional on the loss route, without removing the calculator's required inputs. Gain and maintenance do not show a target-date forecast. Historical activity used to suggest a level stays on the device; the selected activity level is saved.
Keep the actions clear of the home gesture
Onboarding reserves the native device's bottom safe area once, then adds ordinary footer spacing above it. WebKit's guidance explains how system-provided safe-area insets keep controls clear of the home indicator, and why insets do not replace layout margins. The private comparison illustrates this clearance; a browser frame cannot measure a native device's actual inset.
The case for taking longer
In a RevenueCat interview report, Lose It! described double-digit increases in trial starts after adding questions, including questions whose answers were not needed, with diminishing returns. No sample size, exact effect, experiment protocol or retention results accompany that claim. It is relevant practitioner evidence, but cannot predict this app's outcome.
Perceived personalization and commitment are plausible explanations. That does not establish that time already spent causes subscriptions. People who willingly finish more steps may already be more motivated. Any comparison must include everyone who started, including people who abandoned setup.
Extra explanation can have a cost
Nielsen Norman Group's 2020 study compared reading and skipping introductory tutorials with 70 participants across four relatively simple iOS apps. Tutorial readers rated the subsequent tasks harder; task success and speed showed no statistically significant benefit.
This is a reason to examine repeated explanations, not proof that every extra screen hurts. A demonstration of a useful capability can still earn its place before payment.
A broad diet, with room for exceptions
The diet choice, additional exclusions and optional note reach the analyser and coach. Someone can choose an unrestricted diet and select that they do not eat fish, without adding another onboarding step.
The dietary screen keeps a broad diet choice and adds an optional, clearly labelled “Other foods I avoid” area, collapsed by default and opened on request. A few independent selections, such as fish, shellfish, pork and dairy, sit beside free text for anything else. The checklist saves exclusions separately from the free-text note. Only additional exclusions appear in the checklist and collapsed summary; restrictions already covered by the diet are omitted. This avoids presenting a partial list, such as pork, as the definition of pescatarian. Changing the broad diet preserves explicit selections.
Nielsen Norman Group's progressive-disclosure guidance supports showing the principal choices first and revealing secondary detail on request. The opening label must make that detail easy to find. This is design guidance, not a trial of dietary onboarding.
GOV.UK's checkbox guidance fits independently selectable exclusions. NN/g's switch guidance reserves switches for changes that take effect immediately; checkboxes suit choices collected before a confirmation button.
The meta-analysis argues against treating every extra choice as harmful. It also does not show that complexity is harmless: the variation is a reason to test whether people can accurately express their own restrictions. The suggested exclusions are product hypotheses, not an evidence-ranked list of the most common foods people avoid.
A food someone does not eat is different from a mild dislike, and neither should be presented as an allergy-safety guarantee. The current prompt treats the saved diet and note as constraints, while preserving plainly visible food and label evidence. The checklist and note both reach meal analysis and the coach.
The smaller setup, and what remains to test
The revised setup retains simple questions, one example showing an estimate being corrected, and a personal plan. Health connection sits beside measurements. Pace has a dedicated screen directly after the goal, so the two decisions stay together without crowding the plan review. Body, activity and dietary answers precede them so the calculator has its required inputs. Target weight and its projection are optional. Default views fit without scrolling on the tested phone sizes; opening an editor or explanation may require scrolling. Notifications and detailed instruction arrive when their purpose becomes relevant.
Setup includes a deliberate, roughly five-second visual presentation after the real calculation returns. It assembles the calorie target and shared nutrient cards in place, then becomes the review screen. This is a product choice to give the resulting plan more emphasis, not time the calculator needs, a claim that an account has been created, or evidence of improved conversion. It may add perceived value or create impatience; that tradeoff still needs a Snapkin experiment. Reduced-motion mode keeps the cards still.
The test should compare paid subscriptions and realized revenue per setup starter, alongside first-meal logging, continued use, renewals and refunds. Price, trial and acquisition mix need to remain comparable. Neither a higher completion rate nor more trial starts alone establishes that the experience improved.
Ask for notification permission before setup finishes
After the meal-logging example, an optional reminder screen explains that complete logging makes daily totals more useful. Its Allow button requests native notification permission; Not now continues without requesting it. Permission is not a subscription requirement. The default is one daily reminder only when nothing has been logged that local day, not a notification for every missing meal. Settings offers custom times and per-meal options. Existing saved schedules are preserved.
Permission can be granted before account creation. The app registers the device with the server after sign-in and email verification, without prompting again. Browser previews simulate the permission choice; web push is not supported. This is a product choice, not evidence that reminders improve weight loss or that everyone should enable them.