Clarify uncertain product decisions in a short written brief before substantial design or implementation work.
Real-world examples not captured yet
This skill shows a gallery of live HTML demos (CDN libraries welcome — GSAP, Three.js, etc.) rendered inline via srcdoc.
Skill markdown
# Write-First Design Use prose to resolve uncertain product decisions while changes are cheap. A clear user brief, existing decision document, or narrowly specified UI edit already provides direction; do not require another brief or approval step. For substantial work with unclear intent, record the intended user outcome, proposed change, rationale, and useful non-goals. Keep this in the response or the project’s existing decision format unless a durable document helps the team. A useful hypothesis is: “We believe [change] will produce [outcome] because [reason].” Adapt the wording to the decision; the outcome matters more than the template. Explain meaningful design choices so a collaborator can evaluate them before investing in expensive implementation. Ask only about unresolved choices that would materially change the work. Otherwise state a reasonable assumption and continue within the authorized scope. Keep the writer close to the builder. Update the rationale when implementation reveals a different tradeoff. Completion is the requested brief, or the implemented and verified change when implementation was requested. ## Source essays - Write-first design - Falling in love with the build - Design for handshakes, not handovers
More from kemiljk
- Ai Output JudgementCritique generated UI, copy, or code when the user requests a quality review of AI output.
- Android Native UIBuild or review Android interfaces in Compose or Views, including Material conventions, accessibility, adaptive layout, and state.
- Apple Native UIBuild or review native Apple interfaces, including platform controls, accessibility, state, navigation, and macOS window behavior.
- Design EngineeringTranslate design intent into production components or improve collaboration between design and engineering.
- Design For RepetitionImprove workflows used repeatedly by examining recurring effort, waiting, setup, interruption, context retention, and expert paths. Use when an experience works once but may become tiring or inefficient in regular use.
- Design System EvolutionDecide how an existing design system should evolve: reuse a component, add a variant, change its API, or introduce a new pattern. Use when real design or code consumers expose a mismatch and a bounded compatibility or migration decision is needed.