Making AI part of how designers work, not just what they ship

Digital Banker journeys crossed roles and systems: a lead could be reassigned, linked to an appointment, handed to an origination system and closed by someone else. Static screens left Product, Engineering and Change to infer the gaps, discovering differences late.

Design-to-build checks were manual, rare and unrecorded. AI coding tools were also arriving without shared rules for synthetic data, approved sharing or the boundary between prototype and delivery decision.

A bank prototype raised questions about data, access and implied agreement; early versions ran only on a designer’s machine. Code generation produced plausible interfaces quickly but also decoration, unsupported states and irrelevant architecture.

Experience ranged from daily use to none, so a workshop or mandate would not change practice. Both AI-assisted work and AI in the product needed visible sources and uncertainty, with a person responsible.

More annotated screens, longer decks and another review added reading, not alignment. I reframed the problem as time to evidence: build a leader or banker journey within a day so the room could try it.

Each prototype answered one named question, used synthetic data and required approved sharing plus design and engineering checks. Generated material outside that question was discarded; the prototype never became the build.

The same frame made design QA repeatable. A tool could compare design with the live build and record differences, while the designer retained judgement; banker-facing AI likewise kept sources visible and answers correctable.

Using AMP Code and GitHub Copilot, I built proactive-lead prototypes from blueprint moments and interaction rules. Leaders could review demand, filter and bulk-reassign leads; bankers could review assignments, record contact attempts and create the next activity.

Designers then built their own journeys beside me, naming the question, discarding irrelevant output and checking with engineers. I also built AI-assisted QA that lists design-to-build differences as candidates, not verdicts, and presented a prototype-hosting business case.

I did not automate judgement: QA never passes a build, prototypes never become delivery code, and assistive concepts never decide for a banker. Exploratory knowledge-assistant and branch-handover concepts instead exposed inaccessible sources, cross-customer context contamination, audit events and PII masking.

Product, Engineering and Change used prototypes before decks, moving discussion from interpreting screens to testing cases; Change used them for training material. Designers built their own difficult journeys with one-to-one follow-up on prompts and discarded output.

Engineers checked feasibility from the first prototype and shaped QA around build differences, not pixels. I framed hosting as shared alignment, change and review capability; funding and organisational enablement were still being worked through, not decided.

Prototypes became the program’s way to inspect journeys before build. Feedback credited alignment and change materials, observed rather than measured as time or defects saved; QA created a record, but adoption and time saved remain future measurements.

A joint leader-view study recorded System Usability Scale 95 across ten participants: a team result I do not attribute to my design alone. The existing view remained for the following release, so the full journey did not ship then; designers’ independent prototype use was observed.

I now teach AI on real work: scope one question, discard what does not serve it and check the result with people. The same rules govern banker-facing AI—visible sources, shown uncertainty and a person accountable—and keep prototypes separate from delivery decisions.