4 min read - Building a Design System with Angular: Lessons from SoarUI

Building a design system is less about producing a long component list than deciding which interface decisions should be shared. SoarUI, Exceev's Angular and Tailwind design system, is still under active development. Its use in FormAI gives the team a practical setting in which to test those decisions.

The lessons below are engineering principles, not a report of undocumented savings or a claim that SoarUI has reached general availability.

Start with repeated decisions

A component belongs in a shared system when several product surfaces need the same behaviour and the organisation is willing to give that behaviour an owner. Visual similarity alone is not enough.

Before extracting a component, compare the existing implementations. Write down the states, keyboard behaviour, validation rules, responsive constraints and translation needs. If the differences express real product requirements, forcing them into one API will create more overrides than reuse.

This is why a small, well-owned core is more useful than a broad catalogue of abstractions that have not survived product use.

Separate tokens, behaviour and product policy

Three concerns often get mixed together:

• Tokens express visual choices such as colour, spacing and typography.
• Component behaviour covers interaction, focus, validation and state.
• Product policy decides what a particular application allows a user to do.

Keeping these layers distinct makes a system easier to adapt. A product should be able to change its brand tokens without forking interaction logic. A shared form control should not encode a business approval rule that belongs to one application.

SoarUI is designed to adapt to different products and visual identities while maintaining consistent accessibility and interaction standards. That intention still needs validation in every consuming product.

Accessibility is a contract, not a badge

A design system can centralise keyboard behaviour, focus handling and semantic markup. It cannot guarantee that a consuming screen conforms to an accessibility standard. Labels, reading order, error messages, colour choices and surrounding content still matter.

For each shared component, document:

• its accessible name and description requirements;
• the expected keyboard interactions;
• focus entry, movement and return;
• how errors and status changes are announced;
• which contrast decisions belong to the token theme;
• what the consuming application must test.

Automated checks are useful, but manual keyboard and assistive-technology testing remain part of the release decision.

Let a real product challenge the API

An isolated component demonstration can hide the hard parts. Product integration exposes asynchronous data, long translations, permissions, error recovery and existing layout constraints.

FormAI is a confirmed consumer of SoarUI's interface. That relationship gives the SoarUI team a place to discover which abstractions hold up under practical requirements. It does not prove that every component suits every Angular application.

When product use reveals a gap, first decide whether the gap is shared. A product-specific adapter is often healthier than adding another flag to the core component.

Version the contract you can support

Consumers need to know what can change. Define the public inputs, outputs, token names and documented behaviours. Treat undocumented internal markup as private so that maintainers can improve it without creating accidental commitments.

Before a breaking change, identify consumers, provide a migration note and test the change in at least one real integration. The exact release mechanism depends on how the project is distributed; SoarUI has not published a public distribution or licence commitment.

Measure outcomes locally

Do not publish a generic claim that a design system saves a fixed percentage of development time. Establish a baseline in the consuming team and measure:

• time to implement and test a representative screen;
• defects caused by inconsistent behaviour;
• accessibility findings before release;
• effort required for a visual or Angular upgrade;
• product-specific overrides that bypass the system.

If reuse does not reduce repeated work or improve consistency, the answer may be to simplify the component rather than expand the system.

The durable lesson

A useful design system is a maintained agreement between designers, engineers and product teams. Build from repeated decisions, keep product policy out of shared primitives, document the accessibility contract and use real product integration to test each abstraction.

For current public information, see the SoarUI project page and soarui.com.

Sources

• SoarUI official website, reviewed 27 August 2026
• Exceev SoarUI project page, reviewed 27 August 2026