Intro

Client

MIDOM

Role

Lead Product Designer

Industry

RegTech / Risk Management

Proptech

Timeline

Ongoing

Team

CEO, CMO, 3 Devs

This Is An Ongoing Project. Release Q3 2026

Designing A Risk App That Boards Can Trust

Regulatory governance failures cost millions. Most mid-market organisations are still managing that exposure across Slack, Excel, and email — no shared language, no audit trail, boards making calls on data that's days old. Midom was built to replace that. My job was to design the product from the ground up.

My Scope

End-to-end product design across research, definition, and delivery, building a new category of governance tooling from the ground up.

Stakeholder research: risk managers, compliance leads, C-suite board members

End-to-end product design: IA, user journeys, interaction design, visual system

Design system architecture for a remote engineering team

Strategic roadmap decisions under active funding pressure

The Challenge

Replace fragmented risk tooling with a single governance system, making integrity measurable and decisions defensible at board and regulatory level.

Outcome Snapshot

Enabled

board-level visibility without operational noise

Defined

end-to-end risk lifecycle where none existed

Protected

MVP timeline through strategic feature prioritisation

Research

The Problem Was More Than Fragmentation

I had the opportunity to have some time upfront to get embedded in how risk actually operated. Six weeks of interviews, workflow observations, and tool audits across risk managers and board-level stakeholders. Three things defined the problem space.

Multiple Tools

Data was everywhere and nowhere

There was no consistent tool used and compliance teams would often navigate between multiple:

Slack for urgent flags and quick updates

Excel for historical tracking and status reports

Email for stakeholder communications

SharePoint for document storage

Even Benchmarks

No shared language

Listening to risk managers assess the same scenario showed another problem. Ratings varied wildly, one person's "amber" was another's "red". With no objective benchmarks, overseeing where the real problems exist was almost impossible.

60% disagreement on severity classification

No shared language for discussing risk levels

Managers relied on "gut feel" not objective criteria

No structure for evolving ESG & Risk rules

Lack Of Oversight

Delayed oversight

Board members needed to understand organisational risk exposure to fulfill their governance duties, but had no direct access to current information.

2-3 days minimum for each board report

Exposure fines could cost business millions

Making high level calls without oversight

Out of date information, and disjointed ownership

Strategy

Two Journeys, One Direction of Truth

Research made clear that risk managers and board members don't just need different features, they move through risk data in fundamentally different ways. Risk managers create, challenge, and refine. Boards oversee.

User Journeys

Two Journeys

So I designed two distinct journeys around a single architectural principle: information flows one way.

Risk teams input and validate upstream; the board view only ever surfaces approved data. No drafts reach oversight. No incomplete information travels upward.

So I designed two distinct journeys around a single architectural principle: information flows one way.

Risk teams input and validate upstream; the board view only ever surfaces approved data. No drafts reach oversight. No incomplete information travels upward.

The Consumption Side

Board Members

Senior decision makers need visibility into organisational risk without managing or editing individual cases. They have dual-authenticated, read-only access to secure data.

Primary Objectives

Understand overall risk exposure at a glance

Trust that data is current, consistent, auditable

Drill into details only when necessary

Shared language to guide decisions

The Input Side

Risk Managers

Risk Managers create, update, and escalate integrity risk cases. They are accountable for accuracy, defensibility, and final approval before information surfaces to leadership.

Primary Objectives

Capture and update risk cases quickly

Apply objective risk scoring with confidence

Maintain clear, defensible audit trail

Spot emerging risk patterns before escalation

Entry via Dashboard

Case Creation & Management

Data Case Sourcing

Metrics & Ratings

Approval & Case Visible

Entry via Dashboard

Insight Overview Review

Access Control Report

Access Exec Reports

Return To Heatmap

The Feedback

A one-directional system

I designed two distinct journeys around a single architectural principle: information flows one way. Risk teams input and validate upstream; the board view only ever surfaces approved data. No drafts reach oversight. No incomplete information travels upward.

Board Journey: Dashboard → Instant exposure overview → Report access → Drill-down on flagged cases

Risk Manager Journey: Dashboard → Case creation → Data sourcing → Metrics and ratings → Approval

Three Foundations

Instant Scanability

Visual hierarchy must enable recognition of urgency in under 5 seconds.

Shared Language

Consistent classification matrix creating organisation-wide standardisation.

Transparent

Every change traceable with clear ownership, timing and overview available for clear transparency

The Dashboard

Three Hypotheses, One Clear Answer

Single success criterion: a user with no training should answer "where is our highest risk exposure?" within 10 seconds.

Hypothesis 01.

Dashboard with charts

My first instinct was visualisation, pie charts for distribution, bar graphs for trends.

Charts required interpretation

Participants asked "But what does this mean?"

Decision-making slowed rather than accelerated

34% task completion

Why it failed: High cognitive load, users need confidence, not analysis.

Hypothesis 02.

List view with filters

Participants found individual cases but couldn't read patterns. Risk severity had no spatial relationship to likelihood.

Sequential scanning disconnected cases from framework

No spatial relationship between severity and likelihood

Couldn't spot patterns at a glance

50% task completion

Why it failed: Lists optimise for detail, not exposure assessment.

Winner - Hypothesis 03.

Grid Based Heatmap

Risk managers had been running informal severity/likelihood assessments in their heads for years. This heatmap made that consistent, visible and worked with an existing mental model.

Unanimous approval in first-round testing

"This is exactly how I think about risk already"

Zero onboarding friction

96% task completion

Why it worked: Preserved mental models (Excel grid) while dramatically increasing scan speed.

Defining Escalation Logic

With the grid validted, I workshopped with risk teams to establish three rules:

High Risk Over All

A single red case escalates the entire category. High urgency demands immediate attention.

High Risk Over All

A single red case escalates the entire category. High urgency demands immediate attention.

High Risk Over All

A single red case escalates the entire category. High urgency demands immediate attention.

Amber Escalation

Four or more amber cases turn red. Volume of moderate risk creates systemic exposure.

Amber Escalation

Four or more amber cases turn red. Volume of moderate risk creates systemic exposure.

Amber Escalation

Four or more amber cases turn red. Volume of moderate risk creates systemic exposure.

Green Icon = Active

Green without icon = zero cases. Green with icon = low-risk cases exist.

Green Icon = Active

Green without icon = zero cases. Green with icon = low-risk cases exist.

Green Icon = Active

Green without icon = zero cases. Green with icon = low-risk cases exist.

Wireframes

Testing Structure Before Visual Design

With the two journeys and heatmap logic defined, I moved into wireframes — stress-testing navigation before any visual decisions were made. I ran separate task-based sessions with risk managers and board members: creating and rating cases, identifying highest exposure, locating case ownership.

Testing The Framework

Defining the Navigation

Navigation was a critical structural decision. Board members need instant overview, risk managers need to move deep into case detail and back out without losing their place. I tested three patterns to find what held up under real use.

Left-aligned global navigation for consistent orientation across all sections

Breadcrumb trails to maintain context when drilling into individual cases

Topline navigation with pull down for specific cases

Navigation Winner

The Winning Combo

Left-aligned navigation paired with breadcrumbs was the clear winner.

Users could move freely between sections without losing their place inside a case, a small structural decision that dramatically improved task completion on the more complex risk manager journey.

Left-aligned navigation paired with breadcrumbs was the clear winner.

Users could move freely between sections without losing their place inside a case, a small structural decision that dramatically improved task completion on the more complex risk manager journey.

Left Aligned Navigation

for moving between core product sections at any point

Breadcrumb Navigation

at the top for tracking position within a case as they drilled deeper

Critical Pivot

Protecting the MVP

The in-app chat feature was consuming disproportionate dev resources putting the MVP timeline and funding demo at risk.

Focusing Design On The User

Reframing the problem

In-app chat was consuming 40% of available dev sprint capacity. I'd argued for chat from the start. Real-time communication between risk managers and board members was a useful aspect.

I ran a workshop with the team to map every job chat was doing to help find a quicker deliverable for Phase 1.

In-app chat was consuming 40% of available dev sprint capacity. I'd argued for chat from the start. Real-time communication between risk managers and board members was a useful aspect.

I ran a workshop with the team to map every job chat was doing to help find a quicker deliverable for Phase 1.

The Chat Reality

What job does chat
currently do?

Enables instant communication

Keep stakeholders informed of changes

Creates a time-stamped record of discussion and decisions

Surfaces new case creation

The Notification Pivot

What do we need for
Phase 1 to succeed?

Notify stakeholders when something changes

Make case movement visible to boards

Maintain a clear, defensible audit trail & timeline

Show ownership of case

The Process

New case creation

Transformed manual risk to investment-grade SaaS product

Case updates

Stakeholder notification on status change

Urgency changes

Case movement visible to board in real time

Case closure

Visable completed case solutions and history

Old UI

New UI

Design System

Delivering For Development

I worked closely with a Sri Lankan development team through weekly syncs. Given the time zone difference and aggressive timeline, I created a comprehensive UI design system in Figma with all major components—navigation, CTAs, colours, and typography.

The Design Building Blocks

Building for scale and trust

Much of the framework featured repeating patterns (cases, documents, timelines all following similar structures), the dev team could use these components as building blocks, applying design logic to edge cases and feeding back for approval.

Designed core product assets, navigation, heatmap, case structures

Clear component boundaries, giving developers autonomy

Trusted the team to apply design standards using components

Bi-weekly syncs to catch issues early and maintain momentum

System-first approach

Cards

Navigation

Colours

Controls

Scale Quickly

The Key Learning

With repeating elements and a solid design system, remote teams can build and scale quickly.

The system enabled autonomy—developers could solve problems without constant designer intervention. Regular check-ins ensured anything that stood out could be caught and refined.

The Impact

What We've Achieved

MIDOM is currently in development with a planned 2026 release. Post-launch metrics and validation data will be updated following deployment.

Development Planned For 2026 Release

Variant B outperformed Variant A on every metric

Journey Defined

Defined an end-to-end risk lifecycle where none previously existed, turning governance theory into an operational system.

Fragmentation Eliminated

Case management replaced scattered Excel workflows with a single source of truth.

Board Visibility

Board members gained real-time oversight without operational noise, \answering "How exposed are we?" in seconds, not days.

Strategic Delivery

Strategic tradeoffs protected delivery & funding. The notification pivot secured funding timeline while preserving user value.

Systems Thinking

Designed a scalable model that works across teams, risk types, and delivery stages.

Cross-Functional Leadership

Aligned around a shared structure for managing risk. Enabled remote dev team to build autonomously with design system.

Reflections

What I Learnt

Removing in-app chat was the right call — not because it wasn't valuable, but because protecting the MVP and the funding demo mattered more at that stage. Knowing when to defer a good idea is a skill in itself.

The design system reinforced something else: a remote team's velocity depends on decisions made before a single component is built. Clear boundaries and repeating patterns meant developers could work autonomously without constant check-ins.

Structure over surface. Outcomes over attachment.