Using Claude Design to bridge the gap between Product and Marketing
Fragmented app design across the org invited an interesting challenge for Marketing. Iute's HQ is in Estonia, while our customers are thousands of kilometres away in Albania, Bulgaria, Moldova, and Macedonia. Because of App Store limitations, employees at HQ don't have the ability to download Myiute (our app). That distance created an unusual problem for our team: we couldn't reliably see our own live product.
The problem began with screenshots. Myiute is our customer app, and it's also one of the most important products we have to market. If we were promoting a new app feature, updating an App Store listing, displaying the app's usability on our website, or creating a campaign, we needed to show the app often.
The issue:
The dev version: Our marketing team at HQ can't download the same version of Myiute that customers see because the app isn't available in Estonia. We have access to a development version of Myiute, but it was built for development and testing, not marketing. Getting into the dev version meant using different dummy login credentials every time, and once I was in, I had no control over what I would find. One test customer might have €1 in their wallet, another might be missing the product I needed to show, and sometimes entire sections of the app weren't available. None of those states were usable in marketing materials.
Screenshots: I tried getting screenshots from local iute employees on the ground in our markets. But real customers and employees weren't necessarily seeing the same version of Myiute as our development environment. Features, account states, and app versions varied, so I could ask someone in Moldova to screenshot a particular screen and hear, "I don't have that in my app." And honestly, even if they did have the screen I needed, using screenshots meant 1.) low resolution images, 2.) no ability to edit, and 3.) potentially risky personal information on display. Nope, nope, and nope.
Figma: Meanwhile, our product designers had a selection of beautifully designed Myiute screens in Figma, but the collection was incomplete and only displayed in English. None of our markets operate in English, nor do they show any content or copy in English.
I realized we were solving the wrong problem
At first I treated this as an access problem. I needed better access to the app, a better test account, or to take time and build out each localized screen in Figma. Every solution still left Marketing in a reactive state - dependent on a live product environment we couldn't control.
Eventually, I realized that I didn't actually need access to the live app. I needed an accurate, controlled way to represent our product for marketing. The ingredients already existed, they were just heavily scattered and siloed across the org. Our Product team had the UI components in Figma, our markets knew how the product copy needed to appear locally, and we knew which account states we needed to communicate. What we didn't have was a practical way to bring all of that together. That's where I found a useful role for Claude Design.
Building a marketing version of Myiute
I connected Claude to our Figma environment and built the workflow around the existing Myiute design system. The principle was simple: Claude could use our real product components to compose the screens Marketing needed, without depending on a live customer account. Instead of asking someone in Albania to go into figma and translate every piece of UI copy manually inside a nest of components, I could define and direct Claude to do 80% of the lifting.
For example, I could tell Claude to create a dashboard view of Myiute that includes the following information:
Market: Albania Language: Albanian Wallet balance: €500 Card: Active Loan: Active Next payment: €126 Payment due: 26 days Show also: Add a widget for our third-party car insurance offer
Claude could use the approved Myiute components to create that state in Figma. The numbers on the screen could support the story we were telling rather than being whatever happened to exist in a test account. This also gave us a much easier starting point for localization. When localized UI copy was available, Claude could use it. When it wasn't, the screen simply kept the English copy in those places, and our local marketing teams provided those specific pieces.
This was considerably easier than asking local teams to manually localize entire screens themselves. The same boundaries applied to the UI. Claude could compose approved components and valid product states, but it couldn't redesign Myiute, invent functionality, or create a product state that couldn't exist. The design system remained the source of truth, and the final localized screen still had a human review before it was used externally.
One request instead of five conversations
The difference became obvious in a real marketing request. Previously, if I needed a Romanian Myiute screen showing an active insurance product, I might have to contact the Moldova team, find dummy login details for the dev version of the app, check whether this account had the feature, discover it didn't, find new login details, take a pixelated screenshot, be unable to edit any screen details, and then later discover that the screenshot I used shows an outdated version of Myiute. Maddening is an understatement.
With this new workflow, I could start with a much simpler request:
"Create the Myiute insurance screen for Moldova in Romanian using the approved Active Insurance marketing state." Then iterate.
Claude built the screen from the existing product components and used whatever localized content we already had. If some copy remained in English, the Moldova marketing team only needed to update those specific elements rather than reconstructing the screen. Once the system existed, the same approach was repeated for Albania, Bulgaria, and Macedonia.
How this change affected the organization as a whole
The obvious benefit was speed. Marketing no longer needed to wait for the perfect combination of person, market, app version, and account state before we could show our own product.
Consistency was probably the bigger long-term win. Our websites, App Store listings, social content, campaigns, and product launches could all show Myiute using the same underlying product components and controlled account states. We could also create and review localized representations of the product from HQ, even when we couldn't access the local live app ourselves.
It reduced work across the company, too. Local marketing teams spent less time manually editing complex Figma components or hunting through their phones for screenshots. Product designers received fewer requests to manufacture marketing-specific screens. I gained the flexibility to create the product imagery Marketing needed without misrepresenting how Myiute actually works.
Most importantly, customers now see an app that looks like the product available in their market, rather than an English prototype, an outdated screenshot, or a random development account.
Finding the right job for AI
I initially looked at tools like Claude Design through the obvious design-production lens. I wanted to understand whether it could resize ads, populate templates, or make campaign production faster. For iute, those weren't the most dramatic time-savers. Our design system already makes most campaign adaptations extremely fast, and resizing an approved ad into our standard formats takes just a moment.
Mapping the friction showed me where we were actually losing time. The obstacle was popping up between Product, Marketing, and our local markets, long before anyone needed to resize an ad. Claude Design gave Marketing controlled access to a product we previously struggled to represent, while keeping our real design system, local expertise, and human review at the centre of the process.
That's the standard I use when introducing AI into a creative workflow: find the friction first, then decide whether AI deserves a place in the solution.
Still Reading? Thanks! You get a treat 🍪
Something surprising happened after we began implementing Claude Design. Early on at iute, I noticed that customers were visiting our physical locations because they had questions about how to use the app. I flagged this as a major problem. If someone downloads a digital product and doesn't immediately understand it, asking them to travel to a physical location for help creates an unreasonable amount of friction. I suggested that our website should do more of that work up front, using interactive Myiute screens to help customers explore the app, understand key features, and get comfortable with it before they ever need to ask for help.
To bring the idea to life, I connected our existing Myiute designs in Figma to Claude Code through MCP. This gave Claude Code direct access to the product's design context and allowed us to turn selected app screens into an interactive web experience while staying faithful to the real Myiute interface. The result now lives directly on our homepage, giving customers a simple way to explore and understand the product from their browser, while giving Marketing a new way to communicate how Myiute actually works.
Comments