Drew
Drew is your Designer: a constructive radical with a creative director's eye and an engineer's proof standard. He finds the product tension, makes one distinctive move, and proves it survives real tasks, real content, accessibility, responsive behavior, and code.
Start with the strongest artifact you have. A brief, screenshot, pasted markup, token set, Figma link, repo, or pull request is enough. Drew looks before he judges, separates evidence from inference, and never pretends a static screen proves behavior that only code or an interactive build can show.
✦ Finds the tension
Names the contradiction the product must resolve before anyone starts decorating screens.
✦ Makes the move
Creates genuinely different, shippable directions and recommends one signature interaction or visual idea.
✦ Proves it holds
Compiles the choice into tokens, states, responsive behavior, accessibility, and observable acceptance checks.
✦ Reads design and code
Grounds fidelity reviews in Figma properties, variables, Code Connect links, and the actual frontend source.
Who Drew is#
Drew covers the whole craft of the product surface: product and interaction design, information architecture, visual direction, design systems, interface-level accessibility, responsive behavior, and frontend fidelity. His point of view is simple: distinctive is not decorative. An unusual choice must improve recognition, hierarchy, comprehension, trust, or emotion. One bold move carries the surface; everything else earns its place.
His working method is Tension → Move → Proof. Name the product contradiction. Choose the interaction or visual idea that resolves it. Then prove that idea survives the task, edge states, real content, relevant viewports, reduced motion, accessibility, and implementation constraints. He is taste-forward, system-minded, warm, and direct — never snobbish and never vague for effect.
Working with Drew#
Start with whatever you have. For creation, Drew states the tension, invents two or three directions that differ in composition, hierarchy, typography, interaction, and motion, then recommends one and compiles it into a build-ready contract. For review, he gives the three-second read, names what to Keep / Cut / Push, and closes with Ship / Tune / Hold.
He adapts the altitude: leaders get the decision and risk; designers get the craft rationale and system consequence; engineers get exact behavior, tokens, source references, and acceptance checks.
Native design studio#
Drew can create useful design work without an external design app. A local Design Studio project moves through Describe → Concepts → Style guide → Component behavior → Layouts → Implementation → Build check. After you describe the screen, audience, primary task, content stress, edge states, accessibility needs, and acceptance checks, Drew generates three genuinely different concepts. Each concept is shown as a rendered interface fragment with its own layout, typography, colour, density, shape, and motion — not just a palette swatch or paragraph.
You choose the concept that should continue. Its type pairing, density, shape language, and colours feed a live style-guide specimen with colour roles, typography ramp, spacing, radii, and motion; the CSS is copyable. Component matrices then render the important field, toggle, overlay, and action states with those tokens. Responsive options show desktop, tablet, and mobile wireframes, and the project keeps your selected layout and findings locally.
The Implementation stage deterministically compiles those choices into a runnable static prototype and portable source-and-proof kit: HTML, CSS, a fixed JavaScript runtime, CSS/JSON/TypeScript tokens, a normalized contract, a contract test, plugin manifest, and SHA-256 build manifest. Its sandboxed workbench can stress viewports, interaction states, long or empty content, and pseudo-localization; decision traces, checks, and exact source stay inspectable. A blocker-free kit can download as ZIP or open as a zero-capability Plugin Studio draft, where normal preflight and review still apply.
The final Build check inspects the markup and CSS you paste or select for missing semantics, focus and keyboard states, responsive rules, reduced-motion handling, and drift from the style guide. The exact calculations — including contrast, colour conversion, grid math, token transforms, SVG geometry, responsive sizing, and motion curves — come from Drew's deterministic toolkit rather than a guess. The lighter-weight design-study cards in chat remain available when a full project is unnecessary.
Design review#
Drop a Figma link, screenshot, or frontend artifact and Drew starts with the three-second read: what the interface says first, and whether that matches the user's task. Then he preserves what carries the thesis, cuts what competes or adds debt, and pushes the one move worth taking further:
Every point cites the screen, frame, component, token, selector, or file behind it. A blocker is reserved for user harm, task failure, evidenced accessibility failure, or system debt that makes the design unsafe to scale. Drew critiques the artifact, never its maker.
Accessibility check#
Accessibility is a creative constraint, not cleanup. Drew computes contrast, checks target and reflow requirements, designs focus and reduced-motion behavior, and calls an evidenced failure a blocker. He is equally explicit about what the artifact cannot prove: a screenshot does not establish DOM semantics, focus order, keyboard behavior, or screen-reader labels; those require source code or an interactive build.
Design systems & drift#
Drew is system-minded. He can build a coherent starter from a product thesis, transform or validate tokens for CSS, SCSS, Less, JavaScript, Tailwind, or the W3C format, and spot the drift where one component has been rebuilt three ways. With Figma connected, he reads components, styles, local variables, collections, modes, and aliases instead of inferring a system from pixels.
Design engineering#
When GitHub is connected, Drew can preflight the actual frontend before making a design-to-code call: framework and route, relevant component, styling and token source, existing Storybook story or test, and the smallest safe presentation-layer boundary. He reads the source or pull-request diff rather than reviewing from a title, screenshot, or filename.
His code deliverable is intentionally scoped: exact behavior, token and component changes, a focused UI patch proposal where supported, and observable acceptance checks across states and viewports. He never invents a selector or path, and never claims a patch was applied unless the tool confirms it. Application logic, backend work, broad refactors, reliability, and final code-safety judgment stay with Cody.
Live Figma access#
With Figma connected, Drew reads your files directly, read-only. He orients through pages and frames, inspects exact node properties, renders the frame for visual review, reads reviewer threads, inventories components and styles, pulls local variables and modes, and follows Dev Resources or Code Connect links into the implementation. Pass any figma.com link verbatim; for a visual judgment he reads the exact node and render before opining.
Figma proves design intent, not shipped behavior. Drew says which findings came from the frame, which came from source code, which were calculated, and what remains unknown. If the Figma plan, token scope, or file permissions do not expose variables or Dev Resources, he reports that limitation rather than filling the gap with a guess.
Org sites#
When a design review or audit needs the whole team to weigh in — confirming which screens are done, collecting sign-offs on a component migration — Drew can build the table and hand you an org site card to publish. Teammates confirm or update rows in a browser, every action attributed to their identity, syncing back so your copy stays the source of truth. You click Publish; he can't publish for you.
Where Drew's lane ends#
Drew owns the product surface: experience, interaction architecture, in-product visual identity, systems, interface accessibility, responsive behavior, and frontend presentation. Cody owns general architecture, application logic, backend behavior, reliability, broad production changes, and final code-safety review. Iris owns positioning, campaign copy, and final prose; Drew owns information hierarchy and how language behaves inside the interface. Daphne owns security and compliance interpretation; Drew owns inclusive interaction and the WCAG evidence visible at the product surface. Sage coordinates work that crosses those seams.
Studios & lessons#
Drew can steer you into the right studio with a one-click chip, turn a design audit into an org-wide sign-off page, and learn durable working preferences. Correct him — “always name the tension first”, “cite the frame and selector”, “show reduced-motion behavior” — and he files the lesson so future work changes with you.