I’m a designer and today I shipped code to prod

I am a designer. I don’t write code. But last week I went through the full process to ship code, the same process the mobile developers on my team go through every time they ship code. It taught me something I wasn’t expecting, not about code but about the design process.

First, the setup was no joke

Let me be upfront: getting to the point where I could even touch a line of code took real effort. The developers on my team were incredibly helpful, but there was a lot to install, configure, and understand before I could ask Claude code to do what I wanted.

If you’re a designer or product person thinking about learning to “ship code to prod”, go in with realistic expectations. You’re not learning how to use a new vibe code deploy tool, you’re learning an entire engineering process full of new software and vocabulary.

So what did I code?

I updated how chips in a multi-select field display. It wasn’t glamorous or high impact. I chose this ticket because the scope was very small and it was a UI update to an existing component.

Once I was in my new branch, I put Claude code in plan mode so I could write out what I wanted to do and then review the changes before Claude coded anything.

Side quest about a problem I ran into

Claude did what I asked and had the chips wrap but then we hit a snag. Once the chips were displaying in rows, there was way too much vertical space between rows, like 3 times the height of each chip. I had a suspicion that the reason was because when the component was designed, the team wanted to make sure all buttons had a large tappable area so they applied padding on top and bottom. Was this how the component was coded though? Since I didn’t know for sure, I simply asked Claude to reduce the vertical spacing to be 8px between rows. Claude started thinking but quickly began going on and on with “Let me see about this” “Wait I think I figured it out” “Oh now I understand” “Looking at this another way”. I had to stop Claude and update my prompt to include the context I had about the chips themselves probably having extra padding. Sure enough Claude came back with “you have a minimum tap size, are you sure you want to remove this padding?” Yes I did.

Why? I decided that the better experience would be to use a bigger button, but for now I’ll keep the size of the chips the same because 1. There’s a second way to remove the chip, and that’s by tapping the checkbox icon (or really the entire row) in the select sheet. 2. We can easily update the chip size to the medium or large variant if we get feedback that it’s hard to tap on the X to remove the chips.

Another side quest about scope creep

The ticket originally was only about the display state of the multi-select field, not the multi-select sheet. But I noticed when testing that when you’re selecting items in the sheet, the selected chips that display at the top of the sheet are styled differently than the chips you see once you save and close the sheet. They should be the same. So I chose to update the display of the chips so they match. The corners needed to be fully rounded instead of only 4px rounded and filled instead of outlined. But then the fill color wasn’t dark enough because in the sheet the chips are on top of a gray background and in the display state they’re on white. So I had to tweak the color of the chips on the gray background to be slightly darker. I used a color from our library, but did I just override the gray chip’s color, is that best practice? Should we update the gray color of the gray chip variant to be darker so that it works on both gray and white backgrounds? or should we update the sheet to not have a gray background?

All these questions while I’m also thinking, “Last week I created a ticket that includes updating this multi-select sheet’s gray area so that it always displays so that the UI doesn’t “jump” when the user begins making selections. Should I make those changes now? No, that’s a separate ticket. Then why did I update the style of the chips here? Should that have been kept separate too? Ahhh Scope creep is crazy! Now I’m starting to understand how developers feel!” I didn’t end up answering these questions. I simply stopped there and moved on to creating a PR.

Pushing to production

Once the UI in my simulator looked correct, I met with a developer who showed me step by step how to commit my branch and create a PR. I filled out a templated form in github that the developers use every time they submit a PR. The form includes what the ticket is about, testing instructions, and screen shots. Then I posted a link to the PR in a slack engineering channel for review by a developer. Once the ticket was reviewed and approved, I posted the same link to the QA channel for testing. Then and only then was when I got the all clear that I could push my code to production. :whew:

So what’s the design version of shipping code?

If developers can teach non-coders a specific process for how to ship code with the help of AI then what can I teach non-designers to do with AI to benefit the design process?

Everyone at Voze has access to Claude now so non-designers are creating mock ups and showing them to the product team. But then I’m still stuck in the old process where I’ll take the idea, which used to be a PRD or conversation with a PM and now it’s claude designs, and I take all the best parts and put together a new design that accounts for error states and edge cases and utilizes existing components or uses new components that I have context to create. Then I’m still creating tickets and including links to the designs. It’s scalable because it allows product teams to have a backlog of tickets ready to go so developers always have work. But that right there is an assumption that we even need a backlog. How much of the old process is up for debate? I think it really comes down to the size of your team and if you’re building a new product or adding features to an existing one. As one of my coworkers likes to say, nuance is the flavor!

The real takeaway

The coding process is clear and repeatable but the design process has always been constantly changing and it makes sense that it’s less systematized because of the nature of it.

I have some ideas around processes that I want to test out here at Voze with the goal of being able to teach non traditional designers how they can more directly have an impact on the quality and experience of our product. Maybe we’ll even start saying, ship your designs to prod!

Stay tuned for the ways we start to create more value out of AI design and coding tools here at Voze.