Gōshi Design System

A component library and UI framework engineered to span enterprise, consumer and physical products. Enterprise is the tier I am building first.

Role
Sole designer
Timeline
Started on 6 September 2025
Team
Self-initiated project
Status
In progress
Design
Figma, Iconoir
Build
Code framework and markdown specs

Why this exists.

I have been the sole designer at a technology-focused vendor company since August 2023. Three clients, three projects running in parallel, no shared design layer underneath any of them.

In that setup the system is whatever the last project needed. Patterns get redrawn, decisions get remade, and nothing accumulates. It holds at three projects. It does not hold at ten.

Gōshi is that missing layer, built on my own time and in the open. The products I ship are covered by NDA. The reasoning does not have to be.

One framework, several kinds of product.

Gōshi is scoped wider than a single library. Enterprise portals, consumer apps, and physical interfaces like kiosks, handheld terminals and home appliances all sit inside it, because they can share a foundation even when they cannot share a component.

Enterprise is the tier I am building first, and this case study covers that one.

Three artefacts, not one.

The Figma library is where the design work happens. The code framework is what engineering consumes. Between those two sits the gap where most systems quietly drift apart.

So there is a third artefact, and it is written. Markdown specs carrying the naming dictionary, the vocabulary each component is described in, the rules that cannot be breached, and how a design decision is expected to arrive in implementation.

A component is not finished when it looks right in a frame. It is finished when the name, the states, the constraints and the implementation notes agree in all three places.

The specs are written to be read by a person and by a coding agent. I am the only one maintaining this, so the handoff has to survive without me in the room.

Foundation library — Type Set
Foundation library — Colour Palette
_Enterprise Design System
goshi/specs/button.md
# Button## Dictionaryvariant        primary | secondary | tertiary | ghost | dangersize           sm | md | lgstate          default | hover | focus | active | disabled | loading## VocabularyLabel, never text. Leading icon, never left icon.Destructive is danger. It is never warning.## Rules, do not breach- One primary action per view. No exceptions.- Label is a verb. "Save", not "OK".- Focus ring binds to a token, never a raw shadow.- Disabled is never the only signal. Say why.- Target 24px enterprise, 48px kiosk. Same component.## Implementationtoken          --goshi-button-primary-bg  ->  color/action/primaryprops          variant, size, iconStart, loading, disableda11y           aria-busy while loading. Never aria-disabled alone.

Three rules I gave it.

Foundations version separately from components, because a colour change should not force a component release.

Icons are borrowed, not drawn. A bespoke icon library is the fastest way to stall a system built by one person.

Each platform gets its own package rather than one library stretched thin. A kiosk pressed with a gloved finger needs 48 to 64px targets and 7:1 contrast against glare. An enterprise table read across an eight-hour shift needs 24px targets, 4.5:1 text, and density a kiosk would never survive. Same foundation, different rulebook.

What it helps with.

Inside a project, it removes the part of the work that should never be redesigned. Inputs, tables, navigation and their states arrive already decided, so the time goes to the actual problem instead of the primitives.

Across projects, it gives parallel clients one vocabulary. A pattern proven on one job is available to the next without being redrawn from memory.

Across platforms, it is the reason a kiosk and an enterprise portal can share a foundation without sharing a component set.

And for anyone reviewing my work, it is the part that is visible. The products are under NDA. The thinking behind them does not have to be.

What is next.

The system is still in progress. Foundations are set and the component library is filling out, with spacing and utilities still open.

The honest gap is that Gōshi has not yet carried a product end to end. The real test is whether it survives contact with a deadline, and that has not happened.

So I am not waiting for the other tiers before writing code. The enterprise components go into development now, alongside the design work rather than after it. A system that only exists in Figma has not been tested, and the fastest way to find out what is wrong with a component is to build it.