Context

Design decisions often involve competing needs, incomplete evidence and patterns that work well in one context but poorly in another. In my own practice, I’d seen how easily familiar examples could become convincing justifications without enough scrutiny.

I wanted to explore whether a focused AI tool could help designers work through those decisions with the challenge and perspective of an experienced design partner.

The project was also an opportunity to develop practical experience with Claude Code: taking an ambiguous idea through product direction, interaction design, brand and implementation.

My contribution

I led the product concept, interaction design, brand direction, evaluation and release decisions.

I used ChatGPT to develop and challenge ideas, refine prompts and prepare implementation briefs. Claude Code, running inside VS Code, implemented and revised the application. I directed the work, reviewed the experience and decided what to change.

This meant working directly with an implemented product, evaluating both the interface and the reasoning it produced.

Key work

Understanding the problem before recommending a pattern

The first approach combined a curated knowledge base with structured answers. It produced organised responses, but testing exposed a weakness: the available guidance could dominate the recommendation.

After supplying guidance on filtering patterns, I saw the tool suggest filtering-led solutions for problems where filtering was only tangentially relevant. It could justify an approach without sufficiently examining whether it addressed the problem.

I tested different scenarios, refined the instructions and repeatedly compared the results with a design-partner master prompt. Those comparisons led me to change direction.

I removed the curated knowledge base from the live response path and simplified the experience around conversation. The emphasis shifted towards understanding context, identifying consequential decisions, challenging assumptions and exploring trade-offs. Designers could then question the advice and introduce new information as their understanding developed.

Recognising where prompting wasn’t enough

Real interface examples were an important part of the concept. I wanted designers to understand how an interaction worked elsewhere and judge what might transfer to their situation.

The initial approach searched web pages and attempted to extract relevant images. Repeated failures revealed a capability gap: relevant written guidance did not necessarily contain useful screenshots. More detailed instructions could not supply the missing material.

I introduced a dedicated image-search integration and refined how candidates were selected. Broader interaction patterns and partial analogies proved more useful than searching for an exact match to an imagined interface.

My review also exposed weak precedents: an image could look relevant without demonstrating the behaviour being discussed. Visual references remained uneven, making this an ongoing area for improvement.

Making serious thinking approachable

I developed the identity around “serious thinking × playful objects”: a restrained interface paired with tactile sculptural forms representing complexity, investigation, alternatives and direction.

The objects gave abstract ideas a recognisable form, while typography, spacing and reading hierarchy kept the answers central.

I refined the homepage and conversation together, including problem entry, waiting states, answer navigation and copying content into other work. Working in code allowed me to review these behaviours as part of the experience and direct further changes.

Testing the experience without an introduction

I observed six people using the product on their own problems: three designers, a user researcher, a service designer and a product manager. I gave them no introductory explanation and discussed the experience with them afterwards.

Participants initially struggled to understand what the product offered. They also wanted a quick way to assess its value before spending time describing a problem.

Feedback on the results was positive. Participants valued being able to interrogate the advice conversationally, and one introduced new stakeholder information while working through the response.

These sessions informed the next iteration: clearer proposition copy and a labelled, prepared example that visitors can explore without writing a prompt or triggering paid API calls.

Outcomes

An implemented beta

I took the concept into a deployed beta using Claude Code, gaining practical experience of directing AI-assisted implementation and working through the constraints of a public service.

Deployment introduced considerations beyond the interface, including API authentication, usage limits and cost controls.

Early evidence for the conversational direction

The exploratory sessions provided encouraging feedback on the answers and the ability to ask further questions as a problem developed.

They also exposed a clear weakness in the first-use experience. The next iteration focuses on helping visitors understand the offer and see its value sooner.

A repeatable way of working with AI

I developed a working loop of framing, briefing, implementation, critique and verification. Prompts and implementation briefs became reusable artefacts, with explicit behaviours, constraints and review criteria.

The value came from evaluating the result and directing the next change, alongside generating the initial work.

Reflection

The most useful learning was recognising when a plausible, well-presented answer was poorly matched to the problem. Evaluating contextual relevance became as important as refining the interface.

Building with AI gave me a more direct way to explore product decisions in code. It also made my responsibility for judgement clearer: deciding what deserved to be built, recognising weak results and knowing what still needed investigation.