DESIGNED END TO END / DEUTSCHE BANK

Risk is messy.The decision
can't be.

I led the design of dbAssess from research and user needs through to the workflows and interface that reached worldwide deployment. The challenge was making an AI-enabled assessment genuinely useful to the people responsible for the final call.

END-TO-END DESIGNAI-ENABLED PRODUCTWORLDWIDE DEPLOYMENT

01 / THE ASSESSMENT QUEUE

Recreated product screens · illustrative assessment dataExplore screen ↗

THE SHORT VERSION

Not a concept. A product that shipped.

WHAT I OWNED

All the design: research, gathering needs, stakeholders, journeys, interactions and UI.

WHAT I DESIGNED

AI-enabled assessment across business units, risk types, jurisdictions, desks and drivers.

WHAT HAPPENED

Developed and deployed worldwide at Deutsche Bank.

THE PROBLEM

One rating.
A lot underneath it.

A risk could cut across business units, desks, products, jurisdictions and individual drivers. Assessors needed to understand what had changed, what evidence mattered and how to arrive at a defensible conclusion. None of that disappears just because you put it in an app.

HOW THE BANK SEES RISK

The assessment hierarchy

  1. AU / RISK TYPEBusiness-level assessment
  2. JURISDICTION / LEGAL ENTITYGeographic and organisational context
  3. GRANULAR RISK DRIVERProduct, desk and driver detail
  4. RESOURCEA further assessment perspective

FROM QUEUE / TO EVIDENCE / TO DECISION

DISCOVERY & OWNERSHIP

I needed to learn the work,
not just design the screens.

I owned the research, user needs, requirements and stakeholder relationships as well as the UX and UI. The central question wasn't ‘what screen do you want?’ It was what an assessor needed in front of them to make a decision they could defend.

WHAT PEOPLE NEEDED TO DO

Find their assessment

Understand the scope: business unit, risk, desk, jurisdiction.

See what changed

Compare the previous rating with this cycle's indicative view.

Check the reasoning

Understand what supports the recommendation.

Make—and explain—the call

Agree, choose another rating, justify it and send for review.

Research / Requirements / Stakeholders / UX / UI / Development handover

THE QUEUE

A table this dense had better earn its place.

The queue needed to support a lot of assessments, without making people open each record to find out what mattered. I kept the information density, but grouped related ratings, surfaced changes and made it possible to filter by the dimensions people actually worked with.

DESIGN NOTE / Keep the detail. Make it easier to scan.

01. Location / legal-entity queue. The example counts shown here were prototype data.Explore screen ↗

AI IN THE ASSESSMENT

If the system suggests a rating,
show me why.

I brought the indicative rating, its explanation, the last assessment and the contextual evidence together. An assessor needed to interrogate the suggestion, not just take it on trust.

02. The indicative rating, explanation and previous assessment in one place.Explore screen ↗

THE DECISION POINT

The suggestion isn't
the decision.

The previous assessment, the system's indicative rating and the assessor's proposal are deliberately distinct. That separation matters: a recommendation should inform the person making the judgement, not quietly become the judgement.

01 / PREVIOUS

Important

The last assessment and the reasoning behind it.

02 / INDICATIVE

Significant ↑

A system-generated view, with supporting explanation.

03 / THE ASSESSOR

Their call

Accept the suggestion, or record a different rating and why.

A recommendation you can't question is not much of an aid to judgement.

THE COMPARISON

Keep the previous
assessment in sight.

The previous and proposed views stay side by side. People can compare the rating and its written rationale—without opening another tab or relying on memory.

WHY IT'S SIDE BY SIDE / Compare both the rating and its reasoning.

03. Previous and proposed assessments, including their written rationales.Explore screen ↗

WHEN THE ASSESSOR DISAGREES

Disagreement wasn't
an edge case.

The system's suggestion wasn't treated as the final answer. I designed a clear route to select another rating, explain why, write the rationale, add supporting evidence and save or send the assessment for review.

THE RULE / The expert remains responsible for the judgement.

04. An alternative rating, with likelihood, severity, rationale and evidence.Explore screen ↗

DOWN TO THE RISK DRIVER

A summary can only
tell you so much.

A high-level rating can represent numerous underlying assessments. The granular view lets people inspect the product, desk, jurisdiction and driver detail while staying inside the assessment they were working on. The aim was detail without disorientation.

05. A granular risk-driver list inside the parent assessment.Explore screen ↗

AND THE PREVIOUS REASONING?

Open a record. See what was decided before.

A selected granular record reveals the historical rating and rationale alongside the list, keeping the context and the evidence together.

06. The detailed rating inspector, still within the wider risk assessment.Explore screen ↗

THE DECISIONS BEHIND THE DESIGN

The bits I chose not to simplify.

This wasn't a case of removing columns and declaring victory. Some complexity was essential. The design decisions were about where to preserve it, where to organise it and when to leave the final call with a person.

01

KEEP THE DENSE TABLE

Assessors needed fast comparison. I grouped and filtered the detail instead of hiding it.

02

DON'T HIDE THE RECOMMENDATION'S BASIS

The indicative rating needed enough explanation to be understood and challenged.

03

KEEP THE EVIDENCE CLOSE

Controls, findings, events and previous reasoning belong in the assessment journey.

04

GO DEEPER, NOT ELSEWHERE

Drill into the granular records without losing the wider assessment context.

The goal wasn't ‘simple’. It was usable for the people doing the work.

WHAT HAPPENED NEXT

All the way
into production.
Worldwide.

I led the research, stakeholder management, UX and UI for dbAssess, from defining the needs through to a complete design ready for engineering. Deutsche Bank built the AI-enabled platform and deployed it worldwide.

MY WORK

Research, requirements, stakeholder leadership, workflows and complete product design.

THE PRODUCT

Indicative ratings, contextual intelligence, granular investigation and documented decisions.

THE DELIVERY

Engineering build and deployment across Deutsche Bank's worldwide operations.

Recreated design-reference screens. Example data is illustrative; deployment is a confirmed project outcome.

Recreated product screens · illustrative assessment dataClose ×

Scroll to inspect the full screen. Select Close to return to the case study.

01. Location / legal-entity queue. The example counts shown here were prototype data.Close ×

Scroll to inspect the full screen. Select Close to return to the case study.

02. The indicative rating, explanation and previous assessment in one place.Close ×

Scroll to inspect the full screen. Select Close to return to the case study.

03. Previous and proposed assessments, including their written rationales.Close ×

Scroll to inspect the full screen. Select Close to return to the case study.

04. An alternative rating, with likelihood, severity, rationale and evidence.Close ×

Scroll to inspect the full screen. Select Close to return to the case study.

05. A granular risk-driver list inside the parent assessment.Close ×

Scroll to inspect the full screen. Select Close to return to the case study.

06. The detailed rating inspector, still within the wider risk assessment.Close ×

Scroll to inspect the full screen. Select Close to return to the case study.