# Registration audit: five questions to ask of your signup flow

Fill in one row per field in your live registration flow, replacing the example rows, then work through questions 2 to 5 with the person who owns the product and the person who can change it. The counts of what to keep, move and delete and your progress through the questions update as you go. An hour is enough.

## Before you start

Open the registration flow as a new user, with nothing prefilled. Write down every screen in order and every field on each screen, including the optional ones. Note which screens end in a wait for somebody else.

Write the answers down as you go, in the table and in the answer column next to each question, because the list of what to delete falls out of the answers, not the discussion.

## Deciding keep, move or delete

- **Keep** only when the platform cannot do anything for the user without the field on the first visit.
- **Move to first use** sends the field to the screen where the action that needs it happens. The user has a reason to answer there.
- **Move to join by selection** replaces a typed declaration with a pick from a list of organisations that already exist, approved by someone at that organisation who knows the user.
- **Delete** is the answer for a field nothing in the product reads. Rule of thumb: a field read only by reporting is not a registration field.

## 1. What does each field do?

Every field should have a named consumer: a function of the platform that reads it and would behave differently without it. If you cannot name one, somebody wanted it. Four example rows, replace them with your own fields.

| Field | What reads it | When it is first read | Keep, move or delete |
|---|---|---|---|
| Email address | Login, notifications | Immediately | Keep |
| Organisation name | Membership, reporting | Approval, then reporting | Move to join by selection |
| Registered address | Nothing in the product | Never | Delete |
| Role or job title | Segmentation reports | Quarterly reporting | Move to first use |
|  |  |  |  |
|  |  |  |  |
|  |  |  |  |

## Questions 2 to 5

### 2. Could it be asked later?

A field belongs in registration only if the platform cannot do anything for the user without it. Everything else can wait for first use, the moment the user tries to do the thing the field supports. They have a reason to answer then, and you get the answer from people who stayed.

|  | Your answer |
|---|---|
| [ ] For each field kept in question 1, write the first action the user cannot complete without it |  |
| [ ] If that action is not on the first visit, move the field to the screen where the action happens |  |
| [ ] If legal or consent fields must stay, count them and remove something else to make room |  |

### 3. Who is blocked by approval?

Approval is a trust mechanism, and the question is whether the right person is doing the trusting. Write down every approval in the flow, who gives it, and how long a typical user waits.

|  | Your answer |
|---|---|
| [ ] Is the approver someone who knows the user, such as a manager in their organisation, or a central admin working from a form? |  |
| [ ] Does the approver have an incentive to resolve it, or is it one more item in a queue? |  |
| [ ] What does the user see while they wait, and can they do anything at all? |  |

### 4. What happens to an internal user?

Walk the flow as a member of your own staff. Internal users should be seeding the platform with activity, and they are usually the most obstructed group on it.

|  | Your answer |
|---|---|
| [ ] Do staff pass through an approval designed for external users? |  |
| [ ] Do staff have to declare an organisation they already belong to? |  |
| [ ] Can staff attach their work to existing records, or must they create new ones and wait? |  |

### 5. What does a user get before they are asked for anything?

Count the screens, fields and waits between arriving and the first thing of value. If nothing arrives until after approval, the flow is asking for trust before it has earned any.

|  | Your answer |
|---|---|
| [ ] Name the first thing a new user can do, see or save |  |
| [ ] Count everything that stands between the landing page and that moment |  |
| [ ] Decide which of those items could come after it instead |  |

Delete the fields nothing reads. Move the fields read later to the screen where they are used. Move approval to the person who knows the user. Build the internal path. Remove screens rather than improving them, then measure completions per screen again in a month.