Changing how we build

Why it mattered

In fall 2026 we wanted to ship as many Picksy features as we could before the holidays. The usual way of working wasn't going to get us there: finish a Figma file, hand it off, wait two or three weeks to see it built, then find out what didn't survive the trip.

So the product, engineering and design leads got together to figure out how to deliver faster, and an AI-native development process came out of it. The tension was real from day one. Onboarding everyone takes time, some of the team was wary of AI, and pressure from senior leadership kept going up. I also had a worry of my own: the easy version of this future turns designers into a queue. Product writes a spec, the tools build it, and design reviews the output after the decisions are made.

My role

I was one of the leads who shaped the process, and I owned what design's part in it would be. I brought my team of four designers along with me. When Picksy pivoted to wishlists, I also did the work myself as the only designer on the squad, building the whole experience as a working prototype in code.

Making the process our own

The first pilots were mixed. One feature went from a normal two-to-three-week delivery to a working build in an afternoon. Others were messier. What made it work was adapting the process to how we actually build, instead of adopting it as written.

My one condition when I brought it to my team was that design helps write the spec. If the spec is what the tools build from, that's where design decisions have to live. Now design refines the intent and the spec alongside product, then gives the build as much context as the feature needs. Sometimes that's a pixel-perfect Figma file, sometimes it's interaction notes, and sometimes it's a fully working prototype built with Claude.

Bringing the team along

My team was cautiously excited. We held a lot of check-ins to make sure AI was helping us move faster without doing the design work for us. One designer was more reluctant than the rest, and what changed that was agreeing, as a team, exactly what design contributes to a spec. Once everyone could see their part, the process felt like theirs.

The part the team loved most was prototyping. With Claude they could bring a Figma file to life, with real interactions and small moments of delight that used to be impossible to show. Those prototypes made stakeholder buy-in much easier.

Putting it to work: wishlists

The biggest test was Picksy's pivot to wishlists, a net new feature of more than 20,000 lines of code. It went from feature agreement, through design, UX flows and a working prototype, to production in about a month.

I built the prototype with Claude and iterated with the squad every day, 62 versions in about three weeks. Engineers clicked through it and built against it, and daily huddles turned into working sessions. A lot of the real design work was written, not drawn. One long post settled how gifting worked: who can claim an item, what the button says ("I'll get this," not "Claim gift"), and how quantities read ("1 of 3 left").

Keeping the craft at speed

Speed creates a lot of small problems. I built a feedback tool with Claude so design, QA and code review could log issues in one place, and had my whole team click through the product. We found and fixed more than 200 bugs and pieces of design debt before launch, including subtle things like fonts falling back to Arial and card corners drifting from the system.

We also had to agree on what "shippable" means. Our rule is make it work, then make it nice. But what stakeholders see as designers "making it nice" is often just making it work correctly, so a lot of my job was getting product, engineering and design to the same definition before launch, not after.

Where I drew the line

AI made it easy for engineers to add features we'd planned for after launch, like friends and following. They worked technically, and that was impressive. But the experience wasn't ready: we had no notifications to tell people about follower activity, and no place in the navigation to put it. I pulled them from the launch. Features like that need real human thought about how they fit the product, and being easy to build doesn't change that.

Results

• The process grew from 1 team to all 4 of our commerce product teams, with plans to bring it to more teams across People Inc.
• Wishlists, 20,000+ lines of code, went from agreement to production in about a month
• 200+ bugs and design issues found and fixed before launch through a shared feedback tool
• Design now helps write specs, and prototypes in code are an accepted design deliverable

What I learned

• Faster building needs earlier thinking. On wishlists, engineers started building days after the first audit, so decisions landed while code was being written. AI sped up the build. It didn't give product and design more runway, and we needed it.
• Adoption is a team agreement, not a tool rollout. The reluctance faded once we agreed on what design owns. The tools were the easy part.
• Make the work shareable first. Teammates without AI tool access couldn't open my prototype, and I had to host it somewhere else. Now I start with who needs to see the work.
• The way we build is now something we design. Specs, prototypes and feedback tools are design surfaces. If design isn't there when those choices get made, design gets handed a queue.