Where AI earns its place in a design studio, and where it doesn't
An honest account of how we use AI tools in research, copy, prototyping and imagery, the jobs we keep for people, and the four rules we work by.
Every client conversation now includes some version of the same question: how much of this will AI do? The honest answer is that AI tools are in almost every part of our week, and in almost none of our decisions.
That split is the whole point of this essay. We use these tools where they make us faster at work we already know how to judge. We keep them away from the work where judgement is the work. Below is where that line sits for us today, and the rules that hold it in place.
Where it earns its place
First drafts of research synthesis
After a round of interviews we have hours of transcripts and a wall of notes. A language model is good at a first pass: grouping similar statements, pulling every mention of a topic, drafting a summary per participant. It turns a day of sorting into an hour.
It is a draft, though, and it fails in a predictable way. It flattens. The participant who hesitated for ten seconds before answering looks the same in a transcript as one who answered at once, and the tool will happily report a consensus that was really three polite people and one frustrated one. I treat the output as an index into the transcripts, never as the finding.
Copy variants
Microcopy is a good fit: ten ways to phrase an empty state, shorter versions of an onboarding line, a button label in a tone that matches the rest of the app. Generating options is cheap, and a writer or designer picks, edits and checks the result against the product's voice. What ships is still written by a person, even when the starting point came from a tool.
Realistic fake data and edge cases
This is one of the most useful jobs and one of the least talked about. Designs built on "Jane Doe" and perfect profile photos lie about the product. We use AI tools to generate realistic test content: long German compound names, addresses with three lines, product titles that wrap to four lines, reviews in five languages, a user with no photo and an empty history.
Fake data like this finds layout bugs before a developer does, and it stops a design from quietly assuming that every user looks like the team. It also means no real customer data ends up in a Figma file.
Code-based prototyping
Our prototypes increasingly run as real code rather than as linked frames. AI coding assistants make that fast: a working list with real scrolling, a form with live validation, a chart that takes a dataset. A prototype that behaves like the product gets better feedback in testing than a click-through, and it gives engineers something concrete to argue with.
The prototype is still not production code. We review it the way we would review a junior developer's spike: useful for learning, rewritten before it ships.
Accessibility audits, as a first pass
Automated checkers, some now with AI on top, catch a real share of accessibility issues: missing labels, low contrast pairs, small touch targets, images without text alternatives. We run them early and often. But the W3C is clear that tools cannot check everything and some checks need a person. A tool can tell you a button has a label; it cannot tell you that the label makes sense when VoiceOver reads it in the middle of a checkout.
Imagery for moodboards and covers
Image generation is good at exploring a visual direction quickly: twenty takes on a mood before we commit to a photographer or illustrator, or a texture study for a brand. The cover images on this Journal are AI-generated and art-directed by us. We write the brief, choose and reject, and edit, and we label them as generated in the credit line.
Where it doesn't
- Taste. A tool can produce a hundred options. Knowing which one is right for this product, this audience and this moment is the job clients pay for, and it does not average out of a training set.
- Deciding what to build. Prioritisation depends on business context, constraints and trade-offs that live in conversations, not documents. A model can list options; it cannot own the consequences.
- Final copy without review. Generated text is fluent, which makes its errors easy to miss: a wrong legal term, an invented feature, a tone that is subtly off. Nothing user-facing ships without a person reading it in context.
- User research with real people. So-called synthetic users can help with desk research and preparing a study, but Nielsen Norman Group's review found their answers too shallow and too agreeable to replace real participants. We use them to sharpen our questions, never to answer them.
- Accessibility sign-off. Conformance is a claim someone has to stand behind. It needs manual testing with screen readers and, ideally, involving disabled users in evaluation.
We use AI where we can judge the output faster than we could make it. Where we can't judge it, we don't use it.
Our four rules
These are the rules every person at Ainur works by. They are short on purpose, so they are easy to apply in the middle of a busy day.
| Rule | What it means in practice |
|---|---|
| Humans own decisions | Every design decision, recommendation and shipped string has a named person behind it. "The tool suggested it" is never the reason. |
| Disclose generated imagery | Images made with generative tools are labelled as such wherever they are published, including covers, case studies and pitches. |
| No client confidential data in tools without agreement | We do not paste client documents, user data, unreleased designs or code into third-party AI tools unless the client has agreed to that tool and its data terms. |
| Verify every fact | Dates, numbers, quotes, standards, API names: if it came from a model, it gets checked against a primary source before it reaches a client or a reader. |
The third rule causes the most practical friction, and that is intended. Before a project starts we agree with the client which tools may be used on their material and under which data terms. Where the answer is none, we work without them. It costs some speed, and it is the client's call to make.
The fourth rule shaped this Journal. Every article here is checked against official sources, from W3C and EUR-Lex to Apple and Android documentation, and the sources are listed at the end. If a fact could not be verified, it was cut.
What this means if you hire a studio
Ask the studio three questions. Which tools touch our material, and under what data terms? Who reviews generated output before we see it? What do you never use AI for? Clear answers to those tell you more than any claim about speed.
For us, the answer to the last question is simple. AI helps us make more things to judge. It does not do the judging.
