Closing the gap between design quality and what gets shipped
At Monzo, we treat design quality as essential to the reliability and trust of the product. Small details are not “nice to haves” when they shape whether customers understand what’s happening, feel in control, know their funds are safe, and believe the product is robust.
Designers often spot issues early. Copy inconsistencies, UI rough edges, minor regressions. The problem is not awareness. It’s velocity. Historically, fixing these issues depended on engineering capacity and prioritisation, and that gap can impact both product quality and customer trust.
We’re changing that intentionally.
We’re enabling designers to ship small, well-scoped changes in production code, without changing production standards and safety. This is not about replacing engineers or bypassing process. It's about closing the gap between what design can see and what the product can ship, safely.
A big catalyst for this was Senior Lead Designer Heldiney Pereira, who championed AI internally and spearheaded the Designer Shipping to Prod competition. It gave designers a reason to try, share learnings, and build confidence. The result is not “vibes”, but a more capable design team operating inside real engineering guardrails.
The expectation for designers is simple: be curious, not scared. Start small, stay responsible, and work in partnership with engineering. If we do this well, we improve quality, reduce friction, and ship faster on the details that customers actually notice.
The following examples show how some of the first designers at Monzo have started shipping to production, and how this has translated into real productivity gains.
How designers improve quality by shipping small, safe changes
Susan Walsh, Lead Product Designer
I started using Cursor not to become an engineer, but due to curiosity, and to create prototypes, but quickly realised it gave me leverage over something that matters more than tooling: product quality and user trust.
Fixing small, well-scoped issues directly changes the system. Designers can move faster, reduce friction, and take clearer ownership of product quality without bypassing safety.
I started with a deliberately small change to understand both the process and the impact. On Business Banking web, a title read “Get Paid online”, while on mobile it was “Get Paid”, creating a clear mismatch across platforms. A small change, but these details shape how coherent and considered a product feels, and this is where customer trust is built.
Shipping to production reframed how I think about designers working in code. Owning the path from problem to outcome made it clear that this only works because safety is built in, and with the guidance of my engineering partner, Paula.
Working in real repos, committing through GitHub, and shipping within established guardrails is disciplined work. When designers ship code, the same expectations apply around quality, review, and safety as any other production change. Designers are not bypassing engineering. Code review is mandatory and deployment remains with engineers who have completed the required safety checks.
These constraints are not incidental, they are what make this viable at scale and acceptable in the highly regulated financial environment.
This experience reframed how I think about designers writing production code. It’s not “vibe coding” or a threat to engineering. It is design taking responsibility for outcomes, not just intent. When a designer can spot and fix them directly, quality improves by default.
Not every designer needs to ship features, but many should be able to make safe, scoped changes to the surfaces they already own. Treating this as niche keeps teams slow and reinforces unnecessary dependencies.
I am still a long way off shipping end-to-end features, and that is fine. What has changed is my sense of agency, technical understanding and accountability. I can take clearer ownership of UI quality and the frontend experience, while operating within the same safety standards as engineering.


Once designers are operating within clear guardrails, the next shift is increasing productivity. Sasha will talk through at what designer contribution in production actually looks like, how the tools increase productivity and how this work fits into day-to-day product delivery.
Designers are learning to ship safely with AI and engineering support
Sasha Ward, Lead Product Designer
Early in my design career, I took a front-end web engineering course to learn HTML, CSS and JavaScript. I’d never coded before, and I still remember that aha moment when a single line of CSS made a div turn red. My goal wasn’t to become an engineer, but to understand what’s possible, how things actually get built, and to have better, more productive conversations with engineers.
I left the course satisfied, but acutely aware of the gap between what I could realistically build and what the engineers around me were shipping every day. Without hours of learning new programming languages and building side projects, I knew I’d never meaningfully contribute and my understanding would be surface level at best.
Fast forward to 2026, and the landscape looks very different.
It’s mind-blowing how far AI has come and how much access to knowledge and speed it’s giving us. On the Joint Accounts team at Monzo, I’ve started using tools like Cursor to query our codebases directly. I can ask it to explain how a part of the app works and it’ll walk me through, in detail, in language that makes sense to me.
Normally, I’d need to pair with an engineer, map out behaviour together, and go back and forth to fully understand what was happening. Now, I spend ten minutes writing a detailed prompt, wait a few minutes, and read through a clear explanation.
The same is true for contributing to the codebase itself. I’ve never learned Go, but with AI’s help I’ve written a handful of lines and made small changes to our backend. They’re modest changes on the surface, but they point to a bigger shift in how we as ‘AI-enhanced-designers-that-can-fix-some-things’ build products. We don’t need to know every language – we need to understand fundamentals, engineering practices, and work with AI to get us 80% of the way there.
We created this guide to help designers build confidence with the Github workflow and contribute to the codebase. It received positive feedback internally, so we’ve made it public. We’d love to hear if you find it helpful too.

That said, AI isn’t a replacement for human collaboration. Close partnerships with engineers matter more so now than ever. If your pull request breaks acceptance tests, it’s still your responsibility to understand why and fix it. Yes, AI could help you out but working with an engineer to understand what’s failing and why can help you get a better understanding of how things are built, why they’re built that way and how to rethink your approach in the future.
The tools we have available to us now can unlock a new world of productivity, creativity and collaboration – enabling us to solve problems faster and create meaningful impact for customers. When designers and engineers are collaborating in these new ways, novel opportunities arise where they might not have before.
What Designer-Shipped Changes Look Like in Practice
Justin Thrift, Senior Product Designer
Last year I was staffed as the sole designer on a team building a new product 0-1. Over the summer and autumn, our product slowly began taking shape as we swivelled between research, design, code, and various forms of testing. Being in stealth mode means when our engineers ship code, it deploys to production, but hides behind a feature flag where it stays until launch day.
Launches inevitably create a unique challenge for any team to navigate: that deadline tension between the demands of launch day and the work needed to get there. We’re constantly asking ourselves, “Is this really necessary for launch?” And since this is Monzo, de-scoping those little details that add a touch of magic is never an acceptable tradeoff (something I love being empowered with as a designer).
Of course, time ticks by and unexpected technical gremlins and edge cases inevitably rear their heads (despite everyone’s best efforts to forecast). We all know an ideal development cycle might look something like:
Research is conducted that informs designs, and the team iterates until everyone is aligned on a design that solves for customer and business requirements
Engineering builds something great
We ship something great, and begin learning how to improve it even more
But in reality what we’ve experienced is a more familiar situation for anyone who has ever built something from the ground up: a fluid, non-linear development process:
Conduct extensive research
Start designing, while conducting more research
Validate usability and early concepts
Share updates with stakeholders and receive more feedback
Engineering begins laying foundational infrastructure
More feedback
Engineering begins building core flows
We slightly redesign some screens that have already been built
A writer helps re-write all the product copy
Engineering builds another part of the product
Some marketing research, more feedback
And so on, and so on… You get the idea ;)
In this scenario in which the product is being built at pace, it’s easy for small details to be added to a backlog somewhere by a designer sweating in the corner hoping they can successfully advocate for these details to get addressed.
This is where I’ve had the opportunity to build in a way I’ve never experienced before as a designer by actually shipping changes to production. This has looked something like:
A design change is identified
I mock the change or prototype it - to ensure alignment
I make the change, raise a PR, and review with engineering
Once approved, I deploy the change to production behind our feature flag
Not only is this removing tasks from the engineering backlog, it’s giving me a direct role in shaping the end experience our customers will experience. In a short amount of time, I’ve built the confidence to pursue more of this type of design work, and understand at a deeper level how great products are built.
Summary
While designers at Monzo are not yet shipping full features or new products end-to-end, they are engaging in the development process in a new way, made possible by improved tooling and a lot of curiosity. The payoff is that designers are opening up new ways to explore solutions to the problems they’re solving, staying close to how products are built, and building stronger working relationships with their engineering colleagues.
We now have close to ten designers who have successfully shipped changes to production, and it’s only going to increase. That matters. It shows this is not an isolated experiment, but something that can be learned, repeated, and supported within existing teams. The process is still evolving. It is iterative, sometimes imperfect, and genuinely energising.
The simple act of finding something that needs fixing, engaging with the code to understand it, and guiding a pull request through to deployment enables designers to create another layer of impact for both customers and the business.
Interested in a career at Monzo?
If what you’ve read here resonates and you’re passionate about making money work for everyone, we’re hiring designers, engineers, product managers and many more across Monzo! Take a look at our careers page to see if we have the right role for you.