One screen at a time

At my most recent AI session at Cityblock, I walked the room through a build. I started with three documents: a pilot review, a PRD, and a design-intent document I had written. From those, I used AI to produce wireframes and working prototypes for four new Commons designs.

The room was product managers, designers, operations staff, and behavioral researchers, with a few engineers. I run these sessions monthly. Some months I present; others I host a colleague. The concerns I hear most are that AI hallucinates, that it doesn’t have the right context, and that it gets pointed at problems people are still better at solving.

I agree with parts of each. Here’s what I’ve done about them in my own work.

Show the source

Many of the clinicians I design for start with low trust in three things: AI in general, Cityblock’s data, and the AI tools Cityblock has built.

So in Commons AI, a generated answer carries numbered sources, and a source opens the call note or transcript it came from. A nurse can check the claim before acting on it. More generally, I want every AI surface to be open about its dates, its data sources, and its assumptions. When the answer is right, the user can see why and trust it a little more. When it’s wrong, they can see where it went wrong, and so can we.

Citations don’t fix a model. On the member-research tool where we first shipped them, they did not resolve its broader accuracy and relevance problems. But transparency is how the product earns trust where it’s right, and how we learn where it needs to improve.

Give the agents the system

The second objection, missing context, showed up in our own codebase. Coding agents were building a growing share of Commons, and they weren’t using the design system. Asked for a button, an agent could write its own markup and its own CSS. Each screen looked slightly different, and every hand-rolled copy made the real component harder to change later.

I mapped 59 of Commonplace’s 60 components with Figma Code Connect, wrote guidance for coding agents to reuse the system, and brought the components into Claude Design. That gives agents a path to the production component instead of a new one. Bringing Commonplace into Claude Design also reached past engineering: product managers and operations staff started using Claude Design to make on-brand presentations, documents, and even some admin interface designs, without asking a designer to rebuild the visual language each time.

What I hand over

In the four-design build, AI was useful in four specific ways.

It produced working wireframes quickly, which gave me something concrete to react to and critique.

It generated edge-case scenarios. Thinking through every case a care-team screen has to handle is slow and hard to do completely by hand.

It kept sample data consistent across screens, so I could revise the prototype without updating every screen by hand.

And it quickly produced three or four alternative solutions beyond the ones I brought into the session.

What I keep

I wouldn’t use AI to create an experience from scratch before I have a point of view. Without one, I can’t tell a good output from a plausible one. The model doesn’t understand the people I design for or why they do what they do. That understanding comes from interviews, call shadowing, and watching what people do after launch.

The decisions that matter most stayed with me: what goes where, and what will make the most sense to the person using it. I chose the final walkthrough. In this build, individual screens needed less correction than the transitions between them. I had to shape how the screens connected into a story someone could follow from the first click to the last.