Every product above shipped to real people. I was also the one who answered for it afterwards, from where the policy line sat down to what came back through the queue.

This case exists because of arithmetic: five products, Parler, Play, Pay, Shop and Studio, plus the ad platform built on top of them, being built at once, on web, iOS and Android, by a 100+ engineer org, with one design lead setting direction.

The structure was honest about that scale: a design system per platform, on shared brand foundations. Parler, Play, Pay, Shop, Studio and the ad tools each carried its own library; the colour family, the type and the logo system were common stock. I reviewed the work before it shipped, ran the crits, wrote the specs, and drew the risky flows myself, which is how separate libraries kept reading as one product family.

Pay's system, the one rendered on this page, was the most mature of those libraries: full primitives, a semantic layer with Light and Dark modes, a component library and the icon set. It became the reference the other libraries were measured against, and the model for the unification we had underway.

The trade is real. Coherence held in one person rather than a shared file is fast until it isn't: the same decision can get remade twice, and crit is what catches the drift. That is exactly why convergence into a single system was in progress when I left, with this file's architecture as the target.

The base layer is a Primitives collection covering a small ramp for the brand mint, a longer neutral ramp, a handful of system colours, and the spacing and radius scales. These are the real names and values, read out of the working file and rendered here in the system's own numbers. The palette stays small on purpose. Mint is the only colour that appears on anything you tap to move money, so it never competes with decoration.

Primitives are raw values. Nothing in the product points at them directly. Every screen consumes a second collection, Semantic, where each token is an alias with a Light and a Dark value, named for the role it plays rather than its raw colour: bg/surface, for instance, aliases to neutral/white in Light mode. That indirection is what makes the modes work. Flip the mode and the wallet re-themes, because no screen ever hard-coded a colour to begin with.

The tightest decision in the palette is between two colours most people would call the same. Pay's brand is green; in a wallet, green already means a number went up. If one value did both jobs, a gain would read as a button and a button would read as good news, so the mint #59C890 is scoped to brand and action, the signal #31C859 to outcomes, and the token scoping makes the separation structural: feedback/positive can never reach a button fill, and action/primary can never colour a delta. They sit close enough to feel like one family, far enough apart that a glance at a screen tells you which kind of green you are looking at.

The icon library is built the same way as the colour: one source, many expressions. Every glyph carries a Style property (Stroke, Twotone, Duotone, Solid, Bulk) and a Type property (Rounded, Sharp, Standard), so a designer swaps a property rather than hunting for a different file. Every path is bound to system/ink, which is why these recolour with the page you are reading.

Tokens compose into components, so an engineer never guesses. A set of component sets, plus composed pieces like the balance card and the bottom nav, all built from the same primitives. Every fill, stroke, radius and padding in them is bound to a Semantic token, which is what makes the mode switch above possible: nothing in the library holds a colour of its own.

Every case study on this site was built to the same visual language, each on its own library with this file as the bar. The social platform carries the language across feed, Stories, Bursts and the moderation tooling; the wallet is where this system itself ships, and where the scoping rules earn their keep; Play stretches the language across a player, an uploader and live-broadcast tooling; and the ad platform pushes it into dense, data-heavy advertiser screens. If a case study sent you here, this is the standard it was pointing at.

The thing I'd finish first is the convergence. Each platform ran on its own library over shared foundations, and unifying them into one system, on this file's architecture, was still in progress when I left; as long as that stayed unfinished, coherence still depended on my review. The icon library carries a flaw I flagged and still haven't merged: two variant sets, Icon/Token (Alt) and Icon/Brand (Alt), collide, and that Alt naming is a trap for the next designer who searches the library. And elevation was designed for the light surface and merely survives the dark one: at 5–10% black the shadows vanish on neutral/900, so the dark theme leans on borders the system never formally named.

A creator network lives or dies on whether people come back tomorrow. The feed is where that habit is won or lost.

The same screen had to welcome someone's first post and give a working creator room to run a business: short-form video, live audio, stories, messaging, payments, a storefront. Pile it all on and the surface collapses into noise; hide it and creators leave. And because the platform operated under real public scrutiny, every safety decision was part of its reputation. My job was to make the whole thing read as one calm daily habit, with the safety layer designed into the same flows.

I led design across the whole social surface on web, iOS and Android. One designer owned Parler day to day, working from the direction I set, and I sat with the VPs of Engineering daily. A 100+ engineer org was building against the designs, so the deliverable that mattered most was a design system precise enough that dozens of engineers could ship the feed, the creation tools and the safety affordances consistently while I was heads-down in the next surface.

The first version looked like every social app's: email or phone, verify, set up your profile, pick your interest tags. Four steps, each one defensible in review. I designed it.

In use it failed three ways. The step count put a wall between a new user and the feed, the one thing that might convince them to stay. The combined sign-up/log-in screen was worse than long: returning users couldn't tell which mode they were in and created new accounts on top of their old ones, a failure mode that quietly polluted identity across the platform. And the interest tags, the step we imagined powering personalization, got tapped through to get to the app, so the data they produced wasn't worth the screen they cost.

Duplicate-account complaints in the support queue dropped once we split the sign-up and log-in paths. The onboarding sequence came out, and install to feed got shorter. Each step had been fine on its own.

The shipped product keeps the read calm and the tools close.

The feed as home base. One legible stream carries posts, Stories, Bursts and Sovren's live Lounges; creation is always a single tap away.

Lightweight creation. Stories and Bursts cover the in-between moments; the same tools serve a casual poster and a working creator at different intensities.

Safety woven in. Reporting, controls and identity cues live inside the flows people already use: findable the moment something goes wrong, quiet the rest of the time.

Full-screen video is the easiest surface to ruin: every control you add sits on top of someone's work.

The player opens from a tap on any Burst in the feed and takes the whole screen. The HUD ships as one overlay: a legibility gradient pinned to the top and bottom edges so white type holds against any frame while the middle of the video stays untouched; the action rail set low on the right, inside one-handed thumb reach; counts in the mono face so they survive small sizes; and the top tabs persistent, so you always know which lane of the app you're in.

The frame below is the shipped overlay itself: the Figma UI export laid over a real clip, so what you're judging is the actual gradient and rail against live footage.

A creator network is only as strong as the tools that show creators what's working and pay them for it.

Studio, a Sovren product built into the Parler experience, gives creators their balance, payouts and a clear read on performance. I designed it, then prototyped it myself in code with AI, idea to working prototype in days, so engineering started from something they could click. That prototype is on this site, still clickable.

Every safety affordance in these screens had an operation behind it, and I ran that too: the policy calls, the queue, and the signal that came back.

Creation entry points multiplied as surfaces shipped: post, Story, Burst and Lounge each grew its own way in, and by the end the composer deserved a unification we never gave it: one entry that branches by format. And the internal moderation tooling got less design attention than the consumer product; the people working that queue for hours at a stretch got a functional tool when the hours they spend in it justify a considered one.

Everything on this page was built to the same visual language as Pay, Play and the ad tools. The Pay system, the most mature of our per-platform libraries, is documented in the design-system case study.

Money is the most sensitive thing a product can ask people to trust it with. One confusing moment and they never come back.

A non-custodial wallet hands people real control (their keys, settlement that can't be undone) and that control is exactly what makes it frightening. Seed phrases, gas fees, and a 42-character address where one wrong character means the money is gone. Most wallets answer the fear with more warnings and more controls, which only makes the cliff edge feel closer. My job was to design self-custody, sending and settlement for people who had never touched a blockchain, without lying to them about what was happening underneath.

I set design direction across the Sovren ecosystem. One designer owned execution on Parler and Pay under my direction, and I kept the wallet's highest-stakes flows on my own desk: send, receive, confirmation, security and account management. A 100+ engineer org was building screens where a mislabeled button could cost someone real money, so state and edge cases were specced in Pay's design system, the most mature library in the ecosystem.

The first version of the send screen wanted a wallet address and a gas number before it wanted a name.

Send flows asked for wallet addresses, fees showed up as gas, and chain state sat right on the surface. The argument for it was honesty: self-custody is a serious promise, and showing that detail felt like respecting the people who understood it. To a crypto-native eye, those signals read as competence.

This wallet was being built for a social audience, most of whom had never held a crypto key. One wrong character in an address field, and there was no getting the money back. Nobody around them could answer what a gas figure actually meant.

So I changed the direction. You send to a person: a name, a face, a handle, with the dollar value carried alongside the token amount. Security setup, fees and network detail moved behind progressive disclosure, surfaced only when they matter, and the wallet now reads like a familiar finance app.

We kept the blockchain visible. The web app still offers address-level sends and full transaction history for anyone who wants it, and whoever wants the raw detail gets it with one more tap.

Every element on the send screen was a decision, because this is the screen where the money actually moves. Identity comes first (avatar, name, handle) because "am I sending to the right person?" is the question people actually panic over. The amount sits in display type with its dollar value directly beneath and a one-tap flip between denominations. A balance chip with Max means nobody does wallet math by hand. The keypad is the phone's own pattern, because nothing on this screen should require learning.

And when the money moves, the confirmation says so in plain words: what happened, what happens next, one primary action. The full transaction detail stays one tap away for anyone who wants proof.

Pay also shipped as a full web application, and the desktop is where the reversed decision shows its other half. On a phone, the wallet protects your attention: one flow, one question per screen. On the desktop it becomes a workspace (asset dashboard, prices, a persistent send-and-request rail), and the desktop surfaces the detail the phone keeps out of the way: address-level sends, complete transaction history, even hosted node management. The person at this screen asked for the detail, so the design gives it to them.

Both postures are built from the same token and component system. A numeric keypad and a data-dense console, one design language.

Moving value feels ordinary now, and it happens among people you already know.

Send starts from a person, safely. Balance and assets read at a glance, and sending begins with a name or a face on one legible flow, with the cryptography kept out of the way until the moment it earns its place on screen. Account security, confirmation and clear identity cues live inside that same flow, and it was drawn so fiat could sit beside crypto in the same wallet, even though crypto settlement shipped first.

A social layer around the money. Chat, a follower network, profiles and an activity feed mean the wallet is somewhere you already spend time, and a payment often starts as a message.

The send screen still leads with tokens: 15,213.22 OPT in display type, $521.90 in small grey beneath it. For the audience we reversed the whole product toward, I'd flip that default: dollars large, tokens one tap down. Staking kept more crypto vocabulary than it should have; "lock durations" is our language, and I'd redesign that flow around the person's actual questions: what do I earn, when can I get it back. And fiat beside crypto stayed a design model, because settlement shipped crypto-only. The architecture was drawn for it; real use never got to test it, and I'd want that validated before repeating the claim.

The act of making video had been split into pieces, and creators paid the tax every day.

Short-form lived in one app, long-form in another, livestreaming in a third, and the money in a dashboard off to the side. A creator who wanted to post a clip, drop a full video and go live had to manage separate worlds, each with its own rules, exports and analytics. Each handoff lost momentum, quality, or the thread of how anything made money, and it capped how much a creator could produce and earn. The brief I set myself was one path from camera to payout.

The player, the uploader and the live tooling are wildly different surfaces, and a 100+ engineer org was building all three at once. I leaned on Play's own library, held to the same visual language as the rest of the ecosystem, to keep them recognizably one product while the teams moved in parallel.

Play was shaped by a constraint present from the first sketch, and it decided everything downstream.

Live and on-demand video are different systems. We built both: a real-time pipeline that takes RTMP in from OBS, hardware encoders or a phone and delivers it live in seconds (sub-second with LL-HLS) over our own edge network, and an upload pipeline that stores, transcodes to a 4K ladder and serves a library. Two pipelines, with different failure modes, different latencies, different states. The industry's answer to that split is to ship it (a streaming product over here, a video site over there) and let creators carry their audience across the gap by hand.

The constraint I set for the design was that the architecture never gets to appear on screen. That one rule made most of the hard decisions for me. Both pipelines had to end in one player, so watching a replay feels identical to watching it live. Going live and uploading had to start from the same Create action, so the format is the last choice a creator makes, and the lightest. And because every live session is archived with DVR, a broadcast becomes a library video where it stands: no export, no re-upload.

The cost of the rule was real. Most controls in the player, buffering, seeking, error states, had to be designed twice underneath: once against live latency, once against a static file. They were specced precisely enough in the design system that engineers on two separate pipelines shipped what reads as one surface.

A tip is a payment, but it's also a public act: the room sees it land in chat. The sheet is designed around that second fact.

The top of the sheet is a live preview of the chat message the tip will become: your avatar, the "Tipped $1" badge, the message you're attaching. You see exactly what the room will see before any money moves. The amount is a dollar figure with a slider underneath, so generosity is adjustable in one thumb-drag; typing an exact number uses the phone's own keypad, nothing to learn. And the sheet holds two payment routes (a primary on the button, an in-app payment on the quiet line below it) so the impulse to support someone never dies on a payment method.

Tips are priced in dollars, even though creators also earn in tokens elsewhere on the product. The person tipping mid-stream is thinking about the creator, and the sheet is built to keep it that way.

A workflow that used to span three apps now fits inside one product.

Unified creation. Clips, full uploads and live sessions share one creation flow; the format is a choice inside it, and switching between formats needs no exports.

Watching that feeds making. The player, channels and discovery are designed so a viewer is always one step from the Create action: the same person, changing hats on the same screen.

Money in the same room. Tips land in the player, storefronts sit on the profile, and the earnings ledger lives in the product's own navigation, with the self-serve ad platform as a monetization rail beside it.

An honest ledger. The earnings page shows all-time fiat and token earnings, then itemizes every row: the video, the supporter, gross, each fee, net. I put the fee math on every line; a creator deciding whether this platform deserves their work should never have to reverse-engineer their own pay.

Cash out through Pay, with a store on every profile. Payouts settle through the ecosystem's wallet, so the money a video earns arrives next to the money from everything else. A creator's Shop storefront rides on the same profile: the merch shelf under the livestream and the Store tab on the channel are the same inventory.

The tip sheet gets the social half right and then hands you off. "Continue to payment" is a second step at the exact moment someone is feeling generous, and I'd fold the wallet's one-tap confirm directly into the sheet so tipping is a single motion. The whole watch experience is also designed for the stream that's already busy. A new creator's first broadcast, with one viewer and an empty chat rail, gets the same layout as a stream with a full chat rail, and none of the help it actually needs: a prompt, a sense that someone is there, something for that one viewer to do.

Every screen on this page holds the same visual language as the social platform and the wallet. The system discipline behind that coherence has its own case study.

An ecosystem of creator products survives only if something underneath it makes money. That something was ads, and it didn't exist yet.

There was no reference product inside the company to build from. One ad server had to fill the same five placements, priced by an auction our own stack runs in real time. The buyer is an advertiser with no agency behind them, who has to create, target, fund and read a campaign without ever talking to a human. Because the pitch was a platform advertisers could trust with budgets, honesty was a hard requirement I put in the spec: estimates labeled as estimates, spend always legible, no defaults that quietly spend more.

The safe way to scope an ads product is one tool per format, shipped one at a time.

That was the fork at the start. Feed ads carry social mechanics, pre-roll carries video mechanics, the wallet placement has rules of its own. A console per format would have let each ship on its own schedule with its own simple flow, and it's how plenty of ad stacks grow, one bolted-on manager at a time. The cost lands on the advertiser: five placements become five tools to learn and five places to check spend.

I structured it the other way. A campaign is one object (objective, audience, budget, creative) and the placement is a property you set inside the flow. We paid for that call in design and engineering time: the wallet placement, the one with rules unlike any other format, is what came closest to breaking the shared flow, and the component library had to be strong enough to hold it anyway. See how that discipline held up in the design-system case study. What the advertiser gets back is a console learned once, where a new placement arrives as a new option in a flow they already know.

A sponsored post runs in the same feed as everything else; the video unit runs full-bleed with the platform's own overlay grammar; the wallet placement sits inside Pay. So each unit borrows its host surface's layout and type, and wears its disclosure in the unit's own metadata row: Sponsored, set in the same type as the handle, with one clear action per unit. Advertisers are real accounts here too, with profiles and storefronts, which keeps an ad one tap away from a page a person can actually inspect.

The first architecture gave the campaign, the ad set and the ad a screen each.

It looked clean in a flow diagram. Editing a campaign put you on one screen, editing an ad set on another, editing an ad on a third, so changing two things in one sitting meant either starting the flow over or saving progress and coming back. I built it and I would have shipped it. What killed it was a crit that put competitor platforms on the table next to mine: advertisers move up and down the whole hierarchy in one session, and every product they already use lets them. I only caught it because the prototype was clickable and I had put it in front of someone who buys ads for a living.

What replaced it is one session across the whole hierarchy. The campaign tree on the left of the editor is what that decision looks like on screen.

I was directing design across the whole ecosystem through this build, and this was the surface I kept making with my own hands: I wrote the spec, designed the console, then built the prototype in React with Claude Code and Cursor doing the heavy lifting and Figma AI plus media-gen models feeding the creative work. It had real components and real state: flows you could click through and break. Questions that die on a static mock (what a half-built ad set looks like, what blocks publishing, what an empty report says) got answered in the prototype before they became tickets.

Almost nothing this console displays is authored by a designer. The auction sets what each impression costs, so spend, eCPM and CTR are re-derived while you watch. Reach is a moving estimate that shifts with every targeting edit. The creative is whatever an advertiser (or, increasingly, a generative model) hands the system.

So the components are rules for content I'd never see in advance. Numbers carry their state (loading, estimated, settled) so a projection can't be mistaken for a result. Reporting modules keep their shape when data arrives thin or late. Creative slots take any aspect ratio and length, and the preview renders the actual unit per placement, so what an advertiser approves is what runs. This layer of the design is invisible in a screenshot, and it's exactly the layer I prototyped in code to get right.

The campaign editor is where the system's opinions concentrate, so it's the screen worth zooming into. The tree on the left holds the whole campaign (ad sets, ads, drafts) with problems flagged at every level they roll up to, so a broken ad marks its parent from three levels away. Publishing is gated by a validation banner that names the exact ad and the exact missing field, and jumps you straight to it. Targeting leans on saved, reusable audiences, each carrying its reach as a labeled estimate, and exclusions are first-class: keeping existing subscribers out of an acquisition campaign is one selection. On the right, the ad previews re-render as you edit. And every edit saves as it's made, with the footer saying so in plain text, because losing a half-built campaign is how you lose the advertiser.

What I'd change, biggest first.