The question I kept coming back to: what would it look like if the same knowledge that informs a senior design review — heuristics, accessibility standards, your actual design system — was available on demand, directly in the canvas, before anything went to engineering?
SYNTHIA runs five evaluation lenses: your actual design tokens and component library, WCAG accessibility checks, Nielsen's ten usability heuristics, a taxonomy of 26 UI traps and dark patterns, and synthetic users — personas built from real UXR behavioral data. A knowledge worker and a student reading your design, first-person, reacting to what they see. That last one tends to be the most interesting.
Two agentic modes, both grounded in the same idea: only automate what doesn't require judgment. Mechanical issues — wrong token, contrast fail, font size below threshold — get fixed directly in the document. One click per finding, or batch the whole lot. Judgment calls — heuristic violations, dark patterns, persona reactions — get posted as comments pinned to the exact node in the canvas. You shouldn't auto-fix what a human needs to review.
The Figma plugin is the primary surface, but the same evaluation engine also ships as a Claude skill for AI-native workflows and a Go agent for document contexts. Consistent command design across all three — one engine, wherever you're working.
Won "Most Innovative" at Superhuman's global hackathon — 200+ entries. Published to the org plugin library. First designer to demo a coded prototype org-wide.
The vision was a consistent evaluation layer across the entire product lifecycle — the same quality bar whether you're writing a spec, designing in Figma, reviewing code, or shipping to production. The Figma plugin was the proof of concept. The engine was always meant to go further.
Right after the Coda acquisition, the identity team had one job: build id.superhuman.com — a single auth surface for all sign-in and sign-up traffic across Grammarly, Coda, and Superhuman Mail. We started before the brand existed.
Before drawing anything I mapped how other multi-product platforms handle this — Disney, Microsoft, Meta, Atlassian. Disney was the clearest influence: one email field that routes to the right place, white-labeled across brands. Atlassian was the closest structural model — same auth UI, branding switch per product.
Grammarly had two separate modals that couldn't tell if you were new or returning. The goal was simpler: type your email once, the system figures out where you go.
The architecture we landed on was hub-and-spoke — id.superhuman.com routes and serves each product brand, but brands can't talk to each other. I pushed for something more integrated; most traffic was going to Grammarly and a direct Grammarly-to-Coda path seemed more natural than sending someone back up to the parent. Hub-and-spoke was the right call for where engineering was at the time.
The only brand signal I had when I started was "it'll be purple." So the first visual direction came from the product itself — multi-turn interactions, chip-style controls, nothing stacked. Not standard sign-in UI. More like how Superhuman naturally behaves. I imagined those chip patterns eventually contributing back to the design system.
I built a clickable prototype with developer controls, test accounts, and milestone staging across four brand contexts: Genesis (the internal codename), Grammarly, Coda, and Superhuman Mail. Any email from any existing user database routed correctly. That prototype was the artifact that got engineering aligned.
As the brand got closer, the constraint became clear: don't disrupt the Grammarly funnel. We pulled back from the pure identifier-first model — separate sign-in and sign-up flows, brought closer together. I worked with Orr — who was connecting auth into the full Superhuman.com experience — to consolidate every exploration into a single shared view. That work became the foundation for the CUJ (Critical User Journeys) playbook — a framework I built to map sign-up and sign-in quality across all products and brands. The org adopted it as the standard for measuring experience quality across the platform.
The last piece was active session transfer. Old model: enter a Grammarly email, get sent to Grammarly to auth, come back to Superhuman. New model: detect the existing session on entry, transfer it, sign the user in directly. Recognized account — one tap. Returning session — auto-redirect, no UI at all.
Launched October 2025. Engineering source of truth from first sketch through launch — every state mapped, every error path defined.
Grammarly had a design system — it just lived entirely in code. The Lemma Design System was a robust set of tokens and components deeply integrated into SDUI, Grammarly's server-driven UI platform that delivered a consistent experience across browser extensions and its emerging desktop surfaces. It worked. But as Grammarly expanded to new platforms, the design decisions were entangled in SDUI in ways that made change expensive. The design org was small when we started — closer to ten people — but growing fast, and there was no Figma library, no documentation, no shared way to access or reason about what was already built.
Mark and I were brought in by Florian — the sole designer on the systems team at the time — to help scale it. We wanted to redesign things. Florian wanted to redesign things. But the risk of breaking changes in a system this tightly coupled was real. So we made a different call: put the creative ambitions aside and build the infrastructure around what already worked. Figma components that mapped to what was in code. Token naming conventions. Documentation. A way for designers and engineers to access the system without depending on the systems team for every decision. The system was already load-bearing, tightly coupled to SDUI, and breaking changes carried real risk. We chose infrastructure over redesign — the right call when the foundation is already working and the org needs to scale around it.
The approach was to build on what already had traction, not replace it. Foundations first. The color palette was consolidated — before, every product had accumulated its own sprawl of shades with no naming convention or hierarchy.
Before and after — palette consolidation from product sprawl to a structured core
Above the core palette: a semantic layer. Colors named by role, not value — Surface, Content, Boundaries — each mapped to a four-part token convention: Mode / Context / Role / Variant. Future-proofed for rebrands by design.
Token naming convention — Light / Interface / Interactive Branded / Primary
Semantic palette — Base context mapped to Surface, Content, and Boundaries roles
Spacing and radius scales followed the same logic — named tokens, consistent steps, documented usage rules.
Spacing scale — visual and named tokens from 1px to 80px
The Figma component library was restructured from the ground up — layer trees flattened, everything renamed for findability. Before: components buried under category group names that matched no one's mental model. After: flat, alphabetical, searchable.
Improved discoverability — flat naming over nested category groups
Accessibility was baked in. Color contrast was updated across the component set — buttons, banners, form controls — and documented so engineering could implement with confidence.
Color contrast updates — before and after across buttons, notification chips, and inputs
Variant matrices mapped 1:1 to what was in code. The docs site had standardized templates so contributors could add pages without involving the systems team.
Documentation alongside components — usage guidelines, principles, and Figma variants in sync
Governance mattered as much as the components. Formal contribution process, review criteria, and design standards. Friends of GDS embedded champions across product teams — designers who could answer questions locally and reduce dependence on the systems team for every decision.
Release roadshow — org-wide launch presentation for GDS v1
Adopted across the org. Fragmentation reduced. The system survived the Superhuman acquisition and a full brand overhaul — the token names held. That was the real test.
After shipping GDS v1, the next expansion was suggestion cards — Grammarly's most complex and most-seen component, grown independently across surfaces with no shared model. The work started with a knowledge-share session: which clients use which cards, what the differences were, and what the SDUI-to-SCA architecture transition meant for the component going forward.
Discovery — which clients use which cards, and the architecture context
From there, an inventory: every existing card state documented across surfaces — extension popover, desktop popover (two trigger modes), multi-suggestion variant, native editor sidebar, Google Docs sidebar. The same suggestion data, rendered differently depending on where you were.
Inventory — every existing card state across surfaces
With the inventory done, we modeled the structural architecture. Four container types — contextual single-suggestion popover, fixed single-suggestion popover, multi-suggestion popover, multi-suggestion sidebar — each broken into layered sub-components: Nav Bar, Card (Header, Content, Action Bar), Footer. Visualized as both a flat diagram and an exploded layer stack.
Schematics — four container types, exploded layer architecture
The proposed direction: one unified design for all four delivery types, using the same component model and sub-component structure adapted to each context.
Proposed direction — unified design across all delivery types
The goal was to set a clear direction and break each delivery surface down into its generic sub-components — Nav Bar, Card, Action Bar, Header, Footer — so they could be documented into GDS and reused across the product. I left the team with the plan and the schematics and went on paternity leave. When I came back, I moved into a product design role on the Trust team — a lateral move to fill a business need — and stayed close to GDS as a contributor, eventually being featured in the Token Times for contributing the Verification Code component.
Token Times — featured for contributing the Verification Code component
As Grammarly moved upmarket and started shipping generative AI features fast, privacy went from being a legal checkbox to being a real product problem. Consent flows were inconsistent across teams. Settings were scattered and buried. Enterprise customers needed data sovereignty. And every new AI feature meant explaining to users what was being collected and why — in a way they'd actually trust.
The question wasn't how to add consent UI. It was how to make privacy a platform that the whole org could build on.
A framework I developed with the Trust team — four principles that governed every privacy surface we shipped: transparency, intuitive controls, honored consent, and the right to be forgotten. CDTC, CMP, and Privacy Hub all operate under it.
People hear "AI training toggle" and picture a switch. This one took weeks to design — not the UI, the logic. Before a single pixel moved, I was in rooms with the PM, the privacy engineer, and the backend engineer working out the decision matrix: who sees a control at all, when is it editable, what does "locked" mean for a managed user versus an EU user, and what happens when someone moves between account types and their previous state needs to be restored.
The most important design decision wasn't a UI decision. It was a product stance: we will not train on EU or UK user data, full stop. No toggle. No opt-in. GDPR meant the answer was baked in, and the right interface for that wasn't a switch — it was an explanation. EU users see a message where the control would be, not a control they can't use.
State matrix — who sees a control, who doesn't, and what happens when account context changes
The managed client case was the other hard one. Enterprise admins set the training policy for their org — their users have no control. But there are two locked states: locked and active (admin enabled training) and locked and deactivated (admin disabled it). Each communicates both the current status and the reason. A user shouldn't see a disabled switch and wonder if something is broken. They should know their org made the call.
Editable states — user has control
Locked states — admin controls the setting, user sees attribution
Won't Train — no toggle for EU/UK users. Grammarly doesn't train on that data. The UI reflects the stance.
Five states total. Each one communicating status, reason, and the right level of agency for that user's context. Launched June 20, 2024 — the same day Grammarly emailed 70 million users about the privacy policy update.
A plug-in framework for product teams. Give us a feature name, a data list, and a usage explanation. We render the consent modal, the opt-out flow, the in-product invitation, the admin controls — same trust pillars and data language every time. It survived a major pivot (tone personalization → AI training controls) and extended from individual users all the way to org admins.
The content strategy behind the modal was its own design problem.
Not picked by accident. Before settling on a term, I audited how 17 competitors named their data consent features. Most default to "personalization" — safe, familiar, but vague. We wanted something that was relational to the user and honest about what the feature actually does. "Tailored" landed in the right quadrant: candid about data, but framed around value — not compliance. Grammarly learns your specific writing style, not just aggregate preferences. The word earns that.
Competitive landscape — most companies use "personalization." We wanted to be relational to the user and invitingly value-forward. "Tailored" hit both.
We validated "tailored" through user research, including with ESL audiences. It tested as understandable, descriptive, and compelling — users intuitively connected it to something made specifically for them.
User quote from research — the tailor analogy surfaced unprompted across multiple participants.
The headline is a question: "Want Grammarly to be tailored to you?" Not a statement, not a pitch. Framing it as a question was deliberate — we didn't want to nudge users toward consent. We also rejected "tailored assistance" as the headline: too clinical, sounds like a feature name rather than a benefit. The Yes/No options sit directly below it, aligned — no visual hierarchy pushing toward one answer.
The body text was word-by-word. "Grammarly will collect and store some information about your writing" — transparent about what we take, nothing buried. "Understand what you're working on" — plain language for context collection, no jargon like "natural language processing." "Learn your style" — personalization framed as individual, not algorithmic.
Body text annotated — three phrases, each carrying specific trust and transparency intent.
People make an experience-convenience tradeoff when they see a consent screen. We designed for that: lead with the feature benefit, make the data implications explicit, give people the detail they want without forcing it on them. The accordions carry the depth — most users won't open them, but the act of making them available is part of the trust signal. No jargon anywhere. Tested extensively, including with ESL audiences.
Every element annotated — proactive concern addressing, accordion depth for those who want it, explicit data implications, Privacy Policy link for those who need it.
Bring Your Own Key lets enterprise customers encrypt their Grammarly data with keys they control in their own AWS account. Grammarly never touches the key. The design challenge wasn't the cryptography — it was making a feature built for security teams legible to the IT or legal buyer who evaluates it, without dumbing it down for the engineer who sets it up.
The MVP shipped BYOK as a status display only. Active or Inactive. To change it, contact your customer success manager. No self-serve, no controls. That was intentional — BYOK needed to exist in the admin panel before it could influence procurement decisions. Enterprise IT teams evaluate features before they buy. If it doesn't show up, it doesn't count.
Q2 MVP — BYOK as a read-only status. Active or Inactive. To change it, contact your CSM.
Before you can ask someone to replace their encryption key, you have to make the current one visible. Q3 introduced the Grammarly-managed key as a named entity — surfacing the key ID, the last-updated date, and a clear path to BYOK. Encryption went from invisible infrastructure to something admins could actually see and reason about.
Q3 — Named the Grammarly-managed key, surfaced the key ID, added a path to BYOK. Made the default state legible before asking anyone to change it.
The self-serve flow started with an early concept I brought to drive alignment — a file-upload model to get the team's eyes on the experience before we locked scope. That design did its job: it quickly surfaced the real constraint — BYOK users need to provision a key in AWS KMS first, before handing anything to Grammarly. The concept got us to that discovery early. What shipped was a Key ARN entry form with a persistent link to the implementation guide.
Early concept used to drive the alignment conversation. The upload model surfaced the provisioning question before it became a build problem.
The entry point shows the Grammarly-managed key active, with a "Set up BYOK now" CTA. Before asking for any credentials, an explainer walks through how the process works and keeps the Grammarly-managed key active as a safety net until setup completes — no gap in data protection during the transition.
Explainer before the form — how it works, what you'll need, where to get it. Then: Key ARN, optional CloudWatch logs, IAM Role, Log Group.
Cancel guard — if you exit mid-setup, your Grammarly-managed key stays active. No ambiguity about what's protecting your data.
These explorations pushed toward full transparency once BYOK was running — key details, IAM role, log group, an in-progress encryption status, a per-feature manifest. The assumption was that the key would change states and users would need to track it. That assumption didn't hold up. The key doesn't change states — so surfacing all that status was over-engineered. The team moved away from it on feasibility grounds.
Active state explorations — cut on feasibility. The key doesn't change states, so the status layer wasn't needed.
A concept that didn't ship. The existing privacy controls were organized around features — toggles scattered across settings, each owned by the team that shipped the feature. If you wanted to understand what Grammarly knew about you, there was no single place to look. The question we started with: what would it look like to organize privacy around data instead of features?
Before designing anything, I mapped how competitors handle data transparency — entry points, report request flows, download mechanics, deletion. The pattern: most companies bolt a "Download my data" link onto their settings page and call it done. The user flow is long, often opaque, and disconnected from the controls that actually matter.
Competitor review — mapping the data download flow across major products. Most treat it as a legal checkbox, not a product surface.
The reframe: make data the first-class entity. Not "turn off Writing Suggestions" — but "here's what's collected about your writing, here's what it's used for, here's how to limit or delete it." Features become downstream of data. Turn off a data category and the features that depend on it respond. That organizational logic changes what a privacy setting even means.
Home — organized by data category, not by feature. Each entry shows what's collected and what controls you have.
Data category detail and activity journal — "right to be forgotten" as a real product surface, not a legal footnote.
CDTC launched June 20, 2024 — the same day Grammarly emailed 70 million users about the privacy policy update. A few months later, a random LinkedIn post about Grammarly's data practices surfaced in the comments with a screenshot of exactly the EU state we'd designed: "Since you created your account in the EU or UK, Grammarly will not use your content to train its models." The reply: "Ah, brilliant." The design was working in the wild, legible to people who weren't looking for it.
The CMP framework scaled across product teams without needing design on every feature. Privacy became a first-class surface — its own nav item, not a buried subsection. BYOK opened enterprise procurement conversations that wouldn't have happened otherwise.
Three brands, same product. Grubhub, Seamless, and Eat24 shared most of their UI but had no shared system. Components were duplicated, patterns drifted, every team solving the same problems independently. The first step: centralize into a living style guide that could serve all three brands without losing their identity.
Grubhub didn't have a systems-first design culture when we started. Cookbook helped create one. Over time the system became a driver of product and design strategy — not just a repository of decisions that had already been made elsewhere.
The system hierarchy came from interviews — how designers and engineers actually started features, where they got stuck, what information they wished they had. Those conversations shaped every structural decision.
Interview guide — mapping how teams build features and where they get stuck
Development plan — roadmap for building and documenting the living style guide
Cookbook covered every layer of the stack. Style foundations: typography, semantic and perceptual color (light and dark), shape, dimension, line, icons, sound. Layout: device breakpoints, units and measurements, grid, spacing, page templates. Accessibility guides. 45+ cross-platform components.
Type scale — phone, tablet, and stand contexts, each with distinct size, line-height, and letter-spacing specs
Spacing system — scale and usage rules across all platforms
Above the component layer: Strategies — six higher-order docs covering how components work together in real product scenarios. Navigation, Search Navigation, Sheets vs. Dialogs, Forms, Connectivity & Outages, Delight. Not just what to use — when and why.
Delight strategy — conceptual frameworks from social science and product management applied to product design
Dynamic Type — accessibility guide for adapting type across iOS and Android size categories
Contribution had a formal five-stage process — Intro, Discover, Suggest, Support, Document — so any team could add patterns without bypassing quality standards or bottlenecking the systems team. We negotiated a 15% engineering tech debt budget with leadership to fund cross-platform delivery. Governance designed in, not bolted on.
At 50+ designers, a system needs more than good components — it needs education. I structured onboarding around the questions people actually ask: what problem does this solve, what is it, how do I use it.
The case for a design system — the team scale inflection point where shared systems become critical
Getting started — three entry points: Figma libraries, component docs, and the Cookbook Figma project
Impact tracked through quarterly surveys — designer-to-engineer communication, documentation quality, development velocity. Scores improved every quarter.
"The pattern library helps me communicate with the development team" — survey scores, quarter over quarter
Two years in: 39 cross-platform patterns, a full year of engineering time saved, conversion goals exceeded. Experiments informed by Cookbook standards drove +5,260 DAGs and +$57.6M in annual restaurant revenue.
Two-year scorecard — patterns, time savings, and conversion goals
Experiments informed by Cookbook standards contributed +5,260 daily active guests (DAGs) and +$57.6M in annual restaurant revenue — the largest experiment wins in Grubhub's history at the time.
The longer-lasting influence was the people. Every designer who worked on Cookbook went on to lead design systems at other companies — Spotify, Pinterest, Nike, Zendesk, and others. That's the kind of influence that doesn't show up in a component count.
Project Sunburst expanded Cookbook from the consumer app into the full three-sided marketplace — Diner, Restaurant, and Driver. The driver app lives in a car. The restaurant app lives in a busy kitchen. The system adapted: typography scales and control sizes tuned to each environment.
Three-sided marketplace — Diner, Restaurant, and Driver, each with their own product context
Environmental adaptation — type scales and control sizes adjusted for where the product is actually used
Product sub-libraries — Diner, Restaurant, Care, Driver — extended Core with app-level components. Not just overrides: a reorder card in the Diner library knew about ratings, ETAs, and delivery fees. The same structure in Care knew about case status and support context. Core components wired to real product data.
Web, iOS, and Android — all consistent. iOS and Android each had Storybook-style component libraries so engineering could test states and validate changes without opening Figma.
Diner reorder cards — two variants with documented guidance on when to use each
Active order footer — persistent order status, follows the diner through the app
Care data capture — Core input components wired to customer service context
DoorDash and Uber Eats were pulling ahead — not just visually, but structurally. Grubhub's apps were organized around how the product worked, not how people order food. Navigation cluttered with tabs that didn't earn their place. Pickup buried. Reorder buried. Every action a full-page navigation push. The head of product made the call: two designers, shape the redesign. I'd never heard that mandate before.
The systems team — designers who'd been at Grubhub long enough to know the product inside and out — spent two months working out the architectural direction. Full IA, full schematics, every pattern decided before anyone else touched it. Then we handed it to the team.
The existing bottom nav had four permanent tabs: Restaurants, My Grubhub, Perks, Bag. The bag tab showed up even when it was empty. My Grubhub was an unfocused dump. New diners and returning diners landed in the same generic restaurant list with no personalization.
We collapsed it to Home, Perks, Orders, Account. The bag tab gone — replaced by a persistent order footer that follows the diner across the app, only appearing once a cart exists. Every tab had to earn its place. Home became a personalized landing: pickup and delivery exposed directly at the top, reorder favorites surfaced as one-tap cards — no longer buried in a separate tab or behind the address field.
Baseline vs. Sunburst — old Restaurants tab and unfocused nav replaced with a personalized Home and intent-based navigation
No sheet system in the baseline — every action pushed to a full new page. We designed a layered sheet system: filters, sorts, and the menu all slide up from the bottom. Fast, one-handed, interruptible. I prototyped the transitions in Principle before anything hit engineering.
Sorts and filters got rationalized at the same time. Six sort options that mattered — relevant, price, rating, distance, ETA, delivery fee. Deprecated the ones that didn't pull their weight: restaurant name sort, delivery minimum, rapid pickup filter, pickup distance slider. The filter panel simplified accordingly.
Sheet architecture — sort as a layered bottom sheet; persistent order footer replaces the Bag tab
In the baseline, reorder lived in the My Grubhub tab — a separate destination with extra steps between you and whatever you had last week. We moved favorites to one-tap cards on the Home screen. No tab switch, no decisions, one tap.
Baseline vs. Sunburst — reorder moved from a buried tab with extra decisions to one-tap favorites on Home
One design principle: Purposeful. Strip noise — fewer greys, tighter interactive color, better contrast. The menu went from a full-page push to a sheet that slides up from the bottom, covering the nav tabs. Same UX underneath, radically different feel.
Menu before and after — updated palette and typography, now presenting as a sheet that covers the bottom tabs
Before the wider launch, we stitched the full end-to-end flow and produced a sizzle reel with the help of a motion designer we called Sizzle. The CEO and founder of Grubhub saw it. It landed.
Rollout was phased — 5% smoke test scaling to 50% — with conversion, reorder rate, and launch time tracked at each gate. Grubhub was an experimentation company, but you can't A/B test a brand new experience the same way you gate a button color. The organizational trust to ship it was a metric in itself.
Navigation, search, filtering, and reskinned light and dark modes all shipped. The patterns ran in the driver app, restaurant app, and web. The most impactful experience push in Grubhub's history at that point — presented to the C-suite, extended across every major surface.
