From Figma to Production:
Closing the Gap on a Luxury Travel Rebrand
Designing for the real product,
not the ideal one
Context Travel's rebrand arrived as a set of Figma files from an external agency. No interaction spec. No edge cases. No accessibility considerations. A launch date that was fixed before the files were finished.
As the sole designer-engineer on the project, I was responsible for translating that visual direction into a production-ready component system built on a Rails application. That meant making every decision the agency didn't make: hover states, empty states, edge cases, accessibility patterns, mobile density, and the dozens of UI moments that only surface when ideal design meets real content.
A visual direction, a fixed deadline,
and every decision in between still to be made.
A new marketing hire brought in an external agency to lead the visual rebrand. The direction was set through the agency, validated by the marketing hire, and approved by leadership. I was not in those conversations.
What I received was the output: Figma files with a polished visual direction, designed in ideal conditions, against ideal content, for an idealized version of the product.
A constraints document was written to give the agency guardrails around real content requirements. It was never acted on. The gap between what the files showed and what the product actually needed became mine to close in production.
The design looked right in the files. My job was to make it right in the product.
Ideal Conditions
- Figma files only — no interaction spec
- No edge cases or empty states
- No accessibility considerations
- Ideal copy lengths, not real ones
- Dark sky imagery, not our actual photo library
- Files still changing when build started
Real Conditions
- Full interaction and state design
- Cities with 0, 3, and 40 products
- WCAG-compliant accessibility patterns
- Copy that runs 2x the ideal length
- Bright sky images that blow out white UI elements
- A stable system before files were locked
Six categories of design problems
that only surface when ideal meets real
Every item below was discovered during build. Each one required a design decision, a code implementation, and in some cases a stakeholder conversation. None were in the Figma files.
Real copy broke the layouts
The agency used short, punchy placeholder titles and descriptions. Our actual city and tour copy regularly runs two to three times longer. Cards that looked elegant in the files became overloaded and cramped the moment real content landed in them. Typography, spacing, and truncation logic all needed to be rethought.
The image library blew out white UI
The agency designed against dramatic dark skies. Our actual photo library, curated by our marketing team, features a lot of bright skies and high-key images. A save icon designed as a white outline completely disappeared into those images. Every UI element layered over photography had to be pressure-tested against our real assets, not the agency's selections.
Edge case cities didn't exist in the spec
The design assumed a comfortable middle: a city page with a full, even grid of products. In reality we have cities that are live for SEO purposes with zero products, cities with three products that won't fill a row, and cities with forty products requiring pagination logic. The system needed to handle all of these gracefully without individual design intervention per city.
Mobile card density would have buried conversion
The agency's mobile treatment showed 1.7 product cards in the viewport. Our previous design showed 6. That's not a small difference, it fundamentally changes how users browse and evaluate options. I flagged this directly to the marketing hire and CEO, advocated for a more density-appropriate approach, and was overruled. The marketing hire's preference was implemented. The concern is documented.
Accessibility had not been addressed
Context Travel is a walking tour company with a significant population of aging travelers who have real accessibility questions before booking. The new design had no pattern for surfacing this information. I proposed and built a progressive disclosure solution: a subtle link near the tour description that opens a dedicated accessibility panel. Visible to those who need it. Unobtrusive to those who don't.
Missing UI states and components
Hover states, animation interactions, focus states, empty search results, and several UI components that the business requires but the agency spec never addressed, including the Map Popup on the cities index page. Each was identified during build, designed to match the established system, coded, and PR'd into the codebase.
Architecture decisions that made scale possible.
The existing codebase had a working Molecules and Organisms structure. Rather than rebuild from scratch, I made the call to continue that architecture and invest the effort in doing it properly: clean SCSS from scratch, a complete component library, and Lookbook as the team's shared reference tool.
That decision mattered because we're a team of one designer and two developers. A system that developers can browse, inspect, and pull markup from directly reduces friction and preserves design intent through implementation. Lookbook turned the component library from a design artifact into a shared team resource.
The decisions that weren't in any file.
These aren't implementation notes. These are the moments where the work required design leadership rather than design execution.
Small cities and large cities needed different treatments
The spec designed for one version of a city page. In practice, a city with 3 products and a city with 40 products are fundamentally different browsing experiences. I flagged the gap, brought it to the Product Leader, and we co-designed a solution that gave each city type an appropriate layout and content hierarchy. This wasn't in the brief. It came from looking at the real product and asking what it actually needed.
We started building before the files were locked
The launch date was fixed before the agency finished. To have any chance of hitting March 10, we had to start implementation while files were still in motion. That decision kept us on schedule and produced some minor inconsistencies in font sizing, icon sizing, and spacing where the agency made late finalizations after we'd already built. Launch day was clean. Some of those inconsistencies were addressed in the weeks that followed. It was the right trade.
Accessibility information needed to be findable without being prominent
Walking tours have real physical accessibility considerations. Our aging traveler segment needs this information before they can commit to a booking. The rebrand had no pattern for it. Making it prominent risked creating anxiety for travelers who didn't need it. Making it hidden meant travelers who did need it wouldn't find it. I proposed and built a progressive disclosure pattern: a subtle contextual link near the tour description that opens a dedicated accessibility panel. Present for those who are looking. Invisible to those who aren't.
System remains in active use. Components continue to be added as new product surface areas are designed and built.
What I'd fight for next time.
The biggest lesson from this project is about the cost of designing in ideal conditions. Real content is harder than it looks in a Figma file. Real images have bright skies. Real titles run long. Real product counts don't fill a row evenly.
The agency used a "stress test" in their process. It didn't reach the average character count of our actual tour titles. A save button designed as a white outline looked perfect against their selected photography. It disappeared entirely against our actual marketing library.
If I were shaping the next engagement like this one, I'd push hard for real content, real images, and real inventory numbers in the design phase — before a single component is built. Not as a critique of the agency's process, but because the gap between ideal design and real product is where most of the actual design work happens. Getting there faster saves weeks of downstream correction.
The gap between what a design looks like in ideal conditions and what it needs to handle in production, that's not an implementation problem. That's a design problem. It just shows up later than it should.
-- Michaela Hoffman