How we built the AI workstream for support — and how I rebuilt the way design works around it.

From the Support Center to the AI workstream

In this case I described how we stopped developing support inside the messenger, built a separate service around the customer's problem, and started separating the service channel from marketing communications.

But by that point support at T‑Bank was already more than a place to get problems solved.

Over nineteen years the bank had learned to answer any question, and customers took that literally. Only about a quarter of requests were actually about a problem. The rest:

• navigation: "how do I open a savings account?";
• exploration: "where's the best place to put my money?";
• questions that had nothing to do with the bank at all — from recipes to asking us to sing a song.

And support staff answered all of it. That was a real strength of the bank, and it also explains why support became one of the main entry points into the ecosystem for customers.

The Support Center made that entry simpler and cleared out some of the noise. But the product model stayed the same: the customer still had to go to a separate section, phrase a question and then work through the existing combination of bot and support staff.

From strategy to a target state

In Q4 2025 a customer service strategy running to 2030 appeared. It set out a different target state: nine out of ten problems solved automatically and in a single tap, the system knowing the context before the customer gets in touch, and a person stepping in where empathy, expertise or a difficult judgment call is needed.

At the interface level, the product lead and I started describing the target version of smart support — what came out of it was a shared intent layer between search and support.

The customer does not need to work out in advance where to look for a feature, where to ask a question and where to request help. They state their intent in the context of the screen they are on, and the system decides what happens next: take them to the right action, give an answer, kick off a flow or bring in support.

At the same time we deliberately stayed with the chat model. That gave us a target picture of the interface. But there was no ready-made product path between it and the chat we already had.

How we built the roadmap

We worked backwards from the target experience on our own and broke product development down into sequential iterations.

First we had to replace the technical foundation of the chat and learn to migrate existing flows onto it gradually. Then build multimodal interaction and dynamic responses, connect AI, merge the intent layers of search and support, and only after that move toward a single entry point.

Once we pulled the product changes, the architecture and the rollout order into one plan, we ended up with a 24-month horizon.

The strategy did not hand us that number. It came out of breaking the work down: that is how long a realistic path from the current product to the target version takes without rebuilding a business-critical service channel in one go.

What stood in the way of the plan

The chat ran on an old SDK carrying heavy technical debt. We counted defects per feature and could see that almost every new piece of functionality brought new bugs with it. Engineering went off to fix them, product lost predictability in the backlog, and the roadmap kept slipping.

For design it looked like this: instead of the best solution, we increasingly had to find an interface workaround for yet another "we technically can't do that". I did not want to build the next product as a set of compensations layered over the old architecture.

At a leads meeting three positions converged:

• engineering could no longer develop the old foundation predictably;
• product could not plan complex changes while resources kept going to defects;
• design could not assemble the target experience out of interface workarounds.

The decision to rewrite the SDK was a shared one. The new architecture became the first stage of the 24-month plan.

We deliberately planned the first product iterations without an LLM: the new foundation and interface first, intelligence after. Customers should not have to absorb two big changes at once, and there is no point in testing agents on unstable architecture.

How the initiative got through the gates

At T‑Bank a new product initiative goes through a stage-gate process before it gets a team, headcount and budget.

To make the case, we bundled into one initiative:

• the concept of the target customer experience;
• the 24-month roadmap;
• the new SDK and architecture;
• the migration path off the old foundation;
• the resources to launch a separate workstream.

I built the first AI-native Support concept. In it the customer stated their intent in whatever way suited them, and the system decided who should answer and what action to offer: a model with knowledge of the bank, a vetted scripted bot, or a human specialist.

The concept was never meant as a final interface or as an illustration of someone else's strategy. It showed what customer experience was worth changing the product and its technical foundation for.

The initiative passed the review and got a dedicated team and resources.

A team for the new workstream

The designers in my group were running current product work. Handing one of them the AI direction on top of that would have put the new product in line behind committed delivery.

We needed a designer who understands AI products, can work with high ambiguity, and is ready to design the behavior of a working system rather than screens alone.

I wrote the profile and hired someone specifically for this workstream. The designer started in February 2026. I handed over the product context and the first concept, and stayed accountable for final design decisions and stakeholder agreements. He ran the day-to-day product work himself.

By April we already had a first working version of the target experience running on a device.

The hire locked AI-native Support in as a distinct area of work — one where we could change the process without stopping development of the existing product.

Why we moved out of Figma and into code

In the new chat, quality came down to response latency and streaming, switching between text and voice, haptics, attachment behavior, dynamic actions and how context gets handed to a human. You cannot make those decisions from a sequence of pre-prepared screens.

The limit showed up fastest with Liquid Glass. In Figma we could roughly show what the material looked like, but there was no way to reliably tune tint, scroll edge, system states and how glass behaves in motion.

So we picked a different stack: Claude Code and Codex for working with native builds, Xcode and Android Studio for running and tuning behavior, GitHub as the shared base of the project.

The build no longer lived locally with one designer. The repository held the current state, the alternatives we had tried, and the rules for how everyone else on the team could work with it.

Figma stayed for static states, edge cases, specs and the design system. What changed was where decisions got made: we designed behavior on the device and used mockups to lock down what had to be passed on.

How we validated the target experience

We did not need a prototype with pre-written answers. That kind of prototype demos well and tells you nothing about the real pace of a conversation, the length of a response, the pauses, the errors and how the interface reacts to unpredictable content.

In the product release plan, AI was due to arrive after the migration to the new architecture. But the design build needed a model immediately: without one there was no way to check how the target interface behaves in a real conversation.

I connected the OpenAI API, and a real LLM ran inside the build. Responses were generated live during the conversation, streaming was real, and voice, attachments and interactive elements behaved as close to the target flow as possible.

The build's code was never production code, and was never meant to become it.

How decisions reached engineering

The build helped get the idea agreed precisely because it behaved like a product. Stakeholders could walk the flow themselves and judge an experience instead of a promise. The design system team could discuss the material and the components in motion instead of a picture of glass.

Liquid Glass was new to the developers too. They had no ready experience of how a system material should behave in our product specifically, or where platform rules end and the bank's design system rules begin.

We tuned the main states in the native build, locked the behavior down and used it to onboard developers: we went through tint, scroll edge, transitions, animations and system constraints directly on the device.

Developers got the repository before refinement and saw the whole mechanic, instead of reconstructing it from mockups and comments. When behavior raised a question, the team could open the same build, compare options and decide before anything was implemented in production.

The build became a shared reference and closed the gap between what the designer intended, what the developer understood and what the customer ends up seeing.

The change started with workshops

Inside the AI workstream, the designer started working with the product in its native environment: real latency, real dynamics, system constraints and unpredictable model output.

For one team that already changed the quality of decisions. But as a lead I cared more about the next question: how to turn one team's practice into a capability the whole design org can reach.

There are around 600 designers in the company. The designer and I ran a series of talks and workshops; some sessions drew between 150 and 300 people. Afterwards teams came to us separately to work through their own tasks.

The workshops built a shared language and real interest, but they did not change the regular process. For the new practice to actually scale, it had to be built into work designers already do every week.

I picked design review as that point.

Our approach to design review

Features regularly reached design review with basic deviations from the spec: the wrong spacing, shadow or color, a different animation curve, off timing.

Developers and QA do not always catch this: they are checking that it works and that the flow holds, and they are looking for different things. As a result the designer spends time on mechanical checking instead of product logic and the overall quality of the experience.

The target process looks like this:

1. A task moves to design review.
2. The agent goes into the engineering repository, finds the relevant branch or the latest merge, and checks the implementation against the design spec and the working reference. A separate skill defines the rules of the check.
3. Formal deviations go back to the developer, and fix tickets are created automatically.
4. The designer steps in once basic accuracy has already been verified, and assesses the logic, the flow and the quality of the experience as a whole.

We deliberately simplified the first MVP iteration: the agent compares a screenshot of the implementation against the spec instead of going into the code. That is a faster way to find out whether it can reliably catch the standard deviations, without starting from integration into different repositories and engineering processes.

Checking through code and automatic ticket creation remain the target vision. If the MVP confirms the quality of the comparison, the next step is connecting to the development branch and running the full pass through to handing the finished feature to the designer.

My role

I joined the project as Design Lead, accountable for final design decisions, and have been running it since December 2025.

What I owned:

• described the target experience of smart support together with the product lead and broke the path to it down into a 24-month plan;
• built the first AI-native Support concept and used it to make the case at the gate reviews;
• took part in the shared decision to rewrite the SDK and argued against compensating for the old architecture in the interface;
• wrote the profile and hired a designer specifically for the AI workstream;
• moved the key behavior decisions out of mockups and into the native build, connected a real LLM, and made the build a shared reference for the team;
• onboarded developers together with the designer and ran a series of workshops for designers across the company;
• proposed agentic design review as the next point of scale and am preparing its screenshot-based MVP.

The service strategy set the overall direction. The decision on the new architecture, securing the workstream and allocating resources were joint work across product, engineering, design and the business. My part was connecting that direction to the customer experience, building the design capability for a new area, and changing the way the team designs that experience.

The product and the new SDK are still in development, so there are no customer metrics yet. The result of this stage is the AI workstream itself: a 24-month plan, a team, a new technical foundation, a working model of the product and a new way of designing.