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?

Checking validation errors — animated gradient cube with shimmering text.
Quantemplate Agent thinking state
Lower confidence mapping suggestions are highlighted yellow for user review. See Column Mapping case study.

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.

Quantemplate's agent panel over a data table. A user asks it to correct the invalid zip codes; it replies that it added leading zeros to 12 values and links to review the changes. In the table behind, each corrected zip code is marked with a small cube icon. The user then asks it to change 2907 back, and the agent starts reverting that correction.
Agent-proposed changes are marked in context with the cube motif, so users can inspect and approve them before they take effect.

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?

A 10-minute prototype made in Lovable to test and refine some interactions. It doesn’t look exactly like Quantemplate, but at this stage, it doesn’t have to.
Prototyping example

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.


Back to top