Meryem Ghatrif
Meryem Ghatrif

Contents

ghatrif.meriem@gmail.com

Pensées · Agile & AI

Agile UX that works, and where AI fits

Where UX fits in a sprint, four ideas that make agile UX work, and where AI helps without taking over.

6 min read

The sprint demo goes well. The new booking form works, the team is pleased, and it goes live on Friday. On Monday, the first real customer can’t find the button to send it.

Nobody did anything wrong. The team built exactly what it had planned, without ever watching a customer try it.

When UX is pushed aside in an agile team, decisions are made without users, and the team simply ships its guesses faster. When it works, research and testing happen before and during each sprint, and everyone stays close to real people. None of this needs a big team: it applies just as well to a small business and the people building its website.

Agile itself began in 2001 with a short manifesto whose first value still reads: “Individuals and interactions over processes and tools.” I took the Interaction Design Foundation’s course Agile Methods for UX Design, with Laura Klein, Teresa Torres and Adam Thomas. Here is where UX fits in a sprint, four ideas from the course that stayed with me, and where AI fits in.

Where UX fits in a sprint

The course puts research and testing before and during each sprint. In practice, I would give every sprint three UX moments.

  • Before the sprint. Research and sketch the work of the next sprint, so the team never starts from a guess. Talk to a few customers, and turn what you learn into user stories.
  • During the sprint. Test the work in progress with a few people as soon as there is something to click. A paper sketch counts.
  • At the review. Show what users did, not only what the team built. Then decide together what changes in the next sprint.

A short test in every sprint teaches more than a big study once a year.

Bring the team, and the users, into research

Research is not a report you hand over at the end. Invite developers, product owners and stakeholders to watch or join interviews early on. They will own what they saw, you will spend less time explaining it, and the solutions you reach together will be ones the team can actually build.

Listen to the ideas they bring you, too. Behind every suggestion there is a motivation, such as a concern about performance, a request from a client or a lesson from a past project. Understand the motivation first, and deciding what to pursue becomes much easier.

And bring users in early, before the ideas harden. In co-design sessions, customers take part in brainstorming and sketching themselves, which helps you avoid a polished answer to the wrong question.

Show your work before it is finished

Share sketches, prototypes and rough concepts with the team, often. Early feedback costs little and can save a whole sprint, and decisions come faster when everyone has seen the same thing.

Before you prepare a deliverable, ask two questions. Who is it for, and what should they do once they have seen it? A developer and a product owner do not need the same document.

Align on one page

Well-run agile teams have one thing in common: alignment. A simple tool for it is the initiative document, written together before the work starts and kept to a single page.

Initiative documentOne page

Abstract
What are we trying to achieve, and for whom? Short enough for anyone to read and repeat.
Objectives
How does it tie into the product strategy? If it doesn’t, stop here.
Success / survival
What do success and failure look like? When do we pull the plug, keep going or double down?
Resources
Who does what, who decides, and who needs to stay aware?
Time horizon
How long will it take, and when can people expect answers?

“Remember, the goal is one page. Keep cutting until you get there.”

Adapted from the Interaction Design Foundation’s Initiative Document template, developed by Adam Thomas. Shared under CC BY-SA 4.0.

Inside the sprint, user stories keep that alignment alive. The classic form fits on a sticky note: “As a [type of user], I want [an action] so that [a benefit].” For a law firm’s website, that might be “As a business owner looking for a lawyer, I want to see what each partner specialises in, so that I contact the right one.” Designers and developers then share the same picture of who it is for and why it matters.

A roadmap in three columns

When people hear “roadmap”, many picture a Gantt chart, with tasks on a timeline. In agile teams, where requirements change often, that format soon breaks. Instead, treat the roadmap as a draft of your strategy that the team can question. Share it early, listen, and revise it often.

Start from the organisation’s goals, find the problems most worth solving, and sort them into three columns: Now, Next and Later. Describe the outcomes you hope for rather than a list of tasks, and keep it simple enough for anyone to read; a client may need one line per column, the team more detail.

  1. Nowin bloom

    Objective

    In development

    • Experiment 1, validated
    • Experiment 2, invalidated
    • Experiment 3, still running

    Objective

    In prototype

  2. Nextin bud

    Objective

    The most confident bet for the next opening

  3. Laterin seed

    Objective

    Six months or more away, checked against the vision

Adapted from the Interaction Design Foundation’s Product Roadmap template; the Now / Next / Later format was created by Janna Bastow. Shared under CC BY-SA 4.0.

And when someone asks for a date, split the release in two: a soft launch, a first version before the official release, and a hard launch, the final one. Marketing can then plan its work without waiting for every estimate to settle.

Where AI fits

AI makes the making faster: first drafts of interview guides, hypotheses and user stories, variants of copy, quick prototypes, clusters of notes. A sprint can now hold more drafts than ever, and that is good news for small teams.

But it does not do the learning for you. In 2024, Nielsen Norman Group compared AI-generated “synthetic users” with real ones. Asked about online courses, the synthetic learners said they had finished all of them; many real learners had not. The researchers’ verdict was plain: “Real user research is essential.”

Nor does it take the responsibility off your hands. In 2024, a Canadian tribunal ordered Air Canada to compensate a passenger misled by the chatbot on its website. The airline, it ruled, is responsible for all the information on its site, and it makes no difference “whether the information comes from a static page or a chatbot”. If your project includes a chatbot, here are six steps to design it.

And what you paste leaves the room. Interview notes usually contain personal data, protected by the GDPR in Europe and by law 09-08 in Morocco, and replacing a name with “Participant 3” does not make them anonymous. Someone who agreed to talk to a designer did not agree to talk to a server.

Delegate, then review: first drafts, variants, notes that are already anonymised, quick prototypes.

Keep human: talking to users, choosing what to build and what not to, answering for what an AI feature tells your customers, accessibility checks with real people.

Never paste: passwords and keys, anything a client shared in confidence, anything that identifies a participant, sensitive data such as health or religion.

Look closer

Nothing in my garden grows faster because I check on it more often; what changes is what I notice.

A good sprint is the same. The fine dark lines on a heartsease lead a visitor to its heart; every draft, every prototype, every clever summary should lead back to a person. AI can widen the view. The loupe stays in our hands.

If you try one of these ideas in your next sprint, I’d be glad to hear how it went.

Sources (6)