The New Whiteboarding

The slow part was never the drawing

Designers are a shared resource. Their time belongs on brand and product, and concept work for a new screen has to wait its turn in the queue.

When it finally gets a slot, the process looks the same almost everywhere. Product explains what the feature needs. The designer walks away, works on it, and comes back. Then comes the back-and-forth: that’s not quite it, this card should show something else, what happens when the session is over? Every round waits on two busy calendars lining up.

I used to think of that as design time. It isn’t. Most of it is translation time, the cost of describing a screen in words and waiting for someone else to interpret them.

One homepage, six states, two hours

The homepage our end users land on had a lot to carry. The same set of cards had to hold up across six different session states, each changing what the user needed to see and do.

Explaining that in a spec is hard. Drawing it by hand is slow. I’d estimate a designer would have spent about three days on it once you count the back-and-forth.

I built it with AI in about two hours. It wasn’t a sketch. It was a clickable prototype where you could move through all six states and see how each card behaved in each one. It was built to start conversations and plan the real design, and every screen used illustrative data.

What users saw that a spec never would

Because the prototype existed, end users saw the homepage about a week sooner than they would have through the normal design process.

Their feedback was specific. We had the right cards and the right data on the page. What we didn’t have was the right layout. A card sitting in prime space turned out to matter less to users than we had assumed, so the layout changed before real design work started.

A written spec would never have caught that. It would have listed the right cards and passed every review, because the problem wasn’t what was on the page. It was where things sat. Nobody sees that in a requirements document. Users see it in seconds on a screen.

Then the designer started from my file instead of a blank page. We weren’t beginning with an explanation and a wait. We were beginning with something already tested against users.

The same pattern, with bigger savings

I used the same approach on an analytics dashboard, where the savings showed up on the calendar and not just in build hours. Getting a design and the feedback we needed usually took about a month. With an AI-built prototype in front of people first, it took about a week.

I used it again on a scheduling view.

The homepage shows that the build gets faster. The dashboard shows that the whole loop gets shorter. The second one is the bigger deal.

Where AI stops

The prototype is a way to have the conversation. It is not the product.

Every screen used illustrative data, and everyone who saw it knew they were looking at a concept. What the prototype settles is whether the idea holds and where things belong. What it doesn’t settle is the final visual design, the interaction details, and how the whole thing fits the brand. That work still belongs to the designer, and it got better because they started from something real.

This doesn’t replace design. It protects it. The designer’s time goes to the work only a designer can do, instead of translating a product manager’s description into a first draft.