Baseline Report

Problem

Financial institutions using Cense needed a faster way to understand a crypto compliance case without immediately navigating the full depth of an Enhanced Due Diligence investigation.

The existing product model generated a Baseline Report, a Comprehensive Report, and supporting files from the same case run. Although the Baseline Report was intended to provide a quick overview, it had not yet become the concise, decision-oriented artifact that first-line compliance teams needed. Users still required significant crypto knowledge to interpret a case, understand what mattered, and determine whether they could proceed or needed to escalate it.

This created an information architecture problem as much as a visual-design problem. The report needed to answer a deceptively simple question: What is the minimum amount of information a first-line reviewer needs to form a defensible initial position?

Internal UX analysis translated that question into a concrete set of investigator needs: understanding crypto complexity and risk drivers, how assets were acquired and used, fiat inflows and outflows, ownership evidence, suspicious counterparties, unexplained third-party transfers, the relationship between activity and the client's declared story, and any gaps that should prevent the case from progressing.

At the same time, simplifying the experience created its own compliance risk. Removing too much detail could make decisions less defensible, hide relevant evidence, or cause users to interpret missing information as safe information. The design therefore had to reduce cognitive load without reducing traceability.

The two stakeholder quotes below are representative composites synthesized from the documented needs and research themes rather than verbatim interview quotations.

'I don't need another hundred-page investigation to start a case. I need to understand what happened, what looks unusual, and whether I can continue or need to escalate.'

FIRST-LINE COMPLIANCE OFFICER

Needs a concise and defensible overview that converts complex crypto activity into a clear initial decision.

'The report contains the information, but interpreting it still depends too much on somebody who already understands crypto.'

HEAD OF COMPLIANCE

Needs a repeatable workflow that reduces specialist dependency while preserving the evidence required for policy and audit review.

Proposal & Process

The proposal was to reposition the Baseline Report as a triage and decision-support layer rather than a smaller version of the Comprehensive Report.

The report would prioritize the client's story, major holdings, material risk signals, evidence completeness, and the next action a reviewer should take. Detailed forensic analysis would remain available in the Comprehensive Report and supporting data exports. This created a deliberate information hierarchy: understand first, investigate deeper when necessary.

The work followed an iterative, decision-oriented UX process:

1. Translate the compliance workflow into user questions.

   I reframed the report around what a first-line reviewer actually needs to establish: risk position, major red flags, acquisition of funds, current holdings, activity chronology, evidence gaps, sanctions or AML exposure, and whether the customer's story is internally consistent. This provided a behavioral foundation for the information architecture rather than starting from existing report sections.

2. Audit the existing report against those questions.

   The current wireframe and report structure were reviewed for coverage, duplication, missing evidence, and information that belonged in deep investigation rather than first-line triage. The documented workflow was effectively: map questions → evaluate wireframe coverage → identify gaps → propose targeted design fixes.

3. Define the Baseline/Comprehensive content boundary.

   Together with Product and compliance stakeholders, I helped separate information into three categories: Baseline-only summaries, information summarized in Baseline but expanded in Comprehensive, and Comprehensive-only investigation material. This prevented the Baseline from gradually becoming another full EDD report.

4. Design around progressive disclosure and scanability.

   High-value information was promoted into clear visual summaries. For example, the Top Assets Summary was specified around a highly prominent total portfolio value, compact asset rows, clear fallback states, aggregation of lower-value assets, and explicit handling of unavailable or unknown information. The objective was immediate comprehension rather than maximal data density.

5. Redesign risk communication for uncertainty.

   The product had to support report runs both with and without an external labeling provider. When labels were unavailable, the risk score could not imply false certainty; the agreed 2026 behavior was to display the score as unavailable rather than fabricate an internal score. This required UX states that made missing risk data understandable and actionable.

6. Validate the report through scenario-based research.

   The research plan focused on approximately 5–8 scenario reviews with first-line or minimum-crypto-knowledge users. Participants would assess plausibility, decide whether to approve or escalate, and identify what should be verified next. The aim was not simply preference testing; it was validating whether the report supported the intended decision.

7. Turn findings into implementation-ready stories with Engineering.

   Design decisions were decomposed into detailed states, content rules, fallbacks, overflow behavior, data dependencies, and acceptance criteria. Rather than treating the Figma output as the endpoint, the design work became a shared specification between UX, Product, compliance expertise, and Engineering. This aligns with the broader Cense UX mandate of using design to validate problems and support product decisions throughout implementation.

Result

The project produced a more deliberate Baseline Report architecture and an implementation framework centered on first-line decision making.

Core deliverables included:

• A question-led Baseline information architecture

  mapping report content to the decisions a first-line reviewer must make.

• A Baseline versus Comprehensive content boundary

  , preventing deep investigative material from overwhelming the first-line overview.

• A redesigned Top Assets Summary

  prioritizing portfolio scale and composition with clear handling for missing, single-asset, few-asset, and overflow states.

• Redesigned compliance risk presentation

  , including explicit states for cases where third-party risk labels are unavailable.

• Decision-oriented next-step concepts

  intended to make escalation triggers and outstanding verification requirements more visible.

• Structured empty, unavailable, and unknown data states

  , reducing the risk that absence of evidence could be mistaken for a safe result.

• Implementation-ready UX stories and acceptance criteria

  that translated visual concepts into deterministic product behavior for Engineering.

These deliverables attacked the original friction at several levels. Reviewers no longer had to treat every case as a deep investigation just to understand the basics; crypto specialists were less likely to become the sole interpreters of the report; and the report architecture created a clearer pathway from evidence → understanding → action.

The initiative also laid groundwork for Cense's longer-term product strategy. In the documented future-state vision, a lightweight Baseline Report can become the default screening mechanism for high case volumes while only genuinely complex or suspicious cases progress to a comprehensive review. The 2026 work deliberately focused on making the current Baseline understandable first rather than prematurely implementing that commercial separation.

Impact

• Reduced cognitive load for first-line review:

  The redesigned hierarchy shifts the Baseline away from comprehensive-investigation density and toward a concise explanation of the case, its material risks, and the evidence that still requires attention.

• Lower dependency on crypto specialists:

  The product direction explicitly addresses the documented problem that advanced crypto/compliance knowledge can become a bottleneck and trigger unnecessary escalation to second-line or EDD teams.

• Created a foundation for scalable triage:

  The future operating model targets a system in which straightforward cases can be handled automatically and only a minority require deeper investigation; the Baseline redesign establishes the information and decision model needed to move toward that state.

• Improved consistency and audit defensibility:

  By deliberately distinguishing risk signals, unavailable data, evidence gaps, and detailed investigation material, the UX supports more repeatable decisions without hiding the evidence chain behind an oversimplified score.

Challenges

• Simplifying without oversimplifying.

  A successful Baseline needed substantially less information than the Comprehensive Report, but excessive reduction could remove the context required to defend a compliance decision. I mitigated this by using the investigator's decision questions as a content filter and by maintaining a clear path to deeper evidence rather than simply deleting complexity.

• Designing around incomplete risk data.

  External labeling providers add cost and may not always be enabled. The product therefore had to remain useful when no risk score was available. We addressed this by designing an explicit unavailable state and separating the act of understanding the case from dependence on a single risk score.

• Balancing the future vision with immediate delivery.

  Strategically, Cense wants Baseline and Comprehensive workflows to diverge as customer volumes increase. Operationally, the 2026 product still produced both from the same run. We avoided designing an imaginary future product and instead improved the current experience while establishing boundaries that could support future separation.

Role

UX Lead / Product Design Consultant

• Led the translation of complex compliance and blockchain requirements into a user-centered information hierarchy.
• Defined the UX questions, content boundaries, report structure, component behaviors, edge cases, and fallback states required for implementation.
• Challenged feature-level requests by repeatedly returning the discussion to the first-line user's job: understand the case, establish an initial position, and decide what happens next.
• Worked across Product, Business/compliance expertise, and Engineering to make usability and regulatory defensibility part of the same design conversation.

User Experience Research & Product Strategy

• Structured discovery around explicit product decisions rather than open-ended research, including minimum viable Baseline content, next-step guidance, policy alignment, and the role of exports.
• Developed scenario-based validation around plausibility assessment, approve/escalate decisions, and identification of missing evidence.
• Connected immediate UX decisions to Cense's longer-term operating model for high-volume automated screening.
• Converted research risks and unresolved assumptions into concrete questions that could be validated before further product investment.

Learnings

• Information hierarchy is a compliance control:

  In regulated products, hierarchy is not merely visual polish. What is promoted, summarized, hidden, or labeled as unknown directly affects how users assess risk and whether they can defend that assessment later.

• A summary should optimize for decisions, not document length:

  Making a report shorter does not automatically make it simpler. The meaningful design shift came from organizing information around the user's decision—understand, verify, approve, or escalate—rather than compressing an existing report.

• Designing uncertainty is as important as designing success states:

  Compliance products frequently operate with incomplete or third-party-dependent data. Clearly differentiating unavailable, unknown, unverified, and genuinely low-risk states protects users from interpreting absence of information as evidence of safety.