Working standards / public edition
Digital Design Standards
Practical guidance for clear, responsive, reliable digital products. Scope: websites, dashboards, app interfaces, and their supporting APIs. Public edition. Last reviewed: 2026-11-12.
Principles
These standards put First Principles into practice:
- Start With Reality: measure before adding complexity.
- Prefer Simplicity, Not Simplism: simple design, one authoritative reference.
- Transparency: honest states, verified outcomes.
- Design for Change and Failure: recoverable, maintainable systems.
Accessibility remains a requirement throughout the standards below.
Using these standards
This document defines our digital design standards. For the complete collection, see Standards. UI work must apply UI responsiveness; supporting API changes must also apply the API architecture and scalability standard. People and digital agents can use the same guidance to identify the requirements relevant to a project.
A standard describes intended practice, not proof that an existing product implements it. Apply it to new work and relevant edits; verify affected behavior before claiming adoption.
Sections and current coverage
| Section | Current guidance | Coverage |
|---|---|---|
| Foundations | Principles | Simplicity, honest state, resilience, measured decisions, and one source of truth. |
| Responsiveness and interaction | UI responsiveness and pattern selection | Pending/confirmed/error states, preserved work, duplicate/stale-response protection, and purposeful microinteractions. |
| Responsive layout and typography | Layout stability | Dedicated viewport, spacing, and type-scale guidance is future work; no shared numerical specification is adopted here. |
| Accessibility | Accessibility and resilience | Keyboard/focus, status semantics, reduced motion, contrast, and non-color status. Broader accessibility guidance remains future work. |
| Performance and delivery | Responsiveness, bounded upload/prefetch, and measurement | Reduce real latency and unnecessary work; broader delivery budgets remain future work. |
| API architecture and scalability | API standard | Select mechanisms for measured needs; define contracts, access controls, bounded work, and recovery. |
| Validation | UI checks and API verification | Verify affected behavior; record measurements and unverified cases in project documentation. |
Requirements, options, and evidence
- Requirements: apply each standard's correctness, access, accessibility/resilience, and verification safeguards within their stated scope.
- Options: select interaction patterns and architecture mechanisms for actual needs. Example timings, distances, and curves are not universal rules.
- Future guidance: coverage gaps are not silently adopted specifications.
- References: cite established design, accessibility, and API standards from their official publishers; distinguish their requirements from b-tec implementation guidance.
- Evidence: distinguish observed behavior, estimates, and unverified claims. Referencing a standard does not establish product conformance or measured performance.
Maintaining the documentation
These standards evolve as we learn from design, implementation, and real use. Revisions should remain practical, linkable, and independent of any particular product or platform. State what is required, what is optional, what remains future work, and what has actually been verified. Keep product-specific implementation evidence with the product it describes.