How to work with the design team
What design is here for
Clarify story and structure, reduce cognitive load, and keep the Pattern Automation and Neuro OS narrative consistent across pages—so visitors never have to relearn our vocabulary.
How to ask
Open a GitHub Issue with goal, audience, deadline, and links (page URL, PR, or screenshot). Use the shared design/engineering channel for quick questions; avoid DMs when the answer should be searchable.
What to bring
Problem before solution: current URL, what users expected, what broke, and business impact. Attach browser, viewport, and theme (light/dark) when visuals misbehave.
How to give feedback
Early: direction, information architecture, and whether the promise matches reality. Late: typography, spacing, motion, microcopy. Tie notes to outcomes (“first-time reader can find X in one scroll”).
Where discussion lives
PR comments for concrete line/CSS feedback tied to a preview build. Longer exploration can use Figma or a short Loom, but decisions land in the PR or Issue so history stays with the repo.
Rhythm
We bias async: proposals in Issues, reviews on previews, short sync only when fork in the road. Planning cadence depends on team size—weekly triage of open design Issues is the default when volume grows.
Current focus
Keeping quality consistent as surface area grows (handbook, Neuro OS pages, experiments) without collapsing into one-off stylesheets.