A practical component and state inventory for growing business software

Inspect repeated elements in real pages

Collect buttons, fields, tables, messages and dialogs from working lookup, editing and approval screens, with their context. Identical-looking buttons may perform different actions: one submits a record while another moves to a later step. Different-looking lists may also support genuinely different tasks. Compare meaning before deciding that two things should be merged.

For each candidate, record where it appears, the current problem, how often it is used and who owns it. “Make everything consistent” is difficult to accept as a deliverable. Conflicting action names, missing failure feedback and inconsistent treatment of equivalent fields are more concrete starting points.

Record a component’s full contract

• Purpose and exclusions: identify the action and situations where the component should not be used.
• States: cover the normal, focused, disabled, processing, successful and failed states that the actual function requires.
• Inputs: specify text length, whether icons add meaning, and behavior with empty or excessive content.
• Interaction: describe keyboard, touch, repeated activation, closing and return behavior.
• Version: connect the design to its implementation, owner, change reason and replacement scope.

A state inventory is more than several color variants. Disabled states need conditions, processing states need rules about leaving, and failure states need a way to retry or check an uncertain outcome. Design and engineering must agree those behaviors. A stylesheet cannot establish them automatically.

Justify a new component before adding one

The GOV.UK contribution criteria assess whether components are useful, distinct, usable and consistent. This offers a useful management reference without requiring an enterprise to adopt its review process. A proposed component can explain which existing capability is insufficient, why extending it would be inappropriate and which actual pages would reuse the addition.

If the difference is only spacing or wording, improve the existing rule. If behavior differs, such as selecting one object versus an entire group, retain a clearly defined variant. Forcing unrelated behaviors into a single component can create combinations of settings that nobody understands or tests reliably.

Allow controlled coexistence

Apply the new components to one complete task first, including its states and return path. Expand after that path works. Keep version notes so that a shared change does not unexpectedly alter many older screens. Record the boundary for pages that are not being migrated. New work should use the approved version instead of copying old code and creating a third variant.

For example, a hypothetical dialog update adds a check for unsaved input before closing. Read-only and editing dialogs need different behavior; applying the confirmation indiscriminately would interrupt harmless navigation. This illustrates change-impact analysis, not a customer configuration or a requirement that every dialog prompt on close.

Define deliverables that can be used and verified

A commission can deliver component cards, editable designs, agreed running implementations and representative pages. A long visual guide alone may not establish how anything behaves. A design-only engagement does not automatically include code. Check the version, license and limitations of an existing library before deciding whether it can be reused; an inventory is not a reason to replace the technical stack.

1. Use a shared component in at least two different task contexts and verify that its rules still hold.
2. Supply long text, missing values and invalid input to check whether variants behave predictably.
3. Review Chinese and English, narrow screens and keyboard operation, including focus and state feedback.
4. Upgrade one component and inspect its consumers. Record older versions that remain intentionally in use.

When a special page cannot use a shared component, record the reason and maintenance owner. Do not describe a documented exception as full consistency. The inventory succeeds when the next team adding a page can make a clear choice, not when the library contains the largest possible number of components.

Start the inventory with frequently used tables, forms and dialogs, recording their states and consuming pages in the prototype handoff. For an existing system, identify protected behavior using the redesign constraints. When arranging UI design services (Chinese), agree on component scope and state coverage before counting screens; more drawings do not necessarily describe more usable behavior.