A construction business needs software that makes ordinary work easier: finding a record, entering a quantity, recording time, or checking whether a change was saved. Those interactions deserve as much attention as the larger feature they belong to. Our design system gives them a common foundation.
We’re developing it alongside our shared platform and our construction-first product work. It includes interface components, interaction patterns, and the visual rules that connect them. The purpose is to give each product a consistent starting point, so the team can spend more attention on the way an industry actually works.
Consistency that goes beyond appearance
A recognizable button is useful. A predictable way to save, correct an error, or find the next record is more useful. When those behaviors vary from screen to screen, people have to learn the application repeatedly. A shared design system lets related screens use the same language for the same action.
That language includes typography, spacing, color, borders, and focus states. These choices come from shared design tokens: named values for roles such as primary text, supporting text, a surface, or a selected item. Changing a role can then update the components that use it, instead of requiring an independent decision on every screen.
The system supports themes and light and dark schemes. Products can have their own character while retaining familiar controls and interaction patterns. The goal is a clear hierarchy: records and decisions get the attention; the interface helps organize them.
Forms that help people complete the task
Forms are where business software asks people to turn their knowledge into a record. A field can be technically valid and still be frustrating: an error appears before someone has finished typing, the page says something is wrong without identifying the field, or a failed submission leaves the person searching for the problem.
Our form pattern includes schema-based validation, with visible errors deferred until a field loses focus or the person attempts to submit. An error is associated with its control so that it has a clear location. When submission finds invalid fields, focus moves to the first one that needs attention.
These are small behaviors with a practical purpose. Someone correcting an entry gets a next step they can act on. The application still has to choose sensible labels, explain its business rules, and validate information on the server. The design system provides a repeatable pattern for presenting that work to the person using it.
A save should communicate what is happening
After entering information, a person needs to know whether the application is still working. Our save control has a pending state, keeps keyboard focus in place, and guards repeated presses while the operation it was given remains pending. For an asynchronous save, it waits for the promise returned by the application before clearing its pending state.
That gives product teams a consistent way to express an operation in progress. It also gives the person at the keyboard continuity: their place in the interface should not disappear just because they pressed Save.
A control cannot guarantee that data reached the server. The application owns persistence, server validation, and the response to a failed request. Keeping that responsibility explicit helps us design feedback that describes the actual result, including when something still needs attention.
Data views for people who work through records
A table in an operational product is often a working surface. People need to find a subset of records, compare values, select several rows, or change a value without opening a separate page for every item. A useful data view needs to support those tasks without presenting every possible tool at once.
Our grid foundation includes sorting, filtering, column controls, grouping, and selection. More involved views can use editable cells, clipboard operations, undo and redo, aggregation, and pivoting. These are configurable capabilities. A product team chooses the combination that fits the task.
The grid also has paging and virtualization support. Virtualization renders a window of visible rows while preserving information about the larger row structure for assistive technology. It is a way to handle a substantial record set deliberately; it does not remove the need to test the data access and behavior of the finished screen.
For construction, the questions are concrete: which inventory records belong in this view, which columns help someone make a decision, and which actions should be available together? Those are product decisions to make with people who know the work. The shared grid gives us building blocks for the answer.
| Foundation | What the person using it gains | What the product team decides |
|---|---|---|
| Form patterns | Errors linked to fields and a clear place to continue | Labels, business rules, and server validation |
| Save behavior | Feedback while an operation is pending | Persistence, failure handling, and confirmation |
| Data views | Ways to find, compare, select, and edit records | Relevant columns, available actions, and permissions |
| Feedback states | An explanation when data is absent, loading, or unavailable | The cause, wording, and useful next action |
Empty, loading, and failed are different situations
An empty area on a screen is ambiguous. It might mean that no records exist, a filter excludes everything, a request is still running, or the request failed. Those situations require different explanations and different next steps.
The design system has separate empty, loading, and error states. They provide a heading, supporting explanation, and room for an action supplied by the application. Loading patterns can reserve space for the content that follows. Optional persistent announcements provide another way to communicate a state change to screen-reader users.
A useful product chooses its action carefully. Creating a first record makes sense when nothing exists. Adjusting a filter makes sense when nothing matches. Retrying makes sense when a request can be attempted again. The reusable component supplies the structure; the product supplies the meaning.
The same care across different ways of working
The application shell responds to the space available to it. On wider layouts, navigation can remain in a sidebar. In a narrower container, it becomes a drawer, with touch-sized destinations and a drawer that closes after a selection. The person keeps the same places to go while the frame adapts.
Keyboard focus, labels, described validation errors, and reduced-motion styles are part of the foundation too. These are concrete implementation choices that support different ways of using the software. The finished application still needs review and testing with its actual screens, content, and workflows.
Shared interface messages can also be overridden centrally. That gives products a place to adapt language and terminology without rewriting individual controls. Industry vocabulary matters here: a generic label can be technically correct and still be the wrong word for the person doing the job.
A foundation that can change with the product
Our applications draw from a shared, versioned set of interface components. We improve those components at their source and adopt updates deliberately. Product teams can build specialized workflows around them while keeping the common behavior coherent.
That balance matters. Reusing a pattern is valuable when the task is familiar; changing the pattern is valuable when the task calls for it. The design system should help us make that decision carefully, then carry the useful learning into later work.
Inventory management and time tracking are our first construction focus. Presales, including estimating and takeoffs, follows. Each area needs its own domain decisions and its own testing. The design system contributes the everyday interactions underneath those decisions, so a growing product can continue to feel like one coherent place to work.