Design systems for deep tech products: one language from console to firmware tools

When people think of design systems, they picture consumer apps: buttons, colours, a component library in Figma and in code.

Deep tech products need design systems more, not less. They just need a different kind.

A security or industrial product is rarely a single interface. It’s a web console, a command-line tool, an API, documentation, reports for auditors, sometimes a small screen on a device. Different teams build each part, often with different tools. Without a shared language, the same concept ends up with five names and three colours.

What’s different in deep tech

The vocabulary is the system. In consumer products, consistency is mostly visual. In deep tech, the biggest source of confusion is language. Is it a “device”, an “asset”, a “node” or an “endpoint”? Is a finding “critical”, “high” or “severe”? Agreeing on terms, and enforcing them across the console, the CLI, the API and the docs, is the most valuable work a design system can do here.

States carry risk. Status colours and labels aren’t decoration. A user acts on them. They must be consistent everywhere, they must never rely on colour alone, and their meaning must be documented with the same precision as an API.

Engineers are the main contributors. Many interfaces in deep tech are built by engineers without a designer in the room. The design system must work for them: clear rules, good defaults, components that are easy to use correctly and hard to use wrongly.

Data density is real. Experts need dense tables, logs and graphs. A design system built for spacious marketing pages won’t serve them. It needs patterns for density that remain readable.

How I’d build one

1. Start with the glossary. Before components, define the domain objects, their states and their names. Put it in the repository, next to the code, where engineers will see it.

2. Use semantic tokens. Name tokens by meaning, not by value: “status-critical”, not “red-600”. It’s the only way to keep consistency across a web console, a terminal palette and a printed report. I wrote about this in Semantic tokens.

3. Cover non-visual surfaces. Error messages, CLI output formats, log levels, report templates and API error codes are part of the experience. Give them rules too.

4. Build accessibility in. Contrast, keyboard navigation, focus states and text alternatives belong in the components themselves, so every team gets them for free. See accessibility in security tools.

5. Keep it small and enforced. A short system that is used everywhere beats a large one that is used nowhere. Lint rules, code review checklists and templates do more than a beautiful documentation site.

Why it matters for the business

Consistency in deep tech isn’t about looking polished. It reduces errors, shortens onboarding for new customers and new engineers, and makes the product easier to audit and to trust.

As I argued in The design system is dead. Long live the design system, the tools change every year. The need for a shared language doesn’t. In complex technical products, that need is simply more obvious.