Designing an AI assistant treasury teams can trust

From interviews to a live product

1. 01

   Listen

   Before the workshop

   15 user interviews with treasury managers and heads of treasury, research synthesis and first insights.

2. 02

   Frame

   2–5 June 2025

   Four days with TIS, AWS and customer experts. Persona, empathy map, problem statement, How Might We and success metrics.

3. 03

   Design

   After the workshop

   Trust patterns, rapid prototyping in Lovable, final designs in Figma and Figma Make.

4. 04

   Launch

   AWS Marketplace

   The assistant goes live and I collect feedback from real users.

Problem

Treasury teams are handling more payments without more people. Fraud is getting harder to detect, ISO standards are changing how payment data moves, and CFOs expect real-time cash visibility.

The initial brief for the LaunchPad was about optimised payment search. But before we could design a solution, we needed answers to three questions: what exactly is the problem, who will use this tool, and what does "optimised" mean for this user.

Discovery before the workshop

AWS LaunchPad requires customer research to be done before the workshop starts. This part was completely my responsibility.

I conducted 15 user interviews with treasury managers and heads of treasury. My goal was to understand their daily workflows, where they lose time and what they need to trust the data they work with.

What I learned is that these are very busy, highly knowledgeable people with a lot of responsibility, working under constant pressure. They were not looking for a new, fancy interface. They wanted a faster and more reliable way to do a job they already know very well.

This insight shaped the direction of the whole project. Our product owners were in a hurry to define and build the feature. Based on the research, I proposed a different approach: an AI assistant designed for humans, not just a "human-in-the-loop" system where the user is there only to check the AI output. In treasury, where every decision involves large sums of money, strict compliance and personal accountability, this makes a big difference. The assistant should reduce the cognitive load, not become one more system to check.

The AWS LaunchPad workshop

For four days we worked in two Amazon 2-pizza teams of 6 people each, small enough to be fed by two pizzas. Small teams keep communication simple and give every member clear ownership, so they can move faster.

Together, the two teams brought 12 people from TIS, AWS and the customer:

• TIS: Lead Product Designer, Product Owner, two Sponsors, Stakeholder, Customer Expert, AI Subject Matter Expert, Backend Developer, Frontend Developer
• AWS: Innovation Advisor, Solution Architect
• Customer: Data Lake Subject Matter Expert

The workshop follows the Amazon Working Backwards approach. Step by step we defined the customer, built an empathy map, wrote How Might We statements and a problem statement, agreed on our desired outcomes, wrote a press release and FAQ, and defined the key success metrics.

In parallel our engineers prepared the technical questions, for example whether it is secure to query the customer's data lake directly or we need separate tables, and whether the data should be pre-aggregated or processed on the fly.

Who is the customer?

Based on the interview findings, we mapped three possible customer types:

• Head of IT / CIO – motivated to keep the system secure. He will ask if the system is secure and how people feel about AI.
• Head of Shared Services – wants to centralise processes and improve collaboration between departments. A possible buying persona.
• Head of Treasury – needs answers about transactions, wants transparency and doesn't like manual work and inefficient flows.

We chose the Head of Treasury as our primary persona, because he is the person whose daily work the assistant will change. The security questions from the CIO persona stayed with us as a requirement during the whole project.

Problem statement

Today, the Head of Treasury cannot easily ensure that all financial, regulatory and GDPR controls are in place. Daily, including when assigning user permissions or making cross-border payments, he needs clarity, transparency and accuracy to understand the data in his domain. He needs a way to quickly retrieve granular and aggregated information about transaction data, with a guarantee that any change he initiates cannot breach a control or push through a non-compliant process.

After voting and prioritising our ideas by customer value and effort, we framed our challenge:

How might we let a treasury owner get an accurate, granular answer about transaction data without creating manual work behind it?

Success metrics

We defined a validation plan in four stages, each with a clear target:

• Demo with around 50 customers – 70% confirm the agent adds value to their daily work
• Alpha with 20–50 testers – 70% positive experience
• Beta with 20–50 testers – 70% positive experience for the selected use cases
• Initial roll-out for up to 1,000 users in Q1 2026 – continued use after 1, 3 and 6 months

For each stage we also wrote down our assumptions to validate, for example that historical data is a valuable feature and that not every question needs real-time data.

Designing for trust

Treasury managers are accountable for every payment. An AI answer is useful to them only if they understand what it covers, where it comes from and what stays their responsibility. I defined four patterns to build this trust:

Prototyping: from Lovable to Figma

To explore ideas quickly, I started with rapid prototyping in Lovable. Lovable is great for testing ideas fast, but it didn't give us the design accuracy we needed. Our design system files were in Figma, so I exported the prototype to Figma with the html.to.design plugin and continued there.

The final high-fidelity designs were created in Figma and Figma Make with our design system embedded. This way the assistant looks and feels like a natural part of TIS Payments.

Outcome

The TIS AI Personal Assistant is live and listed on AWS Marketplace in Finance & Accounting, Financial Services and Generative AI. According to the listing, it cuts the time users spend searching for information from 30 minutes – 2 hours down to seconds.

In the pilot, 26 of 38 accounts (68%) signed a contractual upgrade, and the other 12 are still pending.

Payment status and audit trail queries are already available. Cash position and forecast variance queries are in discovery.

Next steps

After the workshop I continued working on the product, and after the official launch I collected feedback from users to guide the next improvements.

Learnings

One of my biggest learnings from this project was that the research done before a workshop decides how much the workshop can achieve. AWS LaunchPad requires customer research before the four days start, so I conducted 15 interviews with treasury managers and heads of treasury and built the persona in advance. Four intensive days are not enough to understand a user from scratch, and having this ready kept the whole team of 12 focused on real needs instead of assumptions.

This reinforced that in a regulated domain like treasury, trust is a design problem, not only a technical one. Accuracy is important, but users also need to see the context, the source and the limits of every answer. This is why I proposed an assistant designed for humans, not just a human-in-the-loop system, and defined the four trust patterns around it.

I believe that treating the user as the decision-maker leads to a better product. It changed what the assistant shows, how it speaks and where the responsibility stays. Today the TIS AI Personal Assistant is live on AWS Marketplace, and in the pilot 26 of 38 accounts signed a contractual upgrade.