Account States

Chaos at the border

Imagine if CBP only categorized travelers as either U.S. citizen or non-citizen. What would happen?

Sure, a U.S. citizen can enter freely. That’s obvious. But for everyone else, officers need more information: visa type, status, duration of stay, restrictions, adjustments in progress, and so on. A traveler with a visa is not just a “non-citizen.” Their VISA status matters. It could be either approved, pending, expired, or adjustment in progress, …etc. Without a well-defined status system, control turns into chaos.

Account states and transitions

Account systems work the same way. Early in a product’s life, it’s tempting to think there are only two states: registered & unregistered user. From a feature or monetization perspective, that might seem sufficient. But as the product grows across platforms, markets, and regulatory environments, those categories become too vague to support real operations. More explicit states start to surface, such as:

• Anonymous user
• Anonymous user with email captured
• Registered user
• Verified user
• Email captured but account locked
• Suspended account due to age restriction

Defining these states aligns teams around the actual condition of an account, not just its feature access.

When states are unclear

When account states are loosely defined, strange things start happening in the product. During my time working on the account system at Pluto TV, I saw cases where a user could already be logged in, yet still receive marketing prompts asking them to sign up. From the user’s perspective, that’s unsettling… “I just gave you my information. Why are you asking me to sign up again?” Behind the scenes, the problem was simple: different teams were operating with different assumptions about what counted as a registered user. That gap between definitions eventually shows up in the interface.

Transitions matter too

States alone aren’t enough. You also need to define how users move between them. For example, consider progressive sign-up: A user provides some personal data on a mobile device. Later they open the app on a TV. If the transition logic isn’t clearly defined across platform teams, the system may ask for the same information again, even though it was already collected. To the user, it feels like the system forgot who they are. In reality, the product team never agreed on what state the account was in

Symptoms of poor state modeling

When account states and transitions aren’t clearly defined, several problems tend to appear:

• Contradictory UI: Logged-in users receiving “sign up” prompts.
• Broken permissions: An account deleted on web still appearing active on other devices.
• Experiments breaking the system: “Quick-and-dirty” growth projects creating states that the core system never anticipated.
• Something else that I have not yet seen..

Over time, these inconsistencies kill trust. And obviously we don’t want that to happen.

Document the model

A simple diagram can prevent many of these issues. For example:

Anonymous
   ↓ (email captured)
Email Captured
   ↓ (account created)
Registered
   ↓ (email verified)
Verified
   ↓ (subscription purchase)
Subscriber

Of course, real products rarely follow a model this simple. What matters is that the diagram documents what each state means and what events trigger transitions between them.

Once that model is shared across teams, many downstream design and engineering decisions become much clearer and predictable. And that’s a good start of a coherent account system.