---
title: "Design Handoff: From Design System to Live Frontend"
canonical_url: "https://www.laioutr.com/en/blog/design-system-to-live-frontend-without-handoff-loss-2026"
locale: en
meta:
description: "Design tokens turn into hardcoded values, component variants never ship, and states like loading or empty get improvised. Here is how to close the gap."
"og:description": "Design tokens turn into hardcoded values, component variants never ship, and states like loading or empty get improvised. Here is how to close the gap."
"og:title": "Design Handoff: From Design System to Live Frontend"
---
# From Design System to Live Frontend Without Handoff Loss
Table of contents
1. [1.Three places the handoff actually breaks](#three-places-the-handoff-actually-breaks)
2. [2.Tokens that survive the handoff, and the ones that do not](#tokens-that-survive-the-handoff-and-the-ones-that-do-not)
3. [3.Variants that exist in the design file and nowhere else](#variants-that-exist-in-the-design-file-and-nowhere-else)
4. [4.The states nobody designs: loading, empty, and error](#the-states-nobody-designs-loading-empty-and-error)
5. [5.Closing the loop structurally instead of through review comments](#closing-the-loop-structurally-instead-of-through-review-comments)
6. [6.A five-step way to wire it together](#a-five-step-way-to-wire-it-together)
7. [7.Where this fits into a broader frontend architecture](#where-this-fits-into-a-broader-frontend-architecture)
8. [8.Frequently asked questions](#frequently-asked-questions)
9. [9.Next steps](#next-steps)
10. [10.More from the Laioutr platform](#more-from-the-laioutr-platform)
1. [1.Three places the handoff actually breaks](#three-places-the-handoff-actually-breaks)
2. [2.Tokens that survive the handoff, and the ones that do not](#tokens-that-survive-the-handoff-and-the-ones-that-do-not)
3. [3.Variants that exist in the design file and nowhere else](#variants-that-exist-in-the-design-file-and-nowhere-else)
4. [4.The states nobody designs: loading, empty, and error](#the-states-nobody-designs-loading-empty-and-error)
5. [5.Closing the loop structurally instead of through review comments](#closing-the-loop-structurally-instead-of-through-review-comments)
6. [6.A five-step way to wire it together](#a-five-step-way-to-wire-it-together)
7. [7.Where this fits into a broader frontend architecture](#where-this-fits-into-a-broader-frontend-architecture)
8. [8.Frequently asked questions](#frequently-asked-questions)
9. [9.Next steps](#next-steps)
10. [10.More from the Laioutr platform](#more-from-the-laioutr-platform)
A design system is not the same thing as a live frontend, and the gap between the two is where most visible product drift actually comes from. Tokens defined in a source file get rewritten as raw hex values the moment a developer cannot find the right one in code. Variants that exist cleanly in a design library never make it into the component that ships, because building the tenth variant costs more than the deadline allows. States a real interface needs constantly, loading, empty, and error, rarely get designed at all, so whoever builds the screen improvises something reasonable and moves on. None of this is carelessness. It is what happens when a design system and a live frontend are treated as two artifacts connected by a review comment, instead of one system with a single source of truth. Here is where that loss happens, and how to close it structurally.
## Three places the handoff actually breaks
Ask a designer and a developer separately where a design system breaks down, and the specifics differ, but the pattern repeats across teams. First, tokens survive the handoff only as long as a component needs nothing outside the token file. A developer under deadline pressure writes \`#5B4FE9\` directly into a component rather than filing a request for a new token, and that hardcoded value now lives in production, invisible to the design system and immune to whatever the token changes to next quarter. Second, variants are cheap to draw and expensive to build. A design file can hold a disabled state, a compact density, a right-to-left mirror, and a dark-mode version of the same button without much extra effort. Implementing all four means four more code paths and four more chances for a regression, so only the variants an initial ticket asks for get built, and the rest live in the design file as intent rather than working software. Third, and most underestimated, the states an interface spends the most real-world time in are the ones nobody designs at all.
## Tokens that survive the handoff, and the ones that do not
The fix for the token half of this problem already exists as an open specification, even if adoption is uneven. The [W3C Design Tokens Community Group](https://www.w3.org/community/design-tokens/) has been drafting a shared JSON format for design tokens, so a token defined once in a design tool can be exported and consumed by a codebase without a human retyping hex values along the way. [Style Dictionary](https://amzn.github.io/style-dictionary/), the open-source build tool originally released by Amazon, takes tokens in that kind of structured format and transforms them into whatever a platform needs: CSS custom properties, a Swift enum, an Android XML resource. Figma's own [Variables](https://www.figma.com/variables/) feature and its [Dev Mode](https://www.figma.com/dev-mode/) inspector exist specifically to close the inspection gap between what a designer sees and what a developer can copy into code without guessing. None of these tools fix the handoff alone. A token pipeline only holds if every token a designer can pick maps to a token a developer can reference by name, and if adding a new token is a five-minute pull request rather than a backlog ticket that sits for a sprint.
## Variants that exist in the design file and nowhere else
A component library review is a useful ritual, but it only catches drift after the fact, once a variant already shipped without the states the design file specified. The more durable fix is to treat variant coverage as a property of the component contract itself, defined once in the schema that both the design tool and the codebase read from, not re-derived from memory every time someone opens a design file. A button component's contract should state explicitly which combinations of state, size, and density are supported, and a component that claims to support disabled should actually render a disabled visual treatment, not silently fall back to default because nobody wired it up. This is less about process discipline and more about making the unsupported combination impossible to ship by accident. When a component's prop types only allow variants that were actually implemented, a designer cannot select a combination in the design tool that does not exist in code, which removes an entire category of handoff review from the conversation before it starts. The alternative, a shared spreadsheet of which variants are done, works for exactly as long as someone keeps updating it by hand.
## The states nobody designs: loading, empty, and error
Open most design files for an existing product and count how many screens show the empty state, the loading skeleton, or the specific error a user sees when a request times out. The number is almost always close to zero, and yet a user hits one of those three states constantly: on a slow connection, on a first visit before any data exists, on a search that returns nothing, on a payment that fails. Because these states are not designed, they get invented by whoever is closest to the code the day the ticket comes up, which means the same product ends up with three different loading treatments and two different empty-state illustrations, none reviewed against the same visual language as the rest of the interface. Treating loading, empty, and error as first-class states in the component schema, with the same design attention as the default state, closes this gap at the source rather than patching it screen by screen after launch. A practical rule: no component ships to production until its loading, empty, and error states exist in the same design file as its default state, reviewed with the same rigor.
## Closing the loop structurally instead of through review comments
None of the fixes above depend on hiring more designers or slowing engineering down with a heavier review process. The common thread is moving the decision from a conversation that happens after a component exists to a constraint enforced before it can ship at all. A design system that only lives in a design tool is documentation. A design system that generates the actual component contract, the actual prop types, and the actual token references a codebase consumes is infrastructure, and infrastructure does not drift the way documentation does, because there is no manual step where drift can enter. This is also why ping-pong reviews between design and engineering rarely close the gap for good, even when both sides are diligent: a review comment fixes one instance of a problem, on one component, in one sprint, and the same category of problem reappears on the next component built by someone who was not in that thread. A shared, machine-readable contract between tokens, variants, and required states fixes the category, not the instance, which is the only version of this fix that actually stops repeating.
## A five-step way to wire it together
None of this requires replacing the design tool or the frontend framework a team already uses. It requires a deliberate sequence, applied one component category at a time.
1. Audit the existing token file against the live codebase and flag every hardcoded value that duplicates or should replace a token, treating each one as a missing token rather than an acceptable exception.
2. Define the full variant matrix for each component, state, size, density, and locale direction, in the component's schema, not in a design file caption, so an unsupported combination cannot be selected in either tool.
3. Add loading, empty, and error to the definition of done for every component that renders data, reviewed with the same visual rigor as the default state before the component is considered finished.
4. Give every translatable and every token-driven prop an explicit source in the schema, so a developer never has a reason to hardcode a value just because the token was hard to find.
5. Route new token requests through a fast path, ideally a same-day pull request, so adding a token is never slower than hardcoding one.
Do these five in order and most of what surfaces as a design review disagreement turns out to have been a missing schema decision all along.
## Where this fits into a broader frontend architecture
We are not trying to replace Figma, Storybook, or whatever component-development environment a design and engineering team already relies on, and a platform that promised to would be solving the wrong problem. What we build under the [Agentic Frontend Management Platform](https://www.laioutr.com/en/agentic-frontend-management-platform) is the layer where a design system's tokens, variants, and required states become the actual contract a live frontend renders from, curated centrally through [Brand Consistency](https://www.laioutr.com/en/product/brand-consistency) and composed visually in the [Composable Visual Page Builder](https://www.laioutr.com/en/composable-visual-page-builder), so a [UX or UI designer](https://www.laioutr.com/en/role/ux-ui-designer) is not stuck waiting for an engineering sprint to see a variant rendered correctly, and a [developer](https://www.laioutr.com/en/role/developer) is not stuck guessing which hex value a design file actually meant. Our [UX and UI Agent](https://www.laioutr.com/en/agent/ux-and-ui) also checks new components against [accessibility requirements](https://www.laioutr.com/en/product/wcag-ready) as part of the same review, so accessibility is not a separate handoff loss on top of the one this article already describes.
## Frequently asked questions
**Does this replace Figma or Storybook?** No. Laioutr sits at the point where a design system's tokens and variants become the actual frontend a user sees, alongside whatever design and documentation tools a team already uses.
**Do we need to redesign our whole design system to fix this?** No. The fixes described here apply one component category at a time, starting with whichever component currently has the most hardcoded values or the most missing states.
**Whose job is it to define which states a component needs?** Whoever owns the component contract, usually a shared decision between design system ownership and frontend engineering, made once when the component is defined, not renegotiated per feature.
**Does closing this gap also improve accessibility?** Often, yes. A component with a properly defined disabled or error state is also easier to make accessible, because the states already exist to attach the right semantics to.
## Next steps
If your team keeps re-litigating the same handoff problem on every new component, [book a 30-minute demo](https://www.laioutr.com/en/pricing). We will look at your token setup and where the schema layer between design and frontend needs to catch up.
## More from the Laioutr platform
- [UX and UI Agent](https://www.laioutr.com/en/agent/ux-and-ui)
- [Composable Visual Page Builder](https://www.laioutr.com/en/composable-visual-page-builder)
- [Brand Consistency](https://www.laioutr.com/en/product/brand-consistency)
- [WCAG Ready](https://www.laioutr.com/en/product/wcag-ready)
- [For UX/UI Designers](https://www.laioutr.com/en/role/ux-ui-designer)
- [For Developers](https://www.laioutr.com/en/role/developer)
**About the author:** Marcel Thiesies is Co-Founder of Laioutr and works on how design systems actually survive contact with a live frontend.
---
Share this article
[Share on Facebook](https://www.facebook.com/sharer/sharer.php?u=https%3A%2F%2Fwww.laioutr.com%2Fen%2Fblog%2Fdesign-system-to-live-frontend-without-handoff-loss-2026) [Share on X](https://x.com/intent/post?url=https%3A%2F%2Fwww.laioutr.com%2Fen%2Fblog%2Fdesign-system-to-live-frontend-without-handoff-loss-2026&text=) [Share on LinkedIn](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fwww.laioutr.com%2Fen%2Fblog%2Fdesign-system-to-live-frontend-without-handoff-loss-2026) [Share on Pinterest](https://pinterest.com/pin/create/button/?url=https%3A%2F%2Fwww.laioutr.com%2Fen%2Fblog%2Fdesign-system-to-live-frontend-without-handoff-loss-2026&description=) [Share via email](mailto:?subject=&body=%0A%0Ahttps%3A%2F%2Fwww.laioutr.com%2Fen%2Fblog%2Fdesign-system-to-live-frontend-without-handoff-loss-2026)
## More interesting articles
Practical know-how for frontend development, smart agents, and headless
[To the blog](https://www.laioutr.com/en/blogs)
[Website Tracking in E-Commerce 2026: An Honest Stack Overview
Website tracking in e-commerce is not one tool but a stack of five layers: consent management, tag m…](https://www.laioutr.com/en/blog/website-tracking-ecommerce-stack-overview-2026)
[One Content Source, Every Channel: Print to Storefront
Re-keying happens when the same product text, specification or image is typed in again for every cha…](https://www.laioutr.com/en/blog/unified-content-source-print-to-storefront-omnichannel-2026)
[Third-Party Cookies Are Not Dead: Why Data Still Has Gaps
Third-party cookies still exist in 2026. Google decided in 2025 not to remove them from Chrome and r…](https://www.laioutr.com/en/blog/third-party-cookies-2026-why-tracking-data-has-gaps)
[Guest Checkout vs. Customer Account: A Frontend Decision to Test
Guest checkout should be the default path in a B2C storefront, and the customer account should be an…](https://www.laioutr.com/en/blog/guest-checkout-vs-customer-account-frontend-testing)
[Google Tag Manager Only With Consent: The Hanover Court Ruling
Google Tag Manager may only be loaded after a visitor has given valid consent. That is the core of a…](https://www.laioutr.com/en/blog/google-tag-manager-consent-vg-hannover-ruling-2026)
[Composable Commerce Agency 2026: Three Offers Instead of One
A composable commerce agency does not win in 2026 with one standard package. It wins with three clea…](https://www.laioutr.com/en/blog/composable-commerce-agency-three-offer-models-2026)
[Algolia in a Composable Frontend: Indexing, Events, Integration
An Algolia integration in a composable frontend consists of three layers that are best planned separ…](https://www.laioutr.com/en/blog/algolia-indexing-events-composable-frontend-2026)
[Discount Campaigns in Online Stores: Black Friday Sale Pages
A discount campaign in an online store works when the goal, the discount mechanic and the campaign p…](https://www.laioutr.com/en/blog/discount-campaigns-online-store-black-friday-sale-pages)
[iPhone Duo and Ecommerce: What Merchants Need to Know Now
iPhone Duo goes on sale on October 23, 2026. Online stores don't need a dedicated app or a custo…](https://www.laioutr.com/en/blog/iphone-duo-ecommerce-foldable-storefront)
[Structured Product Data: How It Shows Up in Your Storefront
Structured product data means every product fact lives in a typed attribute with a unit, a stable id…](https://www.laioutr.com/en/blog/structured-product-data-pim-frontend-2026)
[44% Decide via Trial or PoC: How to Run a Storefront PoC in DACH
In DACH, software decisions are increasingly made hands-on: in the study "Software Buying in DA…](https://www.laioutr.com/en/blog/storefront-proof-of-concept-dach-buyers-2026)
[Frontend Management Platform Comparison: How to Choose the Right FMP
Choosing a frontend management platform (FMP) is less about feature lists and more about where your …](https://www.laioutr.com/en/blog/frontend-management-platform-comparison-how-to-choose-2026)
[DAM, PIM, and CMS Are Converging: What It Means for Your Storefront
DAM, PIM, and CMS vendors are moving into each other's territory, and more teams now evaluate on…](https://www.laioutr.com/en/blog/dam-pim-cms-convergence-content-hub-storefront-2026)
[Contentful Live Preview: What Your Frontend Has to Deliver
Contentful Live Preview lets editors see a draft right next to the entry editor and watch changes ap…](https://www.laioutr.com/en/blog/contentful-live-preview-frontend-perspective-2026)
[Content Governance at Scale: Product Content and Brand Assets
Content governance at scale means that roles, approvals, brand rules, asset rights and translations …](https://www.laioutr.com/en/blog/content-governance-product-content-brand-assets-frontend-2026)
[](https://www.laioutr.com/en/apps/shopify)
Laioutr
[Shopify](https://www.laioutr.com/en/apps/shopify)
Shopify is a commerce platform for selling online and in physical retail.
[](https://www.laioutr.com/en/apps/shopware)
Laioutr
[Shopware](https://www.laioutr.com/en/apps/shopware)
Shopware is a flexible ecommerce platform from Europe for product catalogs and omnichannel commerce.
[](https://www.laioutr.com/en/apps/adobe-commerce)
Laioutr
[Adobe Commerce](https://www.laioutr.com/en/apps/adobe-commerce)
Adobe Commerce is an enterprise commerce platform for complex, global B2C and B2B scenarios.
Planned
[](https://www.laioutr.com/en/apps/b2b-sellers)
Laioutr
[B2Bsellers](https://www.laioutr.com/en/apps/b2b-sellers)
B2B suite for Shopware that turns an online store into a professional B2B commerce platform.
Planned
[](https://www.laioutr.com/en/apps/commerce-layer)
Laioutr
[Commerce Layer](https://www.laioutr.com/en/apps/commerce-layer)
Commerce Layer is a headless commerce platform for making inventory and catalogs available online.
[](https://www.laioutr.com/en/apps/commercetools)
Laioutr
[Commercetools](https://www.laioutr.com/en/apps/commercetools)
Commercetools is a SaaS-based headless ecommerce platform used worldwide.
[](https://www.laioutr.com/en/apps/emporix)
Laioutr
[Emporix](https://www.laioutr.com/en/apps/emporix)
Emporix is a composable, API-first commerce platform for scalable B2B and B2C scenarios.
Planned
[](https://www.laioutr.com/en/apps/hcl-software)
Laioutr
[HCL Software](https://www.laioutr.com/en/apps/hcl-software)
Enterprise suite for digital commerce and experience with extensive configurability.
Planned
[](https://www.laioutr.com/en/apps/intershop)
Laioutr
[Intershop](https://www.laioutr.com/en/apps/intershop)
Enterprise commerce platform for complex B2B and B2C business models.
Planned
[](https://www.laioutr.com/en/apps/magento-2)
Laioutr
[Magento 2](https://www.laioutr.com/en/apps/magento-2)
Widely used, extensible commerce platform for B2C and B2B scenarios.
[](https://www.laioutr.com/en/apps/oxid-eshop)
Laioutr
[OXID eShop](https://www.laioutr.com/en/apps/oxid-eshop)
OXID eShop is an extensible commerce platform for complex B2B and B2C requirements.
Planned
[](https://www.laioutr.com/en/apps/patchworks)
Laioutr
[Patchworks](https://www.laioutr.com/en/apps/patchworks)
Patchworks is a low-code iPaaS that connects ecommerce, ERP, WMS, 3PL, and marketplaces.
Planned
[](https://www.laioutr.com/en/apps/PrestaShop)
Laioutr
[Prestashop](https://www.laioutr.com/en/apps/PrestaShop)
Open-source commerce platform for small and midsize merchants in Europe and beyond.
Planned
[](https://www.laioutr.com/en/apps/saleor)
Laioutr
[Saleor](https://www.laioutr.com/en/apps/saleor)
Open-source, API-first commerce platform built on GraphQL for custom storefronts.
Planned
[](https://www.laioutr.com/en/apps/salesforce-commerce-cloud)
Laioutr
[Salesforce Commerce Cloud](https://www.laioutr.com/en/apps/salesforce-commerce-cloud)
Salesforce Commerce Cloud is a cloud-based enterprise commerce platform for businesses of any size.
Planned
[](https://www.laioutr.com/en/apps/sap-commerce-cloud)
Laioutr
[SAP Commerce Cloud](https://www.laioutr.com/en/apps/sap-commerce-cloud)
Enterprise commerce platform for complex catalogs, pricing models, and omnichannel journeys.
Planned
[](https://www.laioutr.com/en/apps/scayle)
Laioutr
[Scayle](https://www.laioutr.com/en/apps/scayle)
SCAYLE is a commerce engine that helps brands and retailers scale their business.
Planned
[](https://www.laioutr.com/en/apps/spryker)
Laioutr
[Spryker](https://www.laioutr.com/en/apps/spryker)
Composable commerce platform for sophisticated B2B and B2C business models.
[](https://www.laioutr.com/en/apps/sylius)
Laioutr
[Sylius](https://www.laioutr.com/en/apps/sylius)
Sylius is a developer-friendly ecommerce framework for B2C and B2B shopping experiences.
Planned
[](https://www.laioutr.com/en/apps/vendure)
Laioutr
[Vendure](https://www.laioutr.com/en/apps/vendure)
Vendure is a headless commerce platform for businesses with complex requirements.
Coming Soon
[](https://www.laioutr.com/en/apps/vtex)
Laioutr
[VTEX](https://www.laioutr.com/en/apps/vtex)
Cloud-native, composable commerce platform for B2B and B2C at scale.
Planned
[](https://www.laioutr.com/en/apps/websale)
Laioutr
[Websale](https://www.laioutr.com/en/apps/websale)
Stable, enterprise-ready commerce backend for complex retail environments.
Strategy call
## Ready to turn your frontend into a control layer?
Show us your stack, your roadmap, your replatforming scenario, and we'll show you how Laioutr fits, what it costs, and how fast you go live.
*"After 30 minutes, we knew Laioutr makes our replatforming feasible." - Daniel B., CEO,* [*hygibox.de*](https://hygibox.de)
[Book a demo](https://www.laioutr.com/en/contact)
## Structured Data
```json
{
"@context": "https://schema.org",
"@graph": [
{
"@type": "Organization",
"@id": "https://www.laioutr.com/#identity",
"name": "Laioutr",
"legalName": "Laioutr GmbH",
"url": "https://www.laioutr.com/",
"logo": {
"@type": "ImageObject",
"url": "https://www.laioutr.com/laioutr-logo.png",
"width": 400,
"height": 400
},
"email": "info@laioutr.com",
"telephone": "+49 30 75435715",
"address": {
"@type": "PostalAddress",
"streetAddress": "Münchweilersteig 5",
"postalCode": "12559",
"addressLocality": "Berlin",
"addressCountry": "DE"
},
"vatID": "DE450905846",
"sameAs": [
"https://www.linkedin.com/company/laioutr",
"https://www.youtube.com/@Laioutr",
"https://x.com/laioutr"
]
},
{
"@type": "WebSite",
"@id": "https://www.laioutr.com/en/#website",
"url": "https://www.laioutr.com/en/",
"name": "Laioutr",
"inLanguage": "en",
"publisher": {
"@id": "https://www.laioutr.com/#identity"
}
},
{
"@type": "BlogPosting",
"@id": "https://www.laioutr.com/en/blog/design-system-to-live-frontend-without-handoff-loss-2026#article",
"headline": "From Design System to Live Frontend Without Handoff Loss",
"description": "Design tokens turn into hardcoded values, component variants never ship, and states like loading or empty get improvised. Here is how to close the gap.",
"image": [
"https://eu-west-2.graphassets.com/cmii2mlqi0dux06l5543v7nkc/cmtcm1nz96s5406l2mj5y2mry"
],
"datePublished": "2026-08-28T07:09:36.173995+00:00",
"dateModified": "2026-08-28T07:09:35.796819+00:00",
"inLanguage": "en",
"articleSection": "Insights",
"keywords": "Visual Editing, Frontend Management, Content modeling",
"author": {
"@type": "Person",
"name": "Marcel Thiesies",
"jobTitle": "Co-Founder & CEO, Laioutr",
"image": "https://eu-west-2.graphassets.com/cmii2mlqi0dux06l5543v7nkc/cmj01b962364n07lb0iguvts5"
},
"publisher": {
"@id": "https://www.laioutr.com/#identity"
},
"mainEntityOfPage": {
"@id": "https://www.laioutr.com/en/blog/design-system-to-live-frontend-without-handoff-loss-2026#webpage"
},
"isPartOf": {
"@id": "https://www.laioutr.com/en/#website"
}
},
{
"@type": "WebPage",
"@id": "https://www.laioutr.com/en/blog/design-system-to-live-frontend-without-handoff-loss-2026#webpage",
"url": "https://www.laioutr.com/en/blog/design-system-to-live-frontend-without-handoff-loss-2026",
"name": "From Design System to Live Frontend Without Handoff Loss",
"description": "Design tokens turn into hardcoded values, component variants never ship, and states like loading or empty get improvised. Here is how to close the gap.",
"inLanguage": "en",
"isPartOf": {
"@id": "https://www.laioutr.com/en/#website"
},
"breadcrumb": {
"@id": "https://www.laioutr.com/en/blog/design-system-to-live-frontend-without-handoff-loss-2026#breadcrumb"
},
"primaryImageOfPage": {
"@type": "ImageObject",
"url": "https://eu-west-2.graphassets.com/cmii2mlqi0dux06l5543v7nkc/cmtcm1nz96s5406l2mj5y2mry"
},
"datePublished": "2026-08-28T07:09:36.173995+00:00",
"dateModified": "2026-08-28T07:09:35.796819+00:00",
"mainEntity": {
"@id": "https://www.laioutr.com/en/blog/design-system-to-live-frontend-without-handoff-loss-2026#article"
}
},
{
"@type": "BreadcrumbList",
"@id": "https://www.laioutr.com/en/blog/design-system-to-live-frontend-without-handoff-loss-2026#breadcrumb",
"itemListElement": [
{
"@type": "ListItem",
"position": 1,
"name": "Laioutr",
"item": "https://www.laioutr.com/en/"
},
{
"@type": "ListItem",
"position": 2,
"name": "Insights",
"item": "https://www.laioutr.com/en/blogs/insights"
},
{
"@type": "ListItem",
"position": 3,
"name": "From Design System to Live Frontend Without Handoff Loss"
}
]
}
]
}
```