Foundations
Semantic tokens, typography, layout, motion, accessibility and content conventions express the values and rules several products share.
Services
Design Systems
Tcules helps product organisations define, build and operate design systems across product semantics, foundations, tokens, components, Figma, code, documentation, contribution, release and adoption.
- Design systems
- Tokens and components
- Figma and code
- Governance and adoption
A component library is only one representation of the system
The objective is not a larger library. It is a dependable shared answer to decisions that several product teams would otherwise keep making alone.
A library can be visually consistent and still fail as shared infrastructure. The same component name may describe different behaviour in Figma and code. Product teams may need a state the library does not cover. Contribution may be too slow for release work. A new version may exist while most products remain on an older fork.
When a team builds a local answer under those conditions, that decision may be rational. A system earns use when the supported route is easier to understand, extend and release than the workaround.
The useful questions are therefore:
- Which recurring product decisions should the system settle?
- Which variations are legitimate rather than drift?
- Which representation governs each concern?
- What happens when the shared answer does not fit?
- Who owns the change and the migration?
- What evidence shows use inside released products?
The design system contains five connected products
Components and patterns
Components define anatomy, properties, states, content and interaction contracts. Patterns describe how components compose around recurring product work.
Design assets
Libraries, examples and templates help product designers use the shared decisions without reconstructing them.
Code and documentation
Runtime components, APIs, stories, tests and guidance make the system implementable and inspectable.
Operating model
Ownership, contribution, exceptions, release, deprecation, migration and adoption determine whether the other four remain current.
Ignoring one product creates local efficiency and cross-team drift. A design-only library cannot govern runtime behaviour. A code library without product semantics makes local composition the place where meaning diverges. Documentation without a change path becomes a record of decisions nobody can maintain.
Choose the responsibility from the system condition
Use the current system condition to choose the route and the decision that route owns.
| Current condition | Leading route | Decision it owns |
|---|---|---|
Teams disagree about what should become shared | Scope, authority, ownership and investment boundary | |
The shared scope is agreed and needs a maintained system | Foundations, components, code, documentation, release and migration | |
Figma and code describe different contracts | Source authority, mapping, intentional difference and change flow | |
Teams bypass, fork or remain on old versions | Contribution, exceptions, release, migration and evidence of use | |
The cause of drift is disputed | Diagnosis before further investment |
Evidence of design-system practice
Auxentios
For an industrial CPQ MVP, the public record supports domain and stakeholder research, eight qualitative interviews, MVP design and component-based visual-system work with components, tokens, guidelines and layout rules. It does not establish coded implementation or adoption across a client organisation.
Doodle
For an enterprise scheduling capability, the retained record supports interface design and bounded UI work using existing and added design-system components. It does not establish a complete organisational design-system programme.
Matter
Matter is an open-source Tcules design-system project published as a Figma Community Edition. It demonstrates Tcules-created foundations, components and design-to-development intent. It does not establish client adoption, active maintenance, coded parity or universal accessibility conformance.
AI-generated interfaces increase the value of explicit system contracts
Tokens, semantic component names, typed properties, examples, tests and accessibility rules give people and coding agents better context than a screenshot. They also make divergence easier to detect.
They do not make generated implementation correct. Product-specific composition, real content, exceptional state, accessibility and release acceptance still require accountable review. Faster generation raises the cost of unclear semantics because an ambiguous rule can be repeated across more surfaces sooner.
A released system still needs ownership
The organisation must know who decides shared meaning, who maintains design and code, who reviews contributions, how exceptions are recorded, how releases reach products and what happens when an owner is unavailable.
Tcules can establish that operating path. Product teams retain responsibility for product-specific composition, user evidence and the complete accessibility of their released experience.
Start with the repeated decision
Bring one decision that several teams keep remaking, the design and code objects that represent it, and what a product team does when the system has no answer. That is enough to locate whether the first need is diagnosis, strategy, implementation, alignment or adoption.
Locate the first system decision
Bring one repeated decision, the design and code objects that represent it, and the point where the current system has no answer.