Designer-to-designer, designer-to-reader.

The documentation voice is what you're reading now. It is direct, technical, peer-to-peer. It assumes the reader is a designer or an engineer who knows what a design system is. It uses precise language; it doesn't flatter; it has opinions.

The production voice is what appears on the case study pages, the articles, and the home. It is essay-like, observational, slower. It assumes the reader is a hiring manager, a fellow designer, or a curious visitor. It makes arguments; it doesn't list features.

• Documentation voice: /designsystem/** and any other docs.
• Production voice: /, /work/**, /writing/**, /about.
• Neither: microcopy inside components (button labels, helper text). That copy is its own thing — see the writing examples.

The site has three audiences, and they each read a different part of the system.

• Hiring managers read the production voice — the home, the case studies, the articles. They want to see how I think.
• Designers read the design system, in either voice. They want to see how the system was built.
• Engineers read the design system, mostly the documentation voice. They want to see the components, the patterns, and the contract.

1. Plain words, technical when needed. "Tokens" instead of "design language atoms". "Component" instead of "atomic design unit". The system is a craft, not a discipline.
2. One voice per page. A page is either documentation voice or production voice. Mixing them reads as a brand trying to be two things.
3. The reader is a peer. Not a customer, not a student. A peer. The tone assumes the reader is doing the same work and would benefit from an argument, not a sales pitch.