Move the cursor to magnify · Esc to close
I came in as the lead designer for a team that had no design direction, just a freelance designer working on demand, two business developers, and three engineers. I ended up steering what got built and how. The job was less about producing screens and more about making decisions, keeping a small team aligned, and setting up a design system that other people, and later AI agents, could build from without me in the loop.
I came in as the lead designer. 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.
So my role became less about making screens and more about leading. I set the direction, decided what to build next and how, kept a small team aligned, and made design something the rest of the team could carry 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. Then I organized what came back and ran team workshops to agree on priorities and get everyone pointed the same way.
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 can see it running, so I prototype fast and I don't hold to one method. The right route depends on the problem, and I pick whatever reaches something testable soonest.
Sometimes I start in Figma. I sketch the stacks, build a clickable prototype, then take it into code or another app to feel how it actually behaves, and sometimes I run that the other way around. Other times I start in code. I open Claude, find a direction, carry it into Figma, make my edits there, move to Claude Code, then bring it back into Figma again, and keep looping until the idea holds up.
Which way I go depends on the stage of production. Early on I stay rough and disposable. Closer to release I prototype in the real material, code, so what I am testing is close to what ships. Either way the point is the same: put something concrete in front of the team quickly so the decision rests on what we can see, not on a description of it.
One of the bigger efforts was merging EARN'M and the Rafli app into a single product. A freelance graphic designer handled the visuals under my supervision, working to the direction I set, while I coordinated with the marketing director to pull the right brand styles.
I was learning as I went, so I leaned on AI to help the designer move faster, steer the product direction, and sharpen the micro-interactions. Most of the work here was collaboration and fast decisions, which is what a startup moving at that speed runs on.
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 survived into the live product as a ghost button: "Want to start smaller?" That conversation was as much the job as the screens were.
The parent company asked me to help build a design system for the global brand too. I ran workshops and onboarded developers on how to work with 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.
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.