Reality of being a startup designer who ships to production
How I ship and work with engineers
This is Part III of my series where I turn my Friends of Figma Talk into helpful tips for getting started with AI in your design workflow. Check out Part I (thinking is the work) and Part II (how I prompt). This post is about what my workflow looks like as a designer shipping to production regularly.
I’ve never followed a perfect design process. The Double Diamond has always felt like a pipe dream. In reality, as a startup designer, you’re lucky if you get a few hours to diverge on ideas or gather context before you’re expected to have a point of view on a design solution. I’m used to being scrappy and trying different ways of working, which made the transition to using AI in my flow a lot easier.
A team of builders and owners.
Ideas move fast at Chronicle, often going from concept to shipped solution in the same day. We’re a small remote team. No PMs. Just design, engineering, and growth working together.
We value outcomes over tidy design files. I use Figma as a potential starting point, but never the source of truth.
So how we work revolves around who starts, and who finishes.
Who’s judgement or skill in the team will add the most value? What do we need to validate first and what artefact will help us make decisions as a team?
Sometimes that means engineering scaffolds the layout and the underlying structure and I come in after to polish (spacing, hierarchy, states, micro-interactions).
Other times, I’ll prototype something quickly to make a complex interaction feel tangible and engineering will use it as a starting point to get it ‘production-ready’.
We’re not precious about where the first draft lives or who owns what.
Engineer scaffolds, Designer polishes.
As part of our document generation flow, Chronicle AI takes your raw notes and turns them into a rough outline. You can then refine your narrative in a chat interface before generating your deck.
The team quickly built the underlying system, the new infra, and a rough cut of the UI flow. We were preparing for a big launch, and the engineers needed to move onto another project asap.
So instead of giving them a bullet list of all the things that needed polish, I came in and did it myself. I worked on the small interactions and loading states, finessing the padding, ensuring the design system tokens were used correctly.
Designer prototypes, Engineer gets it production ready.
Sometimes a Figma prototype is enough, but other times where complexity of interaction is high, it pays to vibe code it. Elliot, a designer at Chronicle, put together a prototype to communicate the different configurations of dynamic gradients in our product using Claude.
What this gave us was a conversation starter → we could align on the logic, discuss performance issues, and it helped to unlock new ideas. That wouldn’t have felt as tangible or real if it was a static mock.
When the engineer looked at the code, they decided to use the prototype as a base to build on top of. Most of the work was in mapping to our system, and making it work with ProseMirror (the thing what makes content editable on the slide in a deck).
Credit: Elliot Midson
Designer ships feature end to end.
There’s a slippery slope once you get the keys to the codebase.
Rather than prototyping externally using something like Replit or Claude, I started building POCs directly in the codebase. Which then led me to ask the question:
“what if I put out a PR and see what the engineers say/do about it?”
Turns out, you might just get that PR approved and your feature makes it to production!
Just because you’re a designer, don’t expect special treatment.
Learn how the team ship, learn their engineering principles. Learn why tests fail, and how you can fix them. And know that if there’s bugs, it’s your responsibility to fix them.
You’re not going to make friends by asking someone to review a PR with 100s of file changes and no context or tests passing. Cursor helped me split work up into stacked PRs to help with reviews. I created a Skill to write PR summaries and test cases that support our team’s way of working.
I’ve had PRs rejected, I’ve had them heavily commented on, I’ve had engineers pick up where I left and fix decisions that I didn’t realise were bad ones.
Just enough technical fluency
I’ll never be a fully-fledged engineer. Gladly. 😮💨
I’m really bad at math, I only know how to multiply by eights because of the 8-point grid. Using Git or terminal to spin up a backend still gives me a lot of anxiety.
I’m always worried I’m going to break something (and I have).
But shipping means I need enough fluency to make small safe changes without AI, review what the model (or I) just did, and not accidentally set something on fire.
What got me through that initial barrier to entry was the engineers I work with. When I first started shipping to production, the team at Chronicle were my biggest cheerleaders. They showed me the ropes. How to create a PR and how our release process works.
Find the person you can ask your stupid questions to.
Because AI will always tell you you’re absolutely right. And we all know we’re not.
I’ve learned to:
use Plan mode before making big changes → asking for an engineer to put their eyes over it if I’m really worried about it
seek clarity using “Ask” mode so I know what the AI is doing
have a Tailwind reference tab open for knowing which class names to use
ask Cursor to walk me through my first commit or help me create stacked PRs
turn repeatable actions into Skills (PR summaries, commits, fix failing tests)
keep a living doc of terminal commands and local setup I use regularly
AI gave me permission to play in the codebase
It gave me a faster way to articulate my point of view, test it in something real, and ship the thing that matters. As designers, we can now take ownership for the last 10%: the polish, the tiny moments that make software feel considered.
Building is a mindset before it’s a skillset. AI lowers the friction to try, and trying is how you get good. So start small: Pick one piece of the product, make one meaningful improvement, and push it over the line. I’ll be your cheerleader! You can do it!
x Claire
This is Part III of turning my Friends of Figma talk into a series of tips and techniques to help others on their journey of building and designing with AI.
Read the other parts here:
Thank you! This gave so much confidence to not get intimidated by technical stuff and get started
thankss for sharing!!!!
my way of working nowadays is really similar, except for the part about jumping into the code and publishing my own builds) but the way you collaborate with devs/engineers is pretty much the same as mine.
however, I can't help but feel like I'm constantly moving from one design refinement/polishing task to the next with very little time to step back and question whether what we're building is actually useful for users. Of course we test things and iterate on them afterwards (or trash them if needed) but I have this feeling that because everything is possible, everything should be shipped and tested later, and this *new* way of working sometimes leaves me feeling a bit empty and disconnected from the purpose behind what I'm doing.
is that happening to you as well? and if so, is there anything you're doing to address what I'm describing?