Design and AI
Designing for AI
How should a system express what it doesn’t know? How do we build confidence in automated decisions? How do we prevent harm?
An uncertain suggestion can be useful if it’s easy to check and correct. Even a confident one may need approval if a mistake would be costly. Previews, controls and feedback should reflect that distinction, directing attention where it matters most.
Trust in a process depends on evidence: who or what suggested a change, what informed it, and how it can be checked. Systems should show their working.
When results change between runs, those changes should be visible. Human work should never be silently undone. People should control what automation can access and change, and be able to trace what it did.
As AI takes on more of the work, design must keep asking: where in the loop does the human need to be?
Designing for agents
Designing for agents extends beyond the chat window to the work itself. People need to see what an agent is proposing, what it has already changed, and what is waiting for their approval. Those distinctions should be visible where the work happens, without reconstructing events from a chat history.
Approval needs something concrete to act on: a structured diff showing exactly what will change. Users should be able to accept, adjust or reject proposals, with attention directed towards uncertainty and consequential decisions.
Once changes are applied, the interface should preserve change provenance: what changed, when, and who or what made and approved it. Interrupted tasks, partial success and conflicting human edits need clear paths to recovery.
Autonomy should be scoped to the task and its consequences, with approval gates for consequential actions.
My work on mapping suggestions, auditable corrections and inspectable data pipelines provides a foundation for these challenges: helping people delegate work while retaining meaningful control.
From raw data to production workflow in minutes with AI pipelines
Watch on YouTube
Designing with AI
For complex projects like Quantemplate, I’m an advocate of getting a working imperfect version into users’ hands early. We need to see how the tools work with real data, in a real context. AI shortens this feedback loop dramatically. Code is now a malleable design material that designers can rapidly shape and test.
I built this portfolio with Claude Code. I have a working knowledge of web development, but using AI helped me get something real stood up faster. I could test how something would look, without building a mockup. And I could spend more time thinking about content, interaction and design and less time debugging nested divs.
Aside from Claude, I’ve found Lovable to be a great tool for getting rough prototypes up and working with realistic data in minutes, so we can test interaction patterns. I’m excited about where these tools can take us.
Things I might say to an AI:
Help me prototype this idea so I can try it out.
Suggest some other options for this pattern. What haven’t I thought of?
Run an accessibility audit on this site.
Review this logic. Are there any edge cases or gaps in this approach?
What’s another way we could say this?
Show me current research on identity cues, avatars, and trust.
Challenge this design decision. What’s the strongest argument against it?
In this example I used Lovable to test how users could find and sort datasets designated as ‘data dictionaries’. I explored placing the filter in the sidebar or the top ribbon, and sorting by properties unique to data dictionaries.
The prototype revealed a conflict between dictionary-specific sorting and the main dataset sort setting. I made the dictionary sort behave like a removable filter: users could see when it was active and clear it to return to the main sort order.
Working with realistic data exposed an issue that would have been harder to spot in a conventional click-through prototype.