zigzag AI Design Sprint

AI Design Sprint

The Challenge

Your problem isn’t the ideas.

The pressure is real and the starting point isn’t obvious. Everyone agrees AI matters. Nobody agrees on where it matters for you. So the question goes into workshops, task forces and strategy decks, and comes back out as a longer list of possibilities. People start experimenting on their own. Six months in, everyone is busy and nobody can say what it adds up to.

Your competitor has access to the same efficiency.

Most AI programs point inward: summarize the meeting, draft the email, clean up the spreadsheet. Useful, and it makes the quarter look better. But the question is: what does AI do to the thing you actually sell? Does your product get more valuable? More capable? Harder to replace? Every competitor has access to the same efficiency. The product is the part that’s yours.

The Sprint

The AI Design Sprint brings the people who know your product and your customers together for one day, to find where AI adds the most and to build it.

The format is documented in “AI Design Sprints: Facilitating AI Innovation within Cross-functional Industry Teams”, a paper at the 2026 Designing Interactive Systems Conference, co-authored by zigzag’s Dennis Knopf and colleagues with researchers from Carnegie Mellon. By the end of day, you have:

A Problem Worth Solving

The point in your user journey where the pain or the upside is greatest — identified by your own people, agreed on by the ones who’ll have to live with it.

A Ranked Backlog of Ideas

Everything your team generated, captured and prioritized.

Prototypes

Real code, running in your browser by the end of the day. Your domain, your design system, and none of your material goes to a public AI service.

A Decision, Not a Follow-Up

Results are synthesized as the day runs, so next steps get agreed while everyone’s still in the room, rather than negotiated over email three weeks later.

Something to Show Upward

Continuing usually needs a budget decision. You’ll have a working prototype and the reasoning behind it, which is a different conversation than a slide deck.

The Day

TBD

You mark where it hurts.

Your team walks through the user journey it lives with every day and marks the points that cost the most time, money or patience.

You see what AI can do right now.

A working session on current capabilities, hands on the material. By the end of it everyone in the room shares the same picture of what’s realistic.

You come up with ideas and pick one.

Everyone generates against that problem, the ideas get shared and ranked, and the team agrees on what’s worth building the same day.

You build it and look at it.

We build it in code with you and it runs in your browser. Then you try it, break it, and decide what should happen next.

We close with a round on what everyone is taking away.

Next steps get decided on the spot, while the day’s momentum is still in the room.

TBD

Why It Works

A tango of human judgment and AI velocity

Design sprints have been around for a decade. We moved the slow parts before the workshop, onto our side. What’s left is one day that runs on live AI assistance and produces tangible results while the people who decide what happens next are still in the room.

We arrive knowing your domain

Before the workshop we build a private knowledge base from your material: project documentation, call transcripts, past presentations, with a glossary for your terminology. We tune it until answers come back grounded in the right documents. The room starts from your context instead of spending the morning explaining it.

ziggie sits in the session

Our own local AI assistant is connected to the workshop board, so it reads what the room produces as it happens and queries it against everything it already knows about your business. Pain points get checked against what people said in past interviews. Ideas get compared to what’s been tried. The synthesis happens live, during the workshop.

The expertise is yours

We facilitate, we handle the tooling, we make sure the day produces something. What your users need, where the constraints sit, what the business can actually absorb: that comes from your people, and it’s the part nobody can prepare in advance.

Prototypes, Built in Your Design Language

We build and maintain design systems for a living, and we work on how AI tooling behaves inside them. That’s what makes a prototype your management recognizes immediately. Before your sprint we set up a scaffold from your design tokens and components, so every prototype starts inside your visual language rather than in the default look of whatever model built it.

Data Security

Two kinds of data, two different paths

TISAX, ISO

What stays with us

Your documentation, transcripts and project knowledge. They go into our own local AI model, on hardware we own, in our own office. Nothing of it is sent to any external AI service at any time. Our office and servers are TISAX-assessed.

What leaves, and how

Prompts for building the prototypes. We use a commercial coding model for this, because no local model matches it yet. Every prompt passes through our local assistant first, which removes customer names, part numbers and pricing. The model sees the shape of the problem, not your business. If your organization hasn’t cleared AI coding tools, that doesn’t stop the day — we work on our machines and our licences.

The Setup

Around eight people works well

What matters more than the count is the mix: people who know what your customers struggle with, people who know what your systems can and can’t do, and someone senior enough to act on what comes out of the day.

No AI experience needed

Some teams arrive having barely touched it, others already have people building. The day starts from your problems rather than from the technology, so both work.

On-site or across time zones

We’ve run this with everyone in one room and with groups spread across four locations and two continents. Remote participants build alongside everyone else.