User story:
As the Growth team, I want to explore how logged-in users interact with Special:CreateAccount so that we can reduce confusion, align with standard UX patterns, and ensure that account creation behaves as expected for both newcomers and experienced editors.
User problem
Account creation is the gateway to meaningful participation on Wikimedia projects, yet it remains an outdated experience in the newcomer journey. The current flows impose high cognitive load, present limited or confusing value propositions, and rely on legacy interface patterns that no longer reflect contemporary expectations. As a result, many potential contributors disengage before they have a chance to join the community.
Other notes to consider:
Special:CreateAccount is not only used for traditional new account creation, but it is also used by experienced logged-in editors to create accounts for others. This dual use occasionally leads to confusion and deviates from standard web conventions.
Related: T284927: Special:CreateAccount should warn against creating a new account if already logged in
On most websites that require a login, visiting an account creation page while already logged in triggers one of the following behaviors:
The user is redirected to their homepage or profile, or
The system displays a clear message indicating that account creation is unavailable while logged in.
In contrast, Wikipedia currently allows logged-in users to access a functioning account creation form. This can cause:
- Confusion about whether they are creating a separate account or modifying their own
- Unintended duplicate account creation
- A user experience that feels inconsistent with broader web norms
We should explore design solutions that maintain functionality for trusted users who intentionally create accounts for others, while preventing confusion for typical logged-in users who may reach this form unintentionally.
For logged in account holders that visit Special:CreateAccount, the form will mostly have the same fields, it will do the same checks (does the proposed username pass AbuseFilter etc.), it will mostly perform the same actions.
Differences:
- Depending on user permissions, rate limits (new users / day / IP) will be loosened. Those are anti-vandalism measures which aren't needed for trusted users, and e.g. for editathons one might need to create many accounts.
- There will be a bunch of extra checkboxes if the user has sufficient permissions (override AbuseFilter, override SpamBlacklist) - we don't want account creators to accidentally create an account with an unwanted name when they weren't aware that that name would be filtered, but we do want them to be able to intentionally override such filters.
- There will be a "create by email" button which sends a temporary password to the new user, rather than expecting the password to be entered in the signup form.
- The account creation will be logged as "User X created User Y".
Workflows that use Special:CreateAccount
| Workflow | UI differences | Before | After |
|---|---|---|---|
| Sign up | - | Anonymous | Logged in |
| Get named account | warning box | Temp account | Logged in |
| Switch to a new account | warning box + extra options | Logged in | Logged in as different user |
| Create a new account for another user | warning box + extra options | Logged in | Logged in as same user |
Acceptance Criteria:
Apply the learnings from T410558: Design Research: Account Registration audit and best-practice review to begin an early design exploration of wiki account creation on mobile and desktop, informed by UX best practices.
