Welcome
This is a blog series about AI-assisted digital design - told as it happened.
A caterer calls with a problem: three canteen locations, 4,500 employees, a contract at risk. Over fourteen episodes, digital designer Kim documents the complete design process of a fictional project - from that first phone call to implementation-ready designs validated by a working prototype.
The twist: Kim works with Claude, an AI assistant, as a genuine design partner. Not as a formatting tool, but as a collaborator - drafting artifacts, simulating stakeholder reactions, checking consistency across documents. The experiment starts with an open question:
Where does AI genuinely help in digital design, and where does it fall short?
The answer turns out to be more nuanced than expected. AI delivers structure, speed, and consistency. But the moments that actually changed the design - a skeptical canteen manager, an unexpected workshop insight, a piece of paper taped to a wall - remained stubbornly human.
Every episode includes concrete artifacts - Design Brief, Solution Design, System Design, Element Designs, a working prototype - and honest reflection on what worked and what didn't. If you're a designer, a student, or simply curious whether AI lives up to the hype: start with Episode 0 for the full context, or jump straight to Episode 1 to see for yourself.
What's New
Series complete — and so is the guideline. All fourteen episodes are published, and the final part of the Working with Design Templates guideline is live — covering the Handover to Development: how to restructure integrated design documents into a navigable wiki, how IDs become the interface between design and development, and how structured specs serve as input for AI coding tools.
The final episode — The Way Forward — covers how demo findings were processed with stakeholders, how Element Designs were updated collaboratively, and how the design artifacts were handed over to a development team via a traceable Confluence structure. Two post-credit scenes show what happened next: the development team's experience with the designs, and the project's long-term outcome fourteen months later.
If you're new, start with Episode 0: Prologue for context, or Episode 1: The Call for Help to jump into the story.
If you've been following along, Episode 13: The Way Forward is the finale.
Episodes
# | Title (Link) | What Happens? | Publication |
|---|---|---|---|
0 | Why this series exists. AI as design partner - what to expect. | Mar 2 | |
Act 1: Scoping | |||
1 | Meier's phone call. Three canteen locations, three different worlds. 40 jobs at stake. | Mar 2 | |
2 | Stakeholder landscape. The works council confrontation. Political complexity revealed. | Mar 9 | |
3 | First design artifact. Problem definition with Claude. Insourcing surfaces. | Mar 16 | |
4 | Go/No-Go meeting. CEO demands alternatives. Technical spike as condition. | Mar 23 | |
5 | Solution Design, Technical Spike, Options Comparison. Three options, one week. | Mar 30 | |
6 | Insourcing analysis - with the works council's help. Worker perspectives: divided, not unified. | Apr 6 | |
Act 2: Concept Development | |||
7 | Steering Committee. App approved. 18-month transformation window. Three non-negotiable conditions. | Apr 13 | |
8 | Solution Design update. Worker validation workshop. A shift worker finds the flexibility gap. | Apr 20 | |
9 | System Design. WiFi problems at Plant North. Terminal strategy splits by location. Two-track evaluation. | Apr 27 | |
Act 3: Development & Operation | |||
10 | Element Designs. Allergen data gap in production. Kitchen Display validation. Pilot plan with rollback. | May 4 | |
11 | Four days, one prototype. Claude Code meets Element Designs. A missing data source surfaces. | May 11 | |
12 | Twenty real lunches. A head chef ignores the design and improves it. A works council chair watches people, not technology. | May 18 | |
13 | Seventeen findings become four updated designs. Handover to development. The conversation ends where it started. | May 25 | |
Templates & Guidelines
The design process in this series is built on a set of templates and guidelines based on the IREB Digital Design Professional (DDP) certification. The process follows three steps: Scoping (understanding the problem and sketching a first vision), Concept Development (exploring and refining the solution through variants and iterations), and Development & Operation (detailing the design and handing it over to development). Within this process, the design works across three layers: Solution Design captures the business perspective - what the solution does for people. System Design defines the architecture - how the solution is built. Element Designs specify each component in detail - use cases, interfaces, technical functions, data models. Traceable IDs connect all layers, from business goals down to entities, making the design systematic and navigable for both designers and developers. For the full methodological background, see the IREB DDP Handbook or Kim’s book Basiswissen Digital Design (German).
Design Templates
Templates define what to produce at each design layer. Each template includes sections, ID conventions, and cross-referencing rules.
Template (Link) | Focus | Content overview |
|---|---|---|
Understand the scope | Problem definition, stakeholders, scope, success criteria, constraints. The project's foundation. | |
Design the over business solution | Vision, value propositions, business entities, processes, scenarios. What the solution does for people. | |
Design the technical system | System architecture, software/hardware elements, interfaces, quality requirements. How the solution is built. | |
Design the particular elements | Detail specification of individual elements - goals, use cases, UIs, technical functions, interfaces, entities. |
Guidelines
The guidelines explains how to work with the templates - from first scoping to handover. It grows alongside the story:
Part (Link) | Available from | Content |
|---|---|---|
Episode 3 | Overview, template relationships, Step 1: Scoping (Design Brief + Solution Design Executive Summaries) | |
Episode 5 | Step 2: Concept Development (Business Refinement, Technical Design, Coordination) | |
Episode 10 | Step 3A: Implementation-Ready Design, Best Practices, Decision Trees, FAQ | |
Episode 13 | Step 3B: Handover to Development (Restructuring, IDs as Handshake Protocol, AI-Assisted Restructuring, Handover Package) |
How Templates and Episodes Connect
The templates aren't abstract - every artifact in the series was built using them. Here's where each template appears in the story:
Template | First Used | Key Episodes |
|---|---|---|
Design Brief | Episode 3 | Created in Ep. 3, approved in Ep. 4, updated to v2.1 with evaluation framework in Ep. 9 |
Solution Design | Episode 5 | Created in Ep. 5, updated with worker validation in Ep. 8 |
System Design | Episode 5 | Created in Ep. 5, updated with Chen review in Ep. 9 |
Element Design | Episode 5 | Created in Ep.5, technical spike for the meal bridge. |
The Design Hierarchy at a Glance
Design Brief - What's the problem? Who's involved? What's in scope?
└─ Solution Design - What does the solution do for people? (Business layer)
└─ System Design - How is the solution built? (Architecture layer)
└─ Element Designs - How does each component work? (Detail layer)
└─ Prototype Specification - What do we build first? (Bridge to code)
└─ Prototype - Does it work with real people? (Validation)Each layer references the one above through traceable IDs: BG → VP → BE → UC → TF → E. A developer can start at any point and trace forward or backward through the entire chain.
Written by Kim Lauenroth with AI assistance by Claude (Anthropic).
Templates and guidelines are free to use with attribution. They are shared as-is - helpful starting points, not guaranteed recipes. Adapt freely, credit kindly.
Feedback, questions, or your own experiences? Contact me on LinkedIn
.