# Help users reach their first useful outcome

- **Canonical URL:** https://playbook.affpartners.io/en/practices/quality-first-value/index.html
- **Markdown version:** https://playbook.affpartners.io/en/practices/quality-first-value/index.md
- **Module:** Product quality
- **Time:** 90 minutes for the first analysis

The first useful outcome is the moment when someone gets a small, tangible result—not merely opens the app. Find that moment and remove what blocks it in the first session.

## Outcome

A first-session journey map with one useful outcome, the path to it, unnecessary barriers, and one change for the next release.

## Show value first, then ask for effort

A new user does not yet trust the app and does not know why they should fill out a profile, enable notifications, or sit through a long onboarding. Let them see real value as early as possible — even if it is just a personalized collection, a saved item, or a first clear result.

## What you will need

- **Clean install:** A phone without a saved account, plus the previous app version from the store for an honest first pass.
- **Colleague:** Product, support, or design for 20 minutes to check a newcomer's expectations against real questions.
- **Period:** Data on new users for the last 14–30 days without major ad spikes.

## Terms in plain language

- **CTA — The main action offered to the user:** Definition: A CTA is a button or link with a clear next step and expected outcome. Example: “Continue registration” is clearer than “Next”.
- **Analytics event — A record of a specific user action:** Definition: The app sends an event when a user opens a screen, taps a button, or completes an action. Example: registration_started and registration_completed reveal how many people abandon registration.
- **Conversion — The share of people moving to the next step:** Definition: Shows how many people who started a step completed it or reached the next one. Example: 80 registrations completed from 100 started: 80 ÷ 100 × 100% = 80% conversion.
- **D1 / D7 / D30 — Return after 1, 7, or 30 days:** Definition: D means day. The metric shows what share of a new user group returned after the selected number of days. Example: D7 = 18% means 18 of every 100 new users returned after seven days.

## When to use it

New users install the app but do not finish onboarding, do not complete the first useful action, or do not come back the next day.

## Where to get signals

Do not try to prove perfect causality right away. Combine the numbers with live user questions and a manual walkthrough.

- **First-launch funnel**
  - **Source:** In AppMetrica, Firebase, or another report, build: first launch → onboarding started → onboarding completed → first useful action.
  - **If access is unavailable:** If the event you need does not exist, ask a developer for the closest technical event and file a task for proper tracking.
- **Support and reviews**
  - **Source:** Take the last 20 questions from new users and mark where they did not understand the value, a permission, a condition, or the next step.
  - **If access is unavailable:** If there are few requests, ask three colleagues unfamiliar with the product to go through the first launch and voice their doubts aloud.
- **Manual walkthrough**
  - **Source:** Record the screen, action, time, and the user's question at every step from install to the first result.
  - **If access is unavailable:** Even without analytics you will get a list of barriers and can pick one safe simplification.

## Map the path to the first useful outcome

1. **Name one useful result.** Define an action after which a newcomer can honestly say: “Now I understand why I need this app.” Do not treat registration, consent, or a deposit as value in itself.
   - **Where to do it:** At the top of the journey map or in a short team document.
   - **Example:** The user saw a clear collection for their interest and saved one item.
2. **Walk the journey from scratch.** Reinstall the app and record every screen, required field, permission, and wait on the way to the result.
   - **Where to do it:** On a real iOS and Android device, not only in a test build.
   - **Example:** Reaching the collection takes 9 screens, 7 fields, and two permission prompts.
3. **Separate the necessary from the habitual.** For each step ask: is it impossible to show value without it, or is the team simply used to doing it upfront? Move optional requests to after the result.
   - **Where to do it:** In the second and third columns of the journey map.
   - **Example:** The time zone is needed for notifications later, not for the first collection — move the request.
4. **Keep one clear CTA.** Every screen should have one main next step that describes the outcome, not the internal process.
   - **Where to do it:** On key screens before and right after the first useful outcome.
   - **Example:** Instead of “Continue” — “Show my collection”; after the result — “Save collection.”
5. **Choose one simplification.** Fix the change, owner, and metrics before development. Do not mix a shorter form, new copy, and a redesign of every screen in one test.
   - **Where to do it:** In the next release's task and the journey map.
   - **Example:** Move five profile fields to after the first collection; owner — product manager; check after 14 days.

## Practical examples

- **Before: a survey ahead of the result:** New users went through 9 screens and 7 fields before the first collection. After moving five fields past the result, the path shrank to 4 screens — one barrier changed, not the whole onboarding.
- **After: permission at a clear moment:** The push permission is requested not at first launch but after an item is saved: the app first explains it will report changes to that exact item.

## Finished artifact: Map of the first useful experience

Capture the current journey in five rows. Do not design a whole new onboarding — pick one barrier to remove first.

| Stage | What happens now | What we change | Done if |
| --- | --- | --- | --- |
| First screen | Three promo slides | Keep one value promise | Clear within 5 seconds |
| Registration | 7 required fields | Keep email and password only | Can continue without a profile |
| Permissions | Push requested immediately | Ask after an item is saved | There is clear context |
| First useful outcome | Collection shown only after a survey | Show a basic collection earlier | Result in the first session |
| Next step | Three identical buttons | One “Save collection” CTA | The action is obvious |

First change: show a basic collection before the full survey. Owner — product + mobile team. Check after 14 days: conversion to the first useful outcome and the median time to reach it.

## Checklist before development

If the team cannot answer an item, go back to the journey map — you do not need a new interface yet.

- [ ] The first useful outcome is described as a user action, not a business metric.
- [ ] The journey was walked on a clean install on iOS and Android.
- [ ] There is a clear reason for every required field and permission.
- [ ] Before the first useful outcome, every screen has one main CTA.
- [ ] One change is chosen, with an owner, a period, and a check metric.

## How to know the journey improved

- **Reached the value:** The share of new users who completed the first useful action in their first session.
- **Reached it faster:** The median time and number of screens from first launch to the useful result.
- **Kept the trust:** Errors, early uninstalls, support questions, and D1 did not get worse after the change.

## Key rule

If the first useful action cannot be described in one sentence, agree on it within the team first — only then change the onboarding.

---

- [HTML version](https://playbook.affpartners.io/en/practices/quality-first-value/index.html)
- [All practices](https://playbook.affpartners.io/en/)