That's Benji's line, not mine. But it's the closest thing I have to a working philosophy after a decade of designing products. So this page isn't a résumé. It's a working sample of how I think — written for one role, at one company, reporting to one person whose work I've studied closely enough to know the bar is taste, not best practices.
"We need to stop talking about product design in absolutes. There are no rules. Everything is made up. Do what makes sense and feels right."
Most "why this company" answers are marketing pasted onto a cover letter. I'm not going to do that. Here's the actual reasoning:
Everywhere else hiring "AI designers" means "design a chatbot tab." xAI is one of a handful of places where the model and the surface co-evolve. The design job moves closer to system design and further from screen design. That's the work I want to be doing for the next ten years — and it doesn't really exist outside of three or four buildings on Earth.
The timeline is the largest real-time human-reaction surface that exists. The question of "what does AI do for that surface" is one of the most interesting design questions of this decade. I've already written a full case study on it without being asked. That's the level of intrinsic motivation you should expect.
Most product orgs split these. xAI doesn't. The visible cadence suggests a team where the IC who has the strongest argument wins, fast — not the IC who's most senior. That's the only environment where my work compounds. I'm useless in places that route every decision through three layers of review.
I'm not endorsing every public statement from leadership. I'm aligning with the pace, the willingness to ship novel surfaces, the seriousness of the AI bet, and the design bar Benji is setting. Those are the things a designer actually joins a company to defend.
Benji Taylor joined X as design lead in March 2026. Before X, he led design at Family (the crypto wallet widely cited as the best-UX wallet on the market, acquired by Aave) and at Base, Coinbase's L2. I've spent time with his public work and his personal site — both the visible aesthetic and the writing about it.
The bar he's set, from what's publicly visible, reads to me as:
Black on white (or white on black). One blue for utility. No second color. Restraint that earns its presence by being load-bearing, not decorative. This case study refuses Grok-as-purple-shimmer for the same reason.
Headlines that read as statements. Body that disappears into the eye. Generous whitespace doing the work that borders, dividers, or color usually do. The visual board follows the same convention end-to-end.
His public statement: "Highly polished products." That polish comes from cutting, not adding. The "lol/gm" empty-state frame in the case study is a direct expression of the same value — the affordance that knows when not to render.
From his post on joining X, what he highlighted was the chance to work at scale while focusing on craft, speed, usability, and real impact. That sequence matches how I work. Argue the thesis fast, ship the smallest version that proves it, then defend the craft in writing through every review.
I'm not claiming to speak for the design org's internal direction — that's a week-one conversation. But the public signal is consistent enough that I built the entire case study to that bar on purpose. If the bar is somewhere else, the case study still demonstrates I can hold a line; I'd happily redirect to where the team is actually pointed.
I'm not going to list "Figma, Framer, prototyping" — assume those. Here's what's actually load-bearing on day one:
The first thing in my spec doc is the bet. Screens come after. I won't open Figma until the argument is sharp enough to defend, because the wrong-argument pixels just get rebuilt.
X is monochrome. The temptation to give Grok purple, shimmer, gradient — every competing AI product does it. I refused all three in the case study, on purpose, and wrote the rationale in the spec. The principle "monochrome is the brand position" is the kind of constraint I defend.
Hallucination reporting, confidence indicators, source chips, latency budgets, consent flows. The case study's edge-case section exists because the trust loop is the IC's responsibility — not "we'll figure it out in iteration."
An IC's job is partly to know what doesn't get made. In the process doc I list the directions I killed — no Grok onboarding flow, no Grok personality in the timeline, no settings page that hides features. The list of refusals is the cleaner half of the work.
Most design proposals die in the meeting room because they can't withstand a 20-minute argument with engineering or PM. I write specs that survive — risks named out loud, metrics and counter-metrics specified, rollout gates defined. The deck is for the win room. The doc is for the war room.
Based on the public posting and what's observable from Grok and X today, here's what I'd push for in the first three months if hired. This isn't a take-it-or-leave-it plan — it's evidence that I've already done the thinking.
| Weeks 1–2 | Listen and instrument. Sit with eng on the model team and the X timeline team. Pull current Grok session telemetry — dismiss rate, hallucination report rate, latency p50/p99 — and write down the actual numbers, not the assumed ones. |
|---|---|
| Weeks 3–6 | Ship Insertion 1: Inline Ask-Grok. Smallest unit that proves the layer-not-tab thesis. Forces resolution on the latency budget, the anchoring pattern, and the source-chip language. Behind a 0.5% flag on Premium+. |
| Weeks 7–10 | Ship Insertions 3 + 4 in parallel: Claim-Context and Compose Co-Writer. Different surfaces, no shared dependencies. Co-Writer is the conversion lever for daily post-creation; Context is the trust mechanism that defends Grok's first-pass reputation. |
| Weeks 11–13 | Write the design-system extension for Grok-in-product surfaces. One mark, one inner-border treatment, one source chip — the whole language. Defended in writing so the next five designers don't reach for purple. |
| Counter-week | What I'd refuse to ship in 90 days: a Grok sidebar in the timeline, a verdict-rendering fact-check feature, a settings page that's anything but a single-tap dismiss. Those would all be available capabilities from leadership pressure — and the IC's job is to make the case against them with evidence. |
If any of this is wrong about the current state of the product, that's fine — that's what week 1 is for. The point isn't that I've nailed the priorities from the outside. It's that I've already thought about what an IC designer ships, in what order, with what defensible reasons — which is the thing the job actually asks for.
An IC's claims need calibration data. These are rough numbers about how I work — meant to help you decide if my pace and depth match what xAI needs.
Hire me and you get a designer who treats the spec doc and the visual board as the same artifact. Who argues against shipped features when the rationale is weak — and also ships the version leadership decides on, fast, without sulking. Who holds the brand line until eng is mildly annoyed, then explains why in writing.
What you don't get: someone who needs the brief sharpened before they start. Someone who agrees with everyone in the room. Someone who confuses motion for progress. Someone who quotes "best practices" instead of trusting their taste.
I made this case study, this prototype, this site, this about page, and the 90-day plan before being asked. That's day-one initiative. It's also day-365 initiative. The bar doesn't move.
There are no rules. Everything is made up. I'd like to keep doing what makes sense and feels right — under your roof.
If anything here is interesting, the fastest next step is a 30-minute call. I'll come with a sharper version of the case study based on whatever the team is actually working on now — and questions about the product roadmap that I can't answer from outside.