Principles for Responsible AI Integration in Design

Most AI features don't fail in the middle. They fail at the edges, when the answer is wrong and the person using it can't tell. Responsible AI design is mostly about that moment.

This is how we approach it on client work. It isn't a list of values. It's what we actually check, build and test.

What does responsible AI integration mean?

It means three things you can check. People know when AI is involved. People can see, or at least question, how it reached its answer. And people can take back control when it gets it wrong. If a feature fails any of those three, it isn't ready, however clever the model is.

Start with the job, not the model

Our approach is human-led and AI-augmented. Before anyone picks a tool, we study the task itself. What does the person do today? Where does their judgement matter? Where is the work pure drudgery?

AI goes into the drudgery first. Summarising, sorting, drafting, checking. The judgement stays with the person, and the design makes that split obvious to them.

Design the wrong answer first

Most teams design the happy path and treat errors as edge cases. With AI, errors aren't edge cases. They're a normal part of how it works.

So we design the failure states before the success state. What does the screen show when the AI isn't sure? How does someone check where an answer came from? How do they undo it, correct it, or reach a human? If those moments are clear, people trust the feature even when it's imperfect. If they aren't, one bad answer can end the relationship.

Know what the machine sees

AI features are increasingly bought in, not built. That brings a different set of questions. Before a client put an AI assistant on its website, we asked the vendor things like:

• What actually renders on the page, and can our design system reach it?
• What does a search engine, or another AI, see when it reads the page?
• What does it cost in page speed?
• Can we design the experience, or only change its colours?

The answers decided whether we were designing a service or decorating someone else's product. Ask them before you sign, not after.

Test with the people most likely to be let down

Bias rarely shows up when you test with confident, tech-savvy users. It shows up with people who have lower digital literacy, speak English as a second language, are older, or use assistive technology.

So we recruit those people on purpose, and we test against accessibility standards (WCAG 2.2) from the first prototype, not at the end.

Keep a record

Write down what data the feature uses, what it's allowed to decide, what it isn't, and who signed off. In regulated sectors, that record is what you show an auditor. Everywhere else, it's what you'll need the first time something goes wrong.

What good looks like

• People can tell when they're dealing with AI, in plain words.
• Every AI answer has a visible way to check it, change it or escalate it.
• It was tested with the people most likely to be let down.
• There's a written record of what it does and who approved it.
• It saves time without quietly lowering the quality of the work.

If you're choosing someone to help with this, we've written the questions we'd ask a partner, and what good answers sound like.

Related: Innovation coaching and Our approach.