If AI can design, what should you do?

The easy answer is to let it. Let it generate screens, write copy, and create ten options before you finish your coffee.

But moving faster is not the same as moving better. Execution without intention only makes teams faster at building things that may not matter.

At Headout, our design team works across product, brand, motion, writing, design engineering, and internal tools. We design the surfaces guests use to discover and book experiences, the systems teams use to move faster, and the details that make a product feel clear, useful, and alive.

For years, our rhythm was familiar. A designer spotted a quality gap. A writer noticed a line that needed changing. A motion designer knew how a transition should feel. A brand designer saw the same request come in for the tenth time. Then came the usual path: Figma to sprint, sprint to build, build to QA, QA to fix, fix to Slack thread. Sometimes, a meeting about the fix.

Nobody called it broken. It had a nicer name: process.

And to be fair, the process worked. But there was a time when the design team would raise thousands of product bugs and quality issues. The intent was always the same: make the product better. The problem was that the people who could see those gaps were often just far enough away from the product to need a ticket, a spec, a follow-up, or someone else’s bandwidth to close them. Over time, that distance started feeling like the actual problem.

‎

The question that changed things

Lately, something has quietly shifted inside our design function. The change was smaller, but far more meaningful: we began closing the gap ourselves.

What if a Product Designer could raise a working PR instead of only filing a bug? What if a UX Writer could fix a line directly at the source instead of waiting for a release pipeline? What if a Motion Designer could wire details into a Rive animation instead of explaining them through comments? What if a Brand Designer could turn a repeated request into a self-serve tool?

That is where AI became useful for us. Not as a shortcut around craft, not as a replacement for judgment, and not as a way to bypass engineering.

AI became useful because it reduced the distance between intent and execution.

‎

Before speed came access

Our entry point was Plato, our internal code assistant bot. We started with small changes: copy edits, spacing fixes, small UI improvements, and quality gaps that were too small for a full ticket but too visible to ignore.

Earlier, a change like that could move through a long chain: spot it, document it, prioritise it, wait for someone to pick it up, review it, and then check if it made it to production. With Plato, the loop became shorter. Designers and writers could raise lightweight PRs, make simple changes, and understand what was happening in the source instead of describing the issue from outside the system.

The early attempts were not clean. We opened unfamiliar files, dealt with build errors, raised messy PRs, and learned where we needed help. Some PRs were corrected. Some deserved to be closed. But that was the learning curve. We were not trying to turn designers into engineers overnight. We were trying to find the places where design could move closer to the product without making the system fragile.

Once the first few changes landed, the old way started feeling slower than it needed to be. After you have personally fixed a bug you used to only comment on, simply pointing at it starts feeling strange.

‎

From commenting on quality to shipping it

After the first few changes, the ambition grew naturally. We were no longer only asking, “Can we fix this?” We started asking, “Can we build enough of this ourselves to make the idea real?

That meant opening repositories locally, reading unfamiliar files, and using AI to understand what we were looking at. We were not suddenly fluent in engineering, but we became fluent enough to ask better questions, make safer changes, and stay closer to the work.

The work gradually moved from small corrections to real product contribution. A Designer built Headout’s Guarantee page end to end. Team members became code owners for Brand pages, including Careers and Operating Principles, which meant brand updates were no longer dependent on borrowed engineering time for every meaningful change.

But the shift was not limited to static pages or brand surfaces. Designers started building and shipping experiments on the main Headout product too: itinerary experiments that made trip consumption more visual, promotional banners across Headout pages, a brand positioning slice built from scratch with CSS-based animations, and multiple flow-polishing improvements across user journeys. These were not separate “AI projects” sitting on the side. They were product improvements: raised as PRs, reviewed, shipped, and in many cases run as experiments.

We also built Headout Detours end to end in code, a persistent in-app feature that uses micro-learning games to bring travel inspiration into the app even when users are not actively booking. It is ready to ship, with the backend logic, Supabase database, and product experience set up to support repeat engagement and future-trip discovery.

The loop also became more data-led. Because our BigQuery setup works with Claude, designers can now ask questions about experiments in natural language instead of always depending on Mixpanel fluency or someone else’s bandwidth to pull the numbers.

This changed how we saw design ownership. Earlier, it often ended at handoff. We defined the intent, documented the behaviour, reviewed the output, and caught the gaps after implementation. Now, for certain kinds of work, we could stay with the idea until it became real, shipped, and tested.

Engineering did not disappear from the process. The collaboration became sharper. Instead of asking engineers to interpret every small detail from a Figma file, we could show working code, raise a PR, and have a more concrete conversation. The work became less about translation and more about review, refinement, experimentation, and scale.

‎

Building inside the app environment

Dex needed a slightly higher level of fidelity because the experience depended on how it behaved inside the React Native app itself. Using Claude Code and Cursor, designers built working app references that people could actually use multiple times, react to, debate, and refine before deciding whether something was ready to release.

This showed up in work like the City Selector and the reimagined Dex home page, where map-led discovery, SVG animations, and location-aware interactions were central to the experience. These details were hard to judge from a static file or a disconnected prototype, so building them closer to the app helped the team understand how the product would actually feel in use.

‎

When the work repeats, build the system

Once designers were closer to the making, another pattern became obvious. A lot of design time was not going into deep thinking. It was going into repeatable work.

If marketing needs near-identical UI comparison tables again and again, should a designer build each one by hand? If a menu format repeats often enough, should it remain a request forever? If City Pass pages need similar structures across destinations, should every version start from scratch?

Probably not.

So we started using AI not just to generate output, but to separate design thinking from repeatable execution. We built internal tools like the menu creator, city pass generator, Alexandria for pulling experience and collection content into Figma, and Scarlet for testing localized content before it was deprecated.

The same thinking shaped the Promo Banners Tool, which is evolving into a way to create and manage promo banners on Headout surfaces. We also built AI-powered media tools like Path Creator for directional arrows on images and Poster Creator for generating Dex posters from scripts.

We turned repeated asks into self-serve systems and reduced the number of times design had to manually recreate the same format. We are not just producing output. We are creating leverage.

‎

This only works with guardrails

“Everyone can change everything” is not empowerment. It is chaos with good intentions.

As more designers moved closer to code, our design engineer made the shift sustainable. They reviewed designer-led PRs, caught edge cases early, and helped us understand when we were making a safe change versus when we needed deeper engineering support.

The goal was never to bypass engineering. The goal was to make collaboration more precise. The system works because there is trust, review, ownership, and a clear understanding of where design can move independently and where engineering needs to step in.

AI helped us move faster. Guardrails helped us move responsibly. Both mattered.

‎

What we are learning

The biggest change is not that designers at Headout now write more code. It is that designers are closer to the product they are shaping. That closeness changes the work. You understand constraints earlier, ask sharper questions, and notice the gap between what looks right in a mockup and what actually feels right in production.

AI helps us move faster, but it still does not know what deserves to exist. Taste, intent, and understanding still decide that. The workflows are young, the PRs are not always clean, and there are still plenty of moments where asking an engineer for help is the smartest move.

But the distance has reduced. The people who notice quality gaps are now closer to closing them. The people who imagine the experience are closer to making it real.

So, if AI can design, what should you do?

Get closer. Closer to the product, closer to the data, closer to the details, and closer to the moment where an idea becomes real.

That is what design at the speed of intent means for us at Headout: not moving fast for the sake of speed, but moving with less distance between what we mean and what we make.

‎

We take heading out seriously. Let’s take this offline.

If this way of working sounds exciting, we’d love to open it up. We’re hosting an offline session at our office to share how our design team is using AI across product, brand, motion, writing, design engineering, and internal tooling.

No boring decks. No generic case studies. Just the workflows that actually survived production. We’ll share how we started, what broke, what worked, where AI genuinely helped, where it didn’t, and how designers can move closer to the product without turning the whole system into chaos.

Date & time: 13th June, 2026, 2:30pm to 5:00pm IST.
Link: https://luma.com/gm54r7jg

Built something interesting with AI yourself? Share it when you RSVP. You'll be getting some supercool giveaways if you are picked among the top 20.

We’re just getting started. Come be part of it.

0

Loved it