Ansarada AiDA simple survey

Turning assumptions into measurable insight

AiDA is Ansarada’s AI assistant, designed to answer user questions inside the platform.

At the time, we had no clear way of knowing whether those answers were actually helpful.

This project focused on introducing a lightweight feedback loop directly into the product. Something simple enough that people would use it, but structured enough that we could learn from it.

The problem

We were making decisions based on assumptions.

We didn’t know:

• If AiDA’s responses were accurate
• If they were useful in context
• Or how people felt about the answers they were receiving

There was no feedback loop or signals, only guesswork.

The goal

Introduce a way to measure how well AiDA was performing, without disrupting the experience.

It needed to be:

• Fast to respond to
• Easy to understand
• Non-intrusive
• Valuable enough that users would actually engage

The intention wasn’t to design a perfect system upfront. It was to get something live, learn from it, and evolve.

Approach

This was treated as a small but important product experiment.

Rather than overdesigning, the focus was on:

• Speed to validation
• Simplicity of interaction
• Clarity of signal

Start with the moment that matters

Feedback was triggered immediately after AiDA returned a response.

This ensured:

• Context was still fresh
• Users didn’t have to recall their experience
• Feedback felt natural, not forced

Keep the interaction lightweight

• The survey was intentionally minimal.
• A single question with an optional comment field.
• No friction or cognitive load.
• The goal was to make responding feel effortless, not like a task.

Explore how to ask the right question

A surprising amount of the work was in the wording.

We tested variations like:

• How useful was my answer?
• Was my answer accurate?
• Did I answer your question correctly?
• How satisfied are you with my answer?

Through testing, we found that:

• Simpler phrasing performed better
• Open-ended framing allowed for more meaningful feedback
• Overly specific wording biased responses

In the end, we landed on a question that felt clear, neutral and easy to respond to.

Test early, test physically

We ran hallway tests using paper prototypes.

Users were asked to:

• Interact with AiDA in a real scenario
• Respond to the survey immediately after
• Talk through their thinking as they interacted

This helped us understand:

• Whether the question made sense
• How users interpreted the response options
• Where they hesitated or dropped off

Iterate the UI to reduce friction

Several concepts were explored, each refining how visible and intrusive the survey should feel.

Key considerations:

• Should it sit within the response or separate from it?
• How much visual weight should it have?
• Does it compete with the answer itself?

The final direction reduced emphasis:

• Neutral colour palette
• Integrated more subtly into the response area
• Clear but not attention-grabbing

The intent was to support the experience, not interrupt it.

Design for what comes next

While the initial release was simple, we considered how AiDA might evolve.

One concept explored embedding the survey directly into a continuous chat experience, where feedback would stay attached to each response as conversations progressed.

This ensured the solution wouldn’t become redundant as the product matured.

Solution

A lightweight, in-context survey that appears after each AiDA response.

• One clear question
• Optional qualitative input
• Minimal visual disruption
• Built using existing components for speed and consistency
• How we measured success

This wasn’t about perfection, it was about signal.

We tracked:

• Response rate
• Quality of qualitative feedback
• Patterns in sentiment

We reviewed results weekly and synthesised insights using:

• Affinity mapping
• 2×2 prioritisation
• Dot voting with the team

This allowed us to:

• Identify recurring issues
• Prioritise improvements
• Feed insights back into product development
• Outcome

The introduction of this feedback loop gave us something we didn’t have before. Visibility.

We were able to:

• Move from assumptions to evidence
• Understand where AiDA was falling short
• Identify opportunities to improve accuracy and clarity

It also created a repeatable pattern for how we test and learn within the product.

What I learned

Not every problem needs a complex solution.

Sometimes the most valuable thing you can design is a simple mechanism for learning.

This project reinforced the importance of:

• Shipping early to reduce uncertainty
• Designing for real behaviour, not ideal scenarios
• Treating design as a tool for insight, not just output