Design Systems & AI
Sparkline: AI Workflow Integration
Connecting design, code and AI to shorten delivery on web and iOS
Overview
Sparkline's first product, the bank's account opening application, won Best Digital Account Opening Solution for North America at the 2025 Global Retail Banking Innovation Awards. With the system in production, I tested how AI tools could improve the path from design to delivery, with three goals: more design output, a cleaner handoff to engineering, and shorter delivery for both teams, on every platform the system serves.
The work ran as a loop: build a real product flow with AI, learn where the system fell short, improve the system, then build again, faster, and on a second tech stack.
Open a CD, built from real Sparkline components
Built entirely from the coded Sparkline components and tokens. Try the mobile flow yourself.
Tip: tap Help on any screen to try live chat.
01. Build
A Figma file becomes working code.
From my Figma file, Claude built the full Open a CD journey in Angular: 15 screens from landing page to receipt, with ID capture, bank linking and live chat. Every component is imported from the Sparkline source rather than recreated, so the prototype is real code engineers can build on, and anything the library couldn't do showed up right away.
Design output An interactive prototype built on production components, not a static mockup.
02. Learn
The build showed what the system never wrote down.
Every workaround in the code fell into one of five gaps:
Missing Pieces
Eight parts of the flow had no Sparkline component, including the header, bottom sheet, sticky footer and a compact mobile stepper. Three icons were missing too.
Hidden Defaults
Input is fixed at 213px wide and its right icon can't be clicked, so full-width forms and a show/hide password toggle both needed workarounds in the app.
Inconsistent Bindings
Input works with Angular forms, but Select, Checkbox and Radio don't, and ButtonGroup can't use two-way binding. Each one needs a different pattern.
Missing Exports
Card, Checkbox, Select, Slider and Stepper weren't exported from the library's entry point, so an app couldn't import them the documented way.
Accessibility Holes
Buttons can't be activated with Enter or Space, Input labels aren't linked to their fields, and Switch has no label. An app has to cover all three.
Handoff Each gap is now documented with its workaround, instead of being rediscovered by the next person who hits it.
03. Improve the System
Documentation an agent can act on.
Storybook pages are written for people. I added a USAGE file for each of the 14 components in one fixed structure: when to use it, its real inputs and outputs, known gotchas with their workarounds, and a working example. Two shared guides cover setup and a token reference organized by role. Missing components get a rule instead of a guess: build from existing parts, flag the gap, and let the design system team decide what gets promoted.
The docs live next to the code and publish with Storybook, indexed by an llms.txt file, so any project can point an agent at them. A script rebuilds them with every Storybook build, so they can't drift from the source.
Handoff One source of truth that designers, engineers and agents all read.
View the AI Docs in Storybook04. Build Again
A desktop version from one sentence.
With the docs in place, I asked for a desktop version of the same flow. About 15 minutes later there was a working browser app to review, built from the same components and tokens. None of the five gaps had to be rediscovered: their workarounds were already in the docs. The recordings are unedited.
A strong first draft, not a finished design.
Without layout direction, Claude applied standard desktop patterns while keeping the steps, rates, validation and copy identical to mobile.
Vertical stepper and a live summary
Sparkline's Stepper runs down the left side, and a "Your CD" panel on the right updates the rate, deposit and earnings as you go.
A comparison, not a stack
The five terms become rows, with minimum, maturity date and APY lined up for easy comparison.
Uploads instead of a phone camera
Drag-and-drop ID photos and a webcam selfie, or scan a QR code to finish the photos on your phone.
Modals and drawers
Plaid opens as a dialog, as it does on desktop, and help and live chat slide in from the side instead of a bottom sheet.
Familiar patterns are a starting point; whether they suit these customers is still a design decision. Patterns the library lacks, like the modal and drawer, were built from existing parts and flagged, adding a modal, side drawer, file upload and softer status colors to the roadmap.
Delivery A second platform variant in about 15 minutes, with every new gap flagged for the library.
05. Extend Across Platforms
One system, more than one platform.
Enterprise design systems often need to reach native apps as well as the web. I wanted to see how well AI tooling could extend Sparkline into a native environment, and how closely the result could match the Angular library. iOS was the test platform: working from the same docs, Claude ported the library to SwiftUI, with 14 components, 62 icons and a catalog app, in a day.
The Sparkline catalog, running natively
Recorded in the iPhone simulator. The catalog app is Storybook for iOS: a live playground for every component, with its states, dark mode and text sizes.
<sp-button type="text" label="Back"
[showLeftIcon]="true"
(buttonClick)="goBack()"></sp-button>
<sp-button label="Create login"
[state]="canSubmit ? 'default' : 'disabled'"
(buttonClick)="submit()"></sp-button>SPButton("Back", type: .text,
leftIcon: .arrowLeft) { goBack() }
SPButton("Create login") { submit() }
.disabled(!canSubmit)How closely the two match comes down to three pieces of tooling:
- Generated tokens and icons. Both come from the web source under shared names, so
--color-surface-brandisSPColor.surfaceBrandon iOS. - A parity check. All 86 Angular inputs and outputs map to a Swift parameter with the same name, and a script flags any that drift.
- The same docs and catalog. Each platform gets USAGE files and a live catalog, so agents and engineers work the same way on both.
These are built to carry future changes from the web source to every platform, and none of them is specific to iOS, so the same generators and checks could cover Android next. Building on native iOS controls also closed the accessibility gaps the first build exposed, and the port surfaced a token problem hidden on both platforms that can now be fixed once, in the shared tokens.
Handoff Every platform team gets the same components, names and tokens, kept in sync by tooling rather than manual review.
06. Why It Matters
A faster path from idea to every platform.
This workflow pairs AI tooling with a well-documented design system: AI handles the assembly, while design sets the rules and reviews the output. For an organization, that changes how product work moves.
- Ideas get validated sooner. A working, production-grade prototype can be in front of stakeholders and customers in days, so decisions rest on real experiences instead of static screens.
- Less rework between design and engineering. Prototypes are built from shipping components, so engineering starts from working code rather than rebuilding from a spec, and fewer details get lost in handoff.
- New platforms without starting over. Tokens, icons and component APIs come from one source, so reaching a new platform extends the existing system instead of creating a parallel one.
- Consistency at scale. Shared documentation and automated parity checks keep platforms aligned as the system grows, protecting brand and accessibility standards, which matters most in regulated industries like banking.
- Knowledge that compounds. Every gap a build exposes is documented once and reused by the next designer, engineer or agent, so each project starts further ahead than the last.
The tools do the assembly. The system, the documentation and the judgment behind them are what make the output trustworthy, and that is still design work.