Temenos wanted to use its partnership with Microsoft to bring more AI into its products, particularly in retail banking. The risk was a solution looking for a problem: a chatbot might demonstrate the technology without making the product any easier to use.

There was a significant gap between ideation and implementation. The platform supported implementation, but the work leading up to it, researching ideas, validating requirements, understanding impact and making decisions, was fragmented and manual.

We explored a conversational AI experience embedded inside Temenos Transact. Product managers already asked questions, sought explanations and relied on experts and support teams, so conversation matched an established behaviour rather than introducing a new way of working.

Crucially, not every pain point became an AI opportunity. Product improvements, bugs and issues better handled by support were kept out of scope. My role was to turn validated needs into jobs to be done, define the conversational interaction model and shape how the assistant behaves within the wider product.

We deliberately paused the original business requirements document to make room for discovery before committing to features. Understanding first, designing second, with AI feasibility informing the design without driving it. Five stages, from prep work before we ever met the client to early access.

We worked with internal product experts and banking customers across Europe and the United States, including BIL Bank and Commerce Bank. Mapping both roles helped us separate shared pain points from role-specific needs.

We mapped the journey for both roles, from idea to launch, then storyboarded ideas really quickly. One scenario stood out: after a release, when calculations go wrong, teams can spend significant time going through reports and logs to find out what happened and which contracts are affected.

Research surfaced many pain points, and we didn’t turn them all into AI features. We ran an impact analysis, sorting pain points on the wall, and turned them into point-of-view statements and how-might-we questions.

To design the product well, I also had to understand a bit of the technical architecture behind it: how the web app, the Azure services, the models and the banking backend fit together.

I led the AI and conversational design work, turning research insights into jobs to be done, sample conversations and a behavioural design framework. Rather than starting with a list of prompts, I explored the full interaction: what the user wants, what context is needed, how the assistant responds and what the user can do next.

We used early concepts and high-fidelity prototypes to explore how the copilot would live inside Transact: where the chat sits and how much guidance to show. We tested continuously with customers for around three months, and worked closely with engineering to align the experience with what the data could support.

Before moving to high fidelity, I mapped the key conversations as mid-fidelity frames: finding the right sources, choosing a template, running a compliance check and following up with market research.

On testing, we found that users didn’t want to type @ to select an agent, and most of the time some of the agents showed up as not available. Based on that, we refined the experience so users no longer have to select an agent with @.

We extended the Temenos design system with AI primitives, using the Temenos icons, so the copilot stays consistent with the host product.

London Underground is a 150+ year old system serving 5 million journeys a day. This project began with my own confusion changing lines, so I set out to learn whether it was a problem faced by many Londoners.

Tube It is a product-agnostic, end-to-end guide. The same route, fare-zone and peak-hour information, line-transfer help and AR wayfinding show up wherever the rider is: on the phone, at the kiosk, on the platform and on the train.

I followed the double diamond end to end, mapped here like the Underground: every stop is an activity I carried out.

User stories from the interviews and survey were voted on by 16 fresh passengers across the four persona types, to avoid existing bias. These are the highest voted needs.

Sketching helped me understand how users want to navigate, and how maps that show the blueprint of a station help them plan their walk.

Passengers mostly use Citymapper, Google Maps and TfL Go, so Tube It had to solve what those apps don't. Comparing them showed two features that are missing:

Paper first, then low fidelity: cheap to make, cheap to throw away, and enough to test what matters before any pixels are polished.