In the Gusto Design org, we just went through one of the biggest shifts that any of us have seen in our careers: we transformed from a traditional design team to an “AI-native” one within a quarter and are now benchmarking ahead of the industry [source]. We know that many design teams are going through this same earthshaking shift and often struggling to define tangibly what changes should be happening. We went through our own long journey to reach this point and wanted to offer some perspective and advice.
This isn’t really happening.
We knew that this change was coming long before we actually made it happen. Last year, Gusto made several attempts at organic AI adoption: we had AI hackathons, we had AI stipends to try new tools, we were investing in building AI-enabled experiences for our customers. In all of those attempts, it never felt like it was something that unlocked anything useful for designers. We had tools that could accelerate coding that made sense for engineers. We had tools that could consolidate and synthesize ideas that made sense for product managers.
The truth is, most designers spent those early hackathons just fighting with the robots to make something that vaguely looked like a phishing site version of Gusto. Early on it felt like a hindrance to the design process. The tools just weren’t a fit for designers. They largely felt like toys that didn’t meaningfully change or improve how we were already working. So, for a while, there were some false starts, but mostly, we sat in limbo, knowing a big change was coming, and hoping design tools would “catch up”.
Maybe it’s happening?
Then, in late 2025, the tools got better… just not for designers.
The coding models dramatically improved, Anthropic released Claude Cowork, and everyone around us started really flying.
Amy Thibodeau, our Chief Design Officer, didn’t want this change to be something that happened to designers. We wanted to be in the driver’s seat defining what this actually meant for us, and finding a way to take advantage of the most useful capabilities of AI, hopeful that this might actually help us lean into craft in a meaningful way. We knew that:
Everyone around us was using AI to go faster, and if design was a bottleneck or operating at a slower pace, we would be left behind
There was a lot in our approach that was wasn’t a great use of our time (ex: navigating design system documentation to try to find the right component)
Craft and customer experience is a key differentiator for Gusto–we wanted to make sure to continue to invest in it deeply and hoped that using AI thoughtfully would actually give us more capacity to own the customer experience, not less
So, this became our top team priority. And if I’m being honest, we were feeling around in the dark for a while before things started to make sense.
Amy discusses the responsibility she felt as a design leader to help her team build these skills
We had an onsite for our design management team where we spent two days defining what this could mean for our team. We talked about responsibility, ethics, and advocating for the customer. We shared our feelings and discomfort. At the end of that onsite, we still didn’t have a tangible “so what do we do now?” answer but at least we felt that we’d turned on the light a bit.
Then, Amy made a suggestion: she wanted every designer to ship a pull request (PR) at our design team onsite. There was a lot of discomfort at this suggestion, a lot of pushback that that was too short notice, that it would be a monumental effort to get designers even set up in their dev environment, and that shipping to production wasn’t what designers should focus on.
The rationale Amy had for why this was the right focus was that it would get people up and running and give them the technical proficiency to have more direct ownership over the customer experience. Although this wasn’t going to be a replacement for the deep problem solving, customer understanding, and attention to craft designers spend time on, it would enable us to move towards making our work more real and tangible. Instead of relying on an engineer’s backlog list to try to fix something broken in the experience, designers could ship those changes directly. And during the launch of a new product or feature, they could personally take accountability for making sure thoughtful customer-facing UX decisions were in scope.
…And we did it! Prior to our December 2025 onsite, we ran multiple office hours with our dev environments team, working through the many headaches and technical challenges to get designers set up in a code-first world. While this process was painful, it was also a good moment for Gusto as an organization to take note of the pain and struggles that non-engineers would have to go through if we are truly trying to become a “builder” organization where non-engineers can work with these types of tools. This has directly led to improvements to the dev environment setup process for everyone.
Katie leading a session to teach the design team how to ship a pull request, December 2025
At that onsite, we spent a full day walking through the process of how to make a change in the codebase, how to see that change in your local staging environment, how to create a pull request, and the full lifecycle of merging our changes into production. This is often a very opaque and scary process for designers, and we wanted to demystify it.
The goal for the changes we wanted designers to make during the onsite was about learning this process and feeling the overwhelming joy at “I did something that our customers can see.” Even though most of the changes we shipped that week were small in scope, most designers found the process fulfilling. Some were energized and continued on this momentum and made more updates here and there, but if we’re being honest, when we looked at Github a few months later, most designers hadn’t shipped anything since this onsite. It was a fun activity, but it didn’t kickstart an AI-native transformation.
It’s really happening.
In January 2026, another hackathon was scheduled. I couldn’t accept another hackathon where everyone had to fight the tooling to make UI that looks like Gusto, so I wanted to figure out a way to actually use our real design system components to design with AI. I worked with a design system engineer, Jay Johnson, to build out an MCP for Workbench (our design system) so that AI tools could actually use the live components. I also built out something I wanted for my own workflow: a shell clone of our application that provided a mock version of our real application to prototype in, removing the need to recreate the scaffolding. This is a tool that we call “Gusto Sandbox” and it lives in our production codebase and has access to all of the context about how Gusto works. This combination started to feel like it was solving real problems for designers. We debuted it at the January hackathon and encouraged people to use it. We got great feedback that it was delivering high quality results people were not used to and many teams were blown away by the output and how much it accelerated their ability to make things that looked, felt, and functioned like Gusto.
It started to feel like we were shaping something that designers could get behind and like we had a real “AI-native” alternative that was built for design workflows. We started outlining more of this toolstack and what we could use for different parts of the design process and where there were still notable gaps, like collaborative files and gathering feedback. Now that we actually had an alternative, Amy announced at our February design all hands that she wanted every designer to have fully transformed the way that they’re working by June 1 and for static Figma files to no longer be how we work.
There was understandably a lot of fear, uncertainty, and doubt from the design team, and some mixed feelings across R&D. Some engineers weren’t thrilled about designers being in the code and PMs were worried about moving away from a tool they had also come to rely on.
Designers were worried about how they would ensure the right experience guardrails were in place to get a good output from AI. To address this, we launched a number of Claude Code skills such as an experience auditor that enabled people to review any prototypes against established criteria, like platform correctness and wayfinding. I even built a plugin for design that will handle all of that manual PR, branch, and other git workflow management for designers so that we could lower the technical barrier to entry for this new way of working. Designer’s human judgement on craft is being replaced by AI, but using AI enables us to spend more of our time focused on where that judgement is best used.
Amy elaborates on making a decision that would shake the team out of their comfort zone
And then things really kicked into motion! We put together a small “design transformation working group” with Jadyn Aguilar and Danielle Barnes, our operations leads, along with Amy, myself, and a few design managers. Working backwards from June 1, we outlined a program with a volunteer cohort to get early feedback and help close more gaps.
We had champions to help advocate for new working styles with other designers, peer to peer, and held office hours multiple times a week to support people. We assigned designers an engineering “buddy” to help review their PRs and answer their technical questions and, in general, just tried to put every available opportunity out there for designers to take advantage of. Surprisingly, what we saw helping the most was #ai-designing, a Slack channel that became an ad hoc community to share tips and tricks, ideas, and new workflows with other designers. This started small and optional, and with general troubleshooting questions. But very quickly, it gained a lot of momentum and designers genuinely learned new ways to deliver truly impressive design work. It quickly expanded with even PMs and engineers joining in to learn how to better design with AI. The momentum in this channel also showed us that the “volunteer early adopters” quickly became “pretty much every designer.” Since the day after Amy’s announcement, every designer took the mandate seriously and started to really experiment with new tools and ways of working.
Getting the reps in
Amy’s encouragement during this phase was just about “getting the reps in”. There’s a parable about how practice leads to quality about pottery that she shared. Essentially: two groups of people. One group is told to make the perfect pot. The other group is told to make as many pots as possible. At the end, the group that has focused on making a lot of pots also ends up making a higher quality product.
We just needed people to practice and accept that early outputs might be messy.
Suddenly, things were evolving at a rapid clip. It even started to feel… fun? We started to hear from designers that they now dreaded having to go back in and use Figma because they preferred this new way of working.
What also came out of this was the organic way that our design team started to build our own ideal workflow. Designers and researchers started dabbling in building more agent Skills for specific parts of the design process, like synthesizing research or auditing component usage.
As a distributed team, being able to work together asynchronously is important to us and a meaningful limitation we still had. We closed this gap by having our AI Dev tooling team build out “shareable links” for our sandbox prototypes, so creating a PR for a prototype will give you a real link that you can send someone on your team to see your prototype. Then people wanted the ability to comment on prototypes, which a design lead Will Tsui and engineer Daniel Flynn worked to build out commenting on top of the Sandbox . Although there will always be tooling gaps to fill, this step was an important way to demonstrate that with AI, we are capable of filling many gaps ourselves instead of relying on a third party to build out what we need. That early work that we did getting designers familiar with the Github and PR workflow started to really pay off, and we were able to build this very bespoke design workflow on top of it—using our real codebase, our real design system.
A screenshot of the Sandbox environment with commenting feature
The momentum from this exposed that there was a really big opportunity to rethink how we were approaching Design Systems and rethinking what it meant for “Builders” more generally. There was a lot of really important work being done on the team and a lot more that we could do to make sure that LLMs were making good design decisions at scale—for everyone, not just designers. Amy worked with our Design System leaders to reposition the team as “Builder Enablement” with a new formal mission dedicated to supporting this type of work, formally supporting and extending things like the Sandbox environment, Workbench MCP, and more forward looking AI-designing workflows.
The momentum then really has just continued from here. We started to build AI into our interviewing plans and career frameworks. We started figuring out how to measure it objectively. Gusto began implementing a performance expectation around AI. The codification all around us enforced what designers were already doing. Of course, there are still growing pains and we have been continuing to battle test this new way of working. There have still been some lingering questions like “well what does the engineering handoff look like now?” (much more seamless now that designs are in code!), “how do we still do discovery?” (we’ve actually been running parallel UXR at a much faster and iterative pace as part of the build process), and “what unique value do designers bring in this world?” (more on that next).
Putting it to the test
Which brings us to how we put this entire transformation to the test with Gusto’s latest launch: Cofounder. Cofounder was a project born organically from a group of builders with a builder mindset. I, along with 4 engineers (Matan Zruya, Ngan Pham, Jeff Carbonella, and Eddie Kim), started riffing and prototyping on some ideas in late March. I wanted to test our AI-native design workflow with this project, and used our new prototyping workflow to quickly mock up my ideas. That same day that the team kicked off this work at an onsite on March 24, one of our researchers, Andrew Rajaram, simultaneously began concept testing that prototype. While the engineers were sketching out the data model, Raj was feeding me customer insights and I began iterating on the design in real time. By the end of the week, I had already transitioned that prototype to production frontend behind a feature flag (reviewed and approved by the engineers!).
An overview of Cofounder’s experience
From there, the team worked in a truly AI-native way to build Cofounder. We were all in it, building it out together, making dozens of iterations in real time, and working towards different customer facing milestones. We ran a session in New York with our Small Business Advisory Council and then a closed beta cohort. I was able to use Claude Code and build out a significant portion of the frontend myself. The engineers found it easier to build out the backend when there was already a frontend existing to hook into, stubbed in from my prototype code. As a designer, I was able to take on features that traditionally would have been labeled as “nice to have” and been cut for an MVP. I was able to deep dive on every design decision, dogfood the product we were building, and shape the user experience based on my constant usage of the real product. I could build out things like transition animations, something teams almost never have time for and is always considered scope creep. I built out a lot of conversational UI widgets and created evals to shape the agent behavior on how to use them. I deleted the things that I built that didn’t resonate. By the time Cofounder launched, I had shipped around 150 PRs contributing to it. From whiteboard to launch, in 11 weeks. These were all experience details that in the traditional software lifecycle would have taken a lot of negotiation to get prioritized, but I could build them in an afternoon.
The end solution of Cofounder wouldn’t have been possible in the “old way” of designing. It is nearly impossible to make decisions on non-deterministic behavior in static screens. It’s impossible to really understand how an experience feels until you can actually use it. And if we had front-loaded all of these decisions in a design mock 3 months ago, we never would have gotten the nuance right of how Cofounder behaves or how we explain a radically different product to small business owners.
Katie discusses some of the design challenges she faced building Cofounder
Our new normal
That’s really the biggest takeaway for us: working in this new way is giving designers agency in a way that we haven’t historically had.
It’s easy for teams to think that AI is just a “tooling” conversation, but it elevates what designers bring to the table. It means no mistranslation in the handoff. It means not blocking engineers and saying, sure, ship that backend functionality and I’ll go in and fix the design after you. It’s true collaboration in a way we haven’t been able to experience before when designers weren’t working in the medium that our customers see. We really see this as an opportunity for accelerated judgment: the ability for designers to apply craft and customer insights directly into production, to get it into the customer’s hands faster and better than it would have been in the old way.
For other design teams that are struggling with this transformation: we know it’s not easy, especially as the world is shifting all around us every day. The biggest pieces of advice we can offer are to feel a real sense of responsibility towards your team and setting them up for success in their careers: which may mean making unpopular decisions. There is real, structural work to be done to support teams through this transformation. It’s important as a design leader to make sure that you have the buy-in from your cross-functional peers to support and enable a massive transformation like this. We wouldn’t have been able to take this leap without the support from our engineering and product organizations, and Gusto as a whole.
This transformation wasn’t just about a process change for us, it was a chance for design to rethink the level of impact that we can have. It enabled us as a design team to tackle high-leverage strategic problems, like a radically different paradigm for our product, in a matter of weeks and with a designer leading the vision for our product. This is the ultimate value of the transformation for us: designers having more impact than ever before.
Want to help us define what the future of design looks like? We’re hiring!
Thank you to Amy Thibodeau for her feedback on this post and Yuri Sakakibara for the illustration.
