Working Artifact

A working artifact is your design idea, but alive. It is not a picture. It is not a document. It is a functional, interactive version of your concept, something you can click, type into, and see respond. Think of it as a structural draft, a preview deployment, or a code-first design. This is the seismic shift from design as a static blueprint to design as a living, breathing thing that engineers can inspect, integrate, and even ship. With tools like Claude Fable 5, it is often generated directly from a static design, collapsing the design-to-code gap from a chasm to a mere crack. This means the deliverable is no longer an interpretation of your intent, but the intent itself, rendered and interactive. It is the thing that communicates more in ten seconds of interaction than a 47-screen Figma file with redlines and a 30-page spec document ever could. It is the future of design handoff, where "done" means "it works and is inspectable" not "it is documented and approved." This artifact is the tangible output of your judgment, a functional piece of the product that moves the conversation from "what does it look like?" to "how does it behave?" It is the design, in its natural habitat, ready for review by anyone with a browser.

A working artifact is not a static Figma file, no matter how many artboards it contains or how many components you painstakingly built. It is not a PDF spec document filled with annotations, redlines, and arrows pointing to hex codes. It is not a collection of screenshots, nor is it a high-fidelity prototype that only *looks* interactive but has no real code behind it. It is also not a design system documentation site, though it absolutely leverages one. Crucially, it is not a final, fully polished product ready for launch without human review. It is a robust starting point, a structural draft that is functional and inspectable, but still requires the designer's judgment to ensure it meets all requirements, especially those the AI cannot infer. It is not a replacement for human taste, accessibility expertise, or the deep understanding of user needs. It is a tool that takes care of the mechanical translation, the pixel-pushing busywork, leaving the hard, human parts of curation and judgment to you. It will not magically solve your product's problems or make bad ideas good. It is a mirror, reflecting the quality of your input and your system, not a magic wand. It is not a substitute for thinking.

Imagine you are designing a complex checkout flow for an e-commerce giant like Amazon. In the old world, circa 2022, you would spend days in Figma, crafting each state: empty cart, items added, shipping details, payment, confirmation, error states for invalid cards, loading spinners. Then you would add redlines, write a 50-page spec document detailing interactions, edge cases, and accessibility requirements, and finally hold a handoff meeting with engineers who would then spend weeks translating your static vision into code. With a working artifact, that process gets flipped on its head. You design the primary "items added" screen in Figma, ensuring it uses your design system tokens and follows established conventions. You feed that single screenshot to a tool like Claude Fable 5. What comes back is not a picture, but a live React component, or a set of HTML/CSS files, that renders that screen. It has your fonts, your colors, your spacing, all mapped to your system variables. You can then click through it, see the form fields, and even test basic interactions like adding or removing items. This artifact is immediately shareable via a URL, allowing stakeholders to interact with the actual thing, not just a representation.

Another example: a designer at a fast-moving SaaS startup in 2024 needs to quickly validate a new dashboard layout. Instead of building a laborious clickable prototype in Axure or Figma, they use a tool like Bolt.new (as mentioned in the parent article) or even Vercel's AI SDK. They feed a rough sketch or a static Figma frame of the dashboard. The AI generates a working HTML/CSS/JS version. The designer then shares a live URL of this artifact with stakeholders. "Here's the new dashboard. See how the cards resize? This is live, not a video." This is faster, more convincing, and gives engineers a head start by providing a functional, inspectable codebase. It is a functional piece of the product, not just a representation of it. It is the difference between showing a picture of a car and letting someone sit in the driver's seat, turn the key, and feel the engine hum. This immediate feedback loop on a functional piece of the product dramatically shortens iteration cycles and reduces misinterpretations.

You should be reaching for a working artifact when your goal is to communicate interaction, behavior, and functional intent, not just static aesthetics. Use it when you need rapid feedback on how an idea *feels* to use, not just how it *looks*. It is ideal for bridging the design-to-code-gap, especially when you have a well-defined design system and tokens that AI models can leverage for high-quality output. Think of companies like Google or Airbnb with mature design systems; their AI-generated artifacts will be significantly better. Presenting to engineers or product managers? A live URL of a working artifact beats a PDF spec or a static Figma link every single time. It accelerates the handoff process by giving engineers a tangible, inspectable codebase to start from, reducing interpretation errors and rework. It is also excellent for early-stage validation of core functionality, letting you test assumptions with real users on a functional piece of the product, like A/B testing two different navigation patterns in a live environment.

However, a working artifact is not a silver bullet. Do not use it when the design is purely conceptual, meant for broad stylistic exploration, or when you are simply brainstorming without immediate implementation in mind. If the AI tool's output quality is poor, requiring extensive cleanup or manual refactoring, then generating a working artifact might be slower than traditional methods. Avoid it for highly complex, custom interactions that AI struggles to infer from static inputs, like intricate drag-and-drop mechanics, nuanced animation curves, or highly specific data visualizations. Crucially, never treat an AI-generated working artifact as final, production-ready code without thorough human review and testing, especially concerning accessibility. AI still struggles with focus order, ARIA attributes, and complex screen reader flows, often producing only the "obvious" accessibility. If the "working" aspect adds unnecessary overhead for a simple visual decision, like choosing between two shades of blue, stick to a static image. It is about smart application, not blind adoption. Your judgment dictates its utility.

The working artifact is the design itself, alive and inspectable, finally killing the static spec and forcing designers to own the outcome, not just the picture.