Bobby is a product and systems designer based in New York. 14 years between Grubhub, Grammarly, and Superhuman.
Background
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?
What it does
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.
Outcomes
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.
What's next
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.
Background
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.
Research + architecture
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.

Design
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.
Outcomes
Launched October 2025. Engineering source of truth from first sketch through launch — every state mapped, every error path defined.
Background
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.
Foundations
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.


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.


Spacing and radius scales followed the same logic — named tokens, consistent steps, documented usage rules.


Components
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.

Accessibility was baked in. Color contrast was updated across the component set — buttons, banners, form controls — and documented so engineering could implement with confidence.

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.

Community + adoption
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.

Outcomes
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.
Card systematization
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.

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.

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.

The proposed direction: one unified design for all four delivery types, using the same component model and sub-component structure adapted to each context.

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.

The problem
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.

CDTC — AI Training Control
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.

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.





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.
CMP
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.
The word "tailored"
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.

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.

Every phrase chosen
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.

The consent moment
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.

BYOK — three quarters, one arc
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.
Q2 — Read-only
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.


Q3 — Make encryption legible
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.


Q4 — Self-serve
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.


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.



The active state
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.


Privacy Hub
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.

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.



Outcomes
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.
Background
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.
Foundation
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.


What it contained
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.


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.


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.
Adoption
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.


Impact tracked through quarterly surveys — designer-to-engineer communication, documentation quality, development velocity. Scores improved every quarter.

Outcomes
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.

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.
Scale
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.


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.



Background
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 room
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.
Navigation
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.


Sheet architecture
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.


Reorder
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.


Menu + visual language
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.


The rollout
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.
Outcomes
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.