Move the cursor to magnify · Esc to close
I came in to a team with no design direction: one freelance designer on demand, two business developers, three engineers. I consolidated the scattered design functions into one practice and ended up steering what got built and how. The job was less about producing screens and more about design leadership: setting direction, managing stakeholders across business and engineering, mentoring the people who would carry the work, and building a design culture and a system that the team, and later AI agents, could run without me in the loop.
The team had no design or structural design direction to speak of: just a freelance designer working on demand, two business developers, and three engineers. Design had been handled ad hoc, built on top of old files with no shared visual language and no one owning where it should go. The design functions that existed were scattered across freelancers and engineers, each solving the same problems in their own way.
So my role became less about making screens and more about design leadership. I consolidated those scattered functions into one practice, set the direction, decided what to build next and how, and managed the stakeholders across business and engineering who had a stake in it. This was principal product design in practice: spreading a design culture across the company and updating the processes people worked by, so the team could carry the work without me standing over it.
I started with the old files and moved everything into a proper, replicable design system, so elements could be reused instead of rebuilt every time. I set the direction and the decisions, and with only one freelance designer working on demand, I did plenty of the building myself.
As we went, the system kept moving somewhere better. It began as an organized Figma library, became real working components in Storybook, and finally turned into a Markdown spec that different coding agents could read and build from, with the design system itself reviewed back in Figma.
A design system isn't a component library. It's a set of decisions, written down clearly enough that a teammate or an AI agent can build from them without asking me.
Most of my work was remote. I ran online workshops, collected user data, and led the conversation about what to build next instead of waiting to be handed a spec.
I set up feedback channels inside the product, through input forms and prompts around the UI, and kept collecting signal from the community channels. I ran deep-dive research on what mattered most, organized the findings into documentation the team could work from, and led workshops that aligned everyone, business, marketing, and engineering, on what to build next.
One freelance designer working on demand wasn't enough to keep pace, so I got hands-on myself. I built the designs, ran the rapid prototyping, proposed the direction to the team, and pushed the releases. Eventually I moved onto the frontend too, delivering features to GitHub on the staging branch for the developers to review. In practice I was bridging three roles at once: designer, frontend developer, and project manager. I decided what got built and how, then helped build it.
A recreation of one "What We Build Next" workshop I facilitated: pains collected from users and the team, ranked by dot voting, then turned into a small, owned set of decisions for the next cycle.
A decision gets better once you see the thing running. So I prototype fast and loop between design and code until the idea holds.
I call the method closed because I own every step. No handoff gap. No waiting on a translation from design file to build.
The loop runs both directions. Sometimes I start in Figma: sketch the stacks, build a clickable prototype, then carry the direction into Claude Code to feel how the flow behaves in real material. Sometimes I start in code: open Claude, find a direction, bring the direction into Figma, edit there, move to Claude Code, then back to Figma. I keep looping until the idea holds up.
Which way I start depends on the stage. Early on I stay rough and disposable. Closer to release I prototype in the real material, code, so what I test sits close to what ships. Either way the loop does one job. Put something concrete in front of the team fast, so the decision rests on what we see, not on a description.
I merged the two apps into one product. I set the direction, mapped the flow the merged product needed, and coordinated the visual work against the plan.
The transition stayed smooth. Users moved into a single product without a jarring switch, and the team shipped the merge without stalling the rest of the roadmap.
I was in the meetings where the team decided how to present features, how to onboard users, and which acquisition strategies to try. I came with the results of real work, not just opinions.
The clearest example was pricing. We already had users, and the business wanted to lead with the big credit packs, the $25 and $100 options. My proposal was to keep those as the primary offer and, alongside them, give new users an easier way to get on board, because a high entry price scares off the first purchase before the product has proved its worth. I also argued for pricing by source: depending on where a lead came from, we would apply a different pricing strategy instead of showing everyone the same packs.
A $10 entry option went live as a ghost button under the main packs: "Want to start smaller?" The pricing-by-source idea shipped too. We ran different prices per acquisition channel instead of showing everyone the same packs.
After we split pricing across channels, the smaller entry point pulled more first purchases. Channel mix makes clean attribution hard, so I read the result as directional, not proof. The principle held anyway. Give a first-time user a low-risk way in before the product earns a bigger spend. That work shaped the product as much as the screens did.
The parent company asked me to help build a design system for the global brand too, so the work grew from one product suite into company-wide design. I ran workshops and mentored the developers on how to design with the system, not just consume it.
Then I brought business, marketing, and engineering onto the same UI systems and onboarded them with a Markdown spec so they could build their own prototypes. That changed the whole process. Instead of me writing every feature for the team, they would prototype from the system, I would review it with them, we would get it right together, and then push it to release.
This was the real leadership work, and less about my own output than about raising the design capability of everyone around me. I set the standards, coached people through them, and updated the processes so good design happened by default rather than by my hand. As a principal product designer, my job was to make the design culture something the company owned, not something I carried.
By the time I left, the habits held without me in the room. A small team kept shipping because the decisions already lived in the system, and people across design, engineering, and business could build from it themselves. Scope grew from the product suite to the company-wide brand, not because of hours logged but because the way of working had changed.
That is the outcome I care about as a design leader: not the screens I drew, but a design culture and a set of processes that outlast me. I did the work of a principal product designer, spreading design practice across the company and changing how it built, and the change stuck.