Vi startede med at gøre mekanikken i politikmotoren eksplicit gennem Domain Learning. Politikker kombinerer i denne kontekst betingelser for adfærdsindikatorer såsom enhedsfingeraftryk, lokationsændring, forbrugshastighed og tidligere fejlhistorik med resultater såsom tillad, bloker eller udløs forhøjet autentificering. Den eksisterende grænseflade viste disse regler som databasevisninger og konfigurationstabeller. Det matchede ikke, hvordan analytikere ræsonnerer om svindelmønstre, eller hvordan de forklarer beslutninger til interne revisionsteams.

Gennem workshops med Callsign produkt-, engineering- og sikkerhedsspecialister under Sandbox Experiments kortlagde vi de eksisterende regelstrukturer, de svindelscenarier, de skulle dække, og punkterne, hvor konflikter eller huller opstod. Denne kortlægningsøvelse førte til en klar adskillelse mellem svindeldetekteringsmodellen, der scorer begivenheder, og politiklaget, der anvender tærskler, tilsidesættelser og workflow-beslutninger. Arbejdet blev et stykke UX-design for AI-systemer, hvor grænsefladen styrer, hvordan modeloutputs flyder ind i virkelige handlinger.

Derfra definerede vi en informationsarkitektur for virksomhedssikkerhed, der behandlede en politik som det centrale objekt. Hver politik samler sine betingelser, handlinger, historik og links til relaterede regler. Analytikere kan følge en politik fra definition til evaluering uden at forlade konteksten. Beslutninger registreres på en måde, der understøtter revisionsgennemgang og regulatoriske kontroller relateret til SCA, PCI DSS og intern styring. Vi validerede tidlige versioner af denne struktur med Callsign-teams ved hjælp af koncise scenarier snarere end abstrakte diagrammer og justerede baseret på deres feedback.

Med arkitekturen på plads redesignede vi analytiker-journeys for at afspejle, hvordan svindelteams faktisk tænker gennem en sag. Den tidligere oplevelse tvang brugere til at hoppe mellem konfigurationsskærme, referencedokumenter og datatabeller, når de ville justere en enkelt regel. Vi erstattede dette med et politikcentreret flow. Analytikere identificerer et scenarie, åbner det relevante politiksæt, justerer betingelser i kontekst og ser øjeblikkeligt, hvor i workflowet ændringen gælder.

Kerninteraktionskonceptet var en tre-gestusmodel designet til interaktionsdesign for svindelanalytikere. Analytikere trækker for at oprette eller ompositionere noder i workflowet, klikker for at åbne og redigere regelparametre inline og tegner en forbindelse for at linke noder og definere sekvensering. Disse gestus er konsistente på tværs af værktøjet, hvilket holder læreindsatsen lav for brugere, der kommer fra risiko- eller compliance-baggrunde snarere end produktbaggrunde.

Vi skulle også foretage scope-afvejninger gennem Tension-driven Reasoning. Til den første release prioriterede vi politikoprettelse, konfliktssynlighed og påvirkningsforklaring over avancerede samarbejdsfunktioner eller fulde versionshistorikvisninger. Denne beslutning afspejlede det umiddelbare mål om at gøre demoer med risiko- og sikkerhedsteams hos store banker effektive og troværdige. Tidlige interne tests med Callsign-analytikere bekræftede, at de nye journeys reducerede tiden det tog at udtrykke et almindeligt svindelscenarie i værktøjet og gjorde forklaringer under kundeopkald mere ligetil.

Konfiguration alene var ikke nok. Callsign havde brug for en måde, hvorpå analytikere og bankinteressenter kunne forstå, hvad et givet sæt politikker ville gøre i realistiske scenarier. Vi skabte en evalueringstilstand, hvor brugere definerer en simuleringskontekst ved hjælp af naturligt sprog-stil filtre såsom kundesegment, geografi eller transaktionstype. Systemet kører derefter disse indstillinger gennem svindeldetekteringsmodellen og politikmotoren og præsenterer resultaterne i en fokuseret analytisk visning.

Evalueringsvisningen er central for brugeroplevelsen af risikostyringsværktøjer, fordi den lukker kredsløbet mellem konfiguration og påvirkning. Analytikere kan se, hvor ofte et scenarie ville føre til automatisk godkendelse, forhøjet autentificering eller blokering, og kan kontrollere, om højrisikosager ville slippe igennem. For at gøre dette fortolkeligt stolede vi på datavisualisering til banksystemer implementeret med D3, ved at bruge graf- og flow-repræsentationer, der fremhæver, hvor trafik koncentreres, og hvor politikker skaber flaskehalse.

Vi holdt forholdet mellem konfiguration og evaluering meget klart. Politikker redigeres altid i konfigurationsrummet, og evalueringsmiljøet bruger disse definitioner uden at lade brugere ændre dem på stedet. Denne sikkerhedsbarriere undgår usporede ændringer under analyse. Vi brugte evidensbaseret UX for AI til at forfine evalueringsflowet, iagttog hvordan analytikere fortolkede diagrammerne og hvor fejllæsninger opstod, og forenklede derefter etiketter og interaktioner i overensstemmelse hermed. Resultatet er et kontrolleret, men fleksibelt kredsløb, hvor analytikere kan teste, justere og begrunde politikstrategier uden at afsløre modelinterne funktioner.

Fra de første uger behandlede vi hver skærm som en del af et design system snarere end et engangsartefakt under Concept Convergence. Systemet dækker workflow-konstruktion, politikstyring, evalueringsvisninger og understøttende navigationsstrukturer. Hver komponent har dokumenterede tilstande, interaktionsregler og brugsnoter. Dette fundament blev et design system til bankprodukter, der hjælper Callsign med at opretholde konsistens på tværs af nye sikkerhedsfunktioner og fremtidige moduler.

På engineering-siden tilpassede vi os tidligt med front-end teamet. Politik- og workflow-komponenter blev modelleret som React-enheder, der kan sammensættes for at skabe mere komplekse skærme uden duplikering. For eksempel vises det samme politikresumémodul i konfigurationslister, i workflow-lærredet og i evalueringsresultater, med en konsistent adfærdskontrakt. De D3-baserede visualiseringer sidder inde i dedikerede React-containere, så layout- og renderingsansvar er klart adskilt, hvilket understøtter performance-tuning til større datasæt.

Vi strukturerede leverancer, så de passede til deres udviklingsproces under Implementation Partnership. Specifikationer fulgte strukturen af deres eksisterende arbejde i Git og Confluence, og vi deltog i regelmæssige sessioner med ingeniører for at løse edge cases, før de nåede implementering. Efter omkring otte uger nåede projektet en stabil tilstand. De nye workflows og politikstyringsgrænsefla