Derive required components from two product views

A design system becomes easier to use when its initial scope comes from actual interface tasks. Start with views the product really needs. A long list of possible components says little yet about which variants your team should use.

Record two views and their tasks

A fictional customer portal provides the worked example. In the project overview, clients should recognise and open a project. In the detail view, they should read its status and download approved documents. Both views belong to the same product but serve different tasks.

Record each visible element’s purpose, content and possible states. A similar frame is not enough reason to create a shared component. Whether meaning and behaviour also match matters.

Decide on shared foundations and separate compositions

The project card and file row can share basic elements. They do not therefore have to become the same large component. An exception makes sense if a shared variant unnecessarily obscures the task concerned.

Fill in a concrete library entry

For the status indicator, the example records: use in both project views; status text from project data; colour only as an additional presentation; no click action of its own. Open points are the required status values and handling long translations. These decisions need resolving before implementation, rather than disappearing behind arbitrary sample values.

Carbon describes components as designed and coded solutions for specific interface tasks. Apply this perspective to selection: document a component’s purpose, variants and limits together. An existing name in a library is not sufficient as a usage rule.

Check the initial scope in both views

First place the selected components in both designs. Check typical content and long translations; for interactive elements, also check keyboard operation and state changes. Record which version is used and which difference is deliberately retained. The example provides a working draft for this, rather than an already implemented library. The next step is a manageable selection with open points resolved, which the team can then implement and test.

Sources

• Carbon: Components Overview