Klaudia Skiba - Product Designer

ROLE AND TEAM:

Product Designer

TIMELINE:

July-August 2026

SKILLS:

Built with Claude Code Animation with Figma Make Iteration with Claude Design User Interviews Visual Design Design System

PROBLEM:

Designers often don't go through a proper planning stage before entering Figma, which leads to missing edge cases, states and unhappy paths and revisions during implementations, resulting in delays and inconsistency.

ROLE AND TEAM:

Product Designer

TIMELINE:

July-August 2026

SKILLS:

Built with Claude Code Animation with Figma Make Iteration with Claude Design User Interviews Visual Design Design System

PROBLEM:

Try it yourself

Why the project existed?

Designers ship what they can see on a static screen. What they can't see, a payment that fails after checkout, a session that times out mid-form, a connection that drops, stays invisible until someone else finds it: engineering during implementation, QA during testing, or a user in production.

The idea came to me at a moment where I wanted to test and build a real end-to-end AI-assisted workflow to test, ideate, prototype, and build, moving deliberately between Figma and Claude Code for both the application and its design system.

Why does it matter?

A missed state doesn't just cost a redesign, it costs the time already spent: re-opening a brief that had moved on, re-learning its context, then reworking screens against a live sprint instead of an open one. That delay doesn't stay contained to design, it pushes the ship date behind it. The prize isn't a nicer flow, it's not having this conversation after the code is already written. This isn't specific to any one team or company. Four separate r/UXDesign threads asked some version of "how do you find edge cases before they find you" across five years, from 39 votes and 19 comments down to 2, the question keeps recurring regardless of who's asking or where they work.

What was the problem?

The problem above had been true for a long time before I did anything about it. What tipped it into an actual project was hitting the same wall enough times myself: designs revisited mid-implementation because something was missing, and worse, sometimes only caught after a user hit it in production. That's what sent me looking for a real fix rather than another personal checklist, into OOUX and Event Storming specifically.

Design decisions

Decision 1: Scope

Interviews shed a different light on the root cause.

The root cause was partly a poor brief - designers felt tempted to jump straight to Figma, because the brief seemed simple.

Solving that meant a different, broader product.

I chose to bound the problem to the action↔state mismatch, keeping the scope narrow and focused.

Decision 2: Representation

discarded

Journey grid as the spine

Every column then reads as a complete unit (who, what, which transition, what else could happen), and the count of dashed cells is the number of screens still to design.

Object cards carry the actor

Denser and scroll-free; weaker to know the order of transitions, which the flat list doesn't give.

selected

By-actor map with actions

Columns are still steps in time, but an action block sits in its actor's lane, so the actor is read from position and the handoff between designer and system is a visible gap in the row.

Each block clearly links an action to objects

The Nobody lane holds transitions no actor causes(timeout, connection loss) which neither of our versions had a home for.

Decision 3: Deliverable

Additional deliverable

Initially, the deliverable was supposed to be a map of the whole system. During early feedback users mentioned a gap between understanding the system and actually getting to design it.

"will it be something I can follow in Figma?"

Reflections

Intentionally leaving out part of the root cause

I could see that the brief itself was half the problem, and I chose not to touch it, because a tool that tries to fix everything upstream fixes nothing well. I prioritised deliverables understanding my deadlines and capabilities.

No outside push

Flowprint taught me resilience and follow-through under uncertainty. It's a self-initiated project, currently launched as MVP. There was no external signal to keep going and it being in an unfinished state pushed me to decide what good enough is. The good enough was launched - otherwise I'd fall into the common trap of constant iteration.

Formalising the process

Building a tool to formalise my own design thinking taught me how much of my process I'd never actually put into words. Something that made sense in my head didn't necessarily when I translated it into a map.

Understanding AI failure mode

I learned to treat AI output as a draft to be QA'd rather than an answer. Every answer and production requires judgement, and its strength is in divergent exploration and stress-testing my assumptions, not for the convergent decision.