Your design team and its first AI product

Most organisations building their first AI product already have designers. They know the users, the product, the brand and the internal politics, and they have shipped software that people use. When the AI product comes along, the question is whether to give it to them, hire somebody new or bring in outside help. The most common answer, outsourcing “the AI part”, is the one that tends to work worst.

What transfers and what does not

Most of a good designer’s craft applies unchanged: research with real users, information architecture, visual clarity, attention to the moment a person has to decide something. What does not transfer is the assumption underneath conventional interface design — that the system is correct and the user is the one who might make a mistake.

An AI component inverts that. It is fast, usually right and sometimes wrong, and the interface has to make checking cheap, doubt obvious and error safe. That takes a handful of things nobody needed before.

Showing uncertainty without a number. Marking the fields the system was unsure about and saying what it could not answer, rather than attaching a percentage that users will read as precision.

Evidence next to the claim. What the answer rests on, within one click, because that is what makes review fast.

Correction paths. How a person fixes a wrong output without redoing the whole thing, and where that correction goes.

Testing with wrong answers. Prototypes with realistic errors in them, and test sessions that measure review time and missed errors rather than satisfaction.

None of this is difficult once seen. It is simply not in the portfolio of somebody whose software has always been right.

Infographic

What transfers from conventional design

Visual designInformation architectureResearch with usersReview-first layoutsCorrection pathsShowing uncertainty

Transfers as isNew with AI

Why outsourcing the AI part fails

The tempting arrangement is for the in-house team to design the product and a specialist to design “the AI screens”. The result is two design languages in one product, and a seam exactly where the user most needs consistency: the moment the system hands something to a person.

It also leaves the in-house team unable to maintain what was designed. The next feature arrives, the specialist has gone, and the team designs it the conventional way, because that is the language it has.

An arrangement that works

Pair on the first workflow. Your designers and the specialist design it together, from watching the current task to testing the prototype. Your team leads on the product; the specialist leads on the uncertainty.

Your team leads the second. The specialist reviews rather than designs. This is where the language either sticks or does not, and it is the cheapest point at which to find out.

Write the patterns down as you go. How this product shows sources, marks doubt, handles refusal and accepts corrections: a short, specific set of decisions, not a general guide. That document is what lets the third workflow be designed without anybody from outside.

What it costs you in time and attention

Pairing only works if your designers are allocated to it rather than fitting it around other work. An interaction model and a tested prototype for one workflow is typically three to five weeks. Add access to people who do the job for test sessions, and a product owner who can make decisions within days rather than at the next steering committee.

The less obvious cost is the willingness of an experienced team to be beginners at one thing for a few weeks. Teams that manage it come out with a new capability. Teams that do not tend to treat the specialist as a supplier of screens, which is outsourcing again by another route.

What a good outcome looks like

Your team can explain, in its own words, why a particular screen shows sources where it does and marks doubt the way it does. The second workflow was designed mostly without help. The patterns are written down, short and specific to your product. And for the next workflow, the outside help is visibly no longer needed.

How we work with design teams

Working alongside an existing design team is often the best arrangement for AI-native apps design. Your team knows your product and your users; we add the design language for uncertainty, which is genuinely new work. And where what you need is a visual refresh rather than this, we will say so.