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.
Fill it in below. Your result updates as you go.
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 | |
|---|---|---|---|---|
Questions 2 to 5
012. 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
- Your answer
- Your answer
023. 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
- Your answer
- Your answer
034. 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
- Your answer
- Your answer
045. 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
- Your answer
- Your answer
If your registration numbers are below what you expected, we can look at the flow with you.
A short review of a live product, starting with where people stop and what they are asked for before they get anything.
Find the right AI starting point.
Align the business case, governance and first implementation—without starting a large programme.