Too Many Business States? Build a State Model First

Too many states usually do not mean the tag component is inadequate. They mean the team has packed workflow phase, processing result, risk warning, and user task into one “status” field. Clarify the business model before designing the interface, and many states disappear naturally.

Too many states usually do not mean the tag component is inadequate. They mean the team has packed workflow phase, processing result, risk warning, and user task into one “status” field. Clarify the business model before designing the interface, and many states disappear naturally.

01 Separate Four Types of Information That Teams Often Mix

Treating “Awaiting my approval” and “High risk” as business states creates unmanageable combinations: high-risk awaiting my approval, standard awaiting my approval, high-risk awaiting someone else, and so on.

Keep business states mutually exclusive. Model tasks and risks as separate fields, then combine them in the interface according to context.

02 Describe a State Machine With Six Elements

Object

What owns the state? An order, contract, ticket, approval request, and payment batch can each have its own lifecycle. Do not use one state table to describe multiple objects.

State

The stable phase an object occupies at one moment. Use names business users understand, not API codes.

Event

What triggers the transition—for example submit, approve, payment callback, timeout, or cancel.

Condition

When is the transition allowed? Amounts above a threshold may require secondary approval, and only the draft creator may withdraw.

Actor

Who triggers or confirms the transition: user, administrator, scheduled job, or third-party system.

Action and Result

What else must happen with the state change: record a log, send a notification, lock fields, generate an invoice, or update inventory.

If a transition cannot explain these six elements, interface design will likely accumulate patches later.

03 Build a State Transition Table

For example, a contract might use:

This table helps engineering, QA, and operations confirm rules more effectively than a flowchart full of arrows. Use the flowchart for the big picture and the transition table for precise rules.

04 State Names Should Describe Facts, Not Vague Sentiment

“Processing,” “Completed,” and “Exception” sound universal but say too little. Is processing waiting for the user, the system, or a third party? Does completed mean the business process, data synchronization, or payment finished?

Follow these guidelines:

• Name the current fact, not a future promise;
• Use consistent grammar at the same level;
• Do not rely on “Normal” and “Exception” as the only explanation;
• User tasks may say “Awaiting my…,” but should not become the object's primary state;
• Distinguish successful, canceled, rejected, failed, and expired terminal states.

05 Color Supports Meaning; It Does Not Define It

The same green may mean approved, completed, active, or normal in different modules. If users must infer meaning from color, the system lacks sufficient text.

Every status component needs clear copy. Color, icon, and shape improve scanning and should stay consistent across modules. High-risk states may include cause, deadline, or next step, but a full paragraph does not belong inside a tag.

06 Define Available Actions for Every State

Designers often draw a row of buttons first and ask product which states should show them. A safer approach defines actions in the state specification:

• Which actions the current state allows;
• Which role can execute each action;
• What preconditions apply;
• Whether confirmation or a reason is required;
• Which state follows;
• Whether the action is reversible;
• Where a failure leaves the object.

The same “Withdraw” label can mean very different things after draft submission, after approval, or after payment initiation. Do not reuse the button name without defining its business meaning.

07 Derive Compound States Instead of Adding Endless Enum Values

Suppose a ticket's primary state is “In progress” while it is also overdue and high priority. Do not create a new “High-priority overdue in progress” state. Derive risk labels and user tasks through rules:

The list can then show “In progress / Overdue / Assigned to me,” while filters and reporting remain clear.

08 Model Exceptions and Timeouts

Real business rarely stays on the ideal path. Discuss at least:

• Delayed or duplicate third-party callbacks;
• Repeated user submission;
• Concurrent modification during a transition;
• An approver who leaves or loses access;
• Long-running task timeout;
• Success after system retry;
• Manual correction;
• Legacy data without the new state field.

Not every exception needs a new business state. Some belong as tasks, errors, or system events. What matters is whether users understand the current fact and the resolution.

09 Preserve an Understandable State History

History should not say only “State changed from 3 to 4.” Show who performed what action, when, and why, plus the before and after values. Returns, cancellations, and manual corrections should preserve a reason.

For automatic transitions, explicitly state “The system closed this item automatically under the timeout rule” rather than presenting it as a person's action.

10 Test States Through Simulation, Not Imagination

Run the state model through realistic scenarios:

1. Normal completion;

2. Return midway and resubmit;

3. Concurrent operation;

4. Permission revocation;

5. Retry after an external API failure;

6. Timeout, cancellation, and recovery;

7. Legacy data migration;

8. Entry through a notification deep link.

For each scenario, check that interface copy, buttons, notifications, list filters, detail timeline, and backend results agree. A closed state-machine diagram does not guarantee a closed product experience.

11 Make the State Specification a Shared Asset

Maintain a specification card for every state: name, definition, entry and exit conditions, eligible roles, available actions, UI copy, color and icon, notifications, audit, and data fields. Product, design, engineering, QA, and operations should use the same asset instead of maintaining conflicting versions.

Frequently Asked Questions

How many states are too many?

There is no fixed number. If several states differ only by label color or owner, split those dimensions. If every state carries distinct business rules and lifecycle meaning, a larger set may be reasonable. The test is whether every transition can be explained and verified clearly.

Should “Under review” and “Awaiting my review” be separate states?

Usually not. The first is the object's state; the second is a task view derived for the current user. Modeling them separately lets each approver see their own tasks while the object keeps one business state.

What happens to historical data when states change?

Create mappings for old values, migration rules, and a treatment for unmappable records. If reporting definitions change, decide whether historical reports use old or new definitions and retain version notes.

12 Put Research and Design Into Product Decisions