Case 05 / 06 — Selected Work
Docker’s first CLI design system, now the organizational standard for terminal surfaces.
Docker’s CLI grew organically: inconsistent patterns, styles and terminology across commands, with no shared system for designing terminal experiences. Every team reinvented conventions; users paid in relearning.
The system started with evidence, not taste. DockerCon 2023 research interviewed 10 CLI users and community captains on how they actually read and trust terminal output. In parallel, an audit of Docker's own commands catalogued the drift: inconsistent sectioning, casing, color use, and synonym churn ("service" vs "container" vs "app") across products.
The finding: users don't fear the CLI, they fear inconsistency. Every unexpected format is a small trust tax.
The first draft (27 Mar 2023) turned the research into a system: command anatomy, section and hierarchy rules, terminology decisions, and a component library for terminal surfaces (tables, key-value blocks, status chips, color semantics for state). The library shipped in Figma (CLI – Design System.fig) so PMs and engineers could reuse patterns instead of inventing them.
The core trade-off: codified conventions constrain one-off command creativity. Exceptions are allowed, but they have to be argued for, which is exactly what turns a style guide into a system.
Each card defines the job, the design response, the objective, the measured outcome, and the trade-off made.
“Design a new CLI command that feels like Docker”
“Reuse proven patterns instead of inventing them”
“Align on terminology and structure”
Impact is leverage-shaped: it changed how other teams design, which is hard to attribute to a single metric. Sources: Notion DDS-CLI pages, Drive .fig, Slack.
A design system is only alive if someone owns it. The maintenance role is the deliverable; the Figma file is just its current snapshot.
Exported from the original Figma files with figx.
