Information Architecture | Tan Zhou

From Messy Dataset to “At-a-Glance” Visualizations of Competitive Landscape

Sat, 01 Nov 2025 05:26:35 +0000

Overview

As AI and automation accelerated across the industry, my stakeholders need to understand the competitive space of AI, automation, and technology in title/settlement platforms. The challenge wasn’t collecting information—it was making complex, uneven competitive data understandable and actionable for decision-makers.

This case study focuses on how I translated a large competitive dataset into a clear visualization system. It intentionally avoids sharing competitive “insights” or conclusions about specific companies.

The Business Problem

Leadership needed decision support for product strategy questions, like:

Where are competitors investing in automation across the transaction workflow?
What types of solutions exist (end-to-end platforms vs. narrow tools)?
Which parts of the ecosystem are truly comparable to our context?

To answer these, stakeholders needed a landscape they could trust and interpret quickly—without reading a long report.

The Research Challenge

This was not a clean comparison set. The competitive space had three structural issues:

1. “Apples-to-oranges” offerings

Some products are broad workflow platforms. Others specialize in one slice (e.g., document automation, search, closing coordination, post-close). Comparing them on a single axis would oversimplify and mislead.

2. “AI” claims were inconsistent

Many vendors used similar language (“AI-powered,” “automation,” “intelligent workflow”), but the underlying capability varied widely. The dataset needed a way to separate marketing terms from meaningful maturity indicators.

3. Too much information to be usable

Raw competitive research often becomes a dense spreadsheet that only the researcher can navigate. Stakeholders needed clarity at a glance, with enough structure to support follow-up questions.

My Role

I led the work end-to-end across:

Research framing (what decisions the landscape needed to support)
Data modeling and taxonomy creation (how we normalized inconsistent inputs)
Classification logic and decision rules
Information design and visualization system
Stakeholder alignment through iterative readouts and refinement

What Success Looked Like

We defined success as a set of outputs that were:

Strategic: tied to product decisions, not just market description
Trustworthy: classification logic visible and repeatable
Scannable: usable in seconds, not minutes
Multi-dimensional without being messy: complexity represented through a system, not a single overloaded chart
Reusable: designed as an artifact we could update as the market changed

Process: From Research Needs to Visualization System

Step 1: Translate stakeholder questions into “decision views”

Before making any visual, I reframed stakeholder needs into explicit questions the landscape must answer:

Orientation question: “Where does each solution fit in the workflow?”
Capability question: “How advanced is automation/AI—and how broadly does it apply?”
Context question: “Which solutions are actually relevant to our domain focus?”
Ecosystem question: “What’s plug-and-play vs. what changes switching costs and integration realities?”

This step prevented a common failure mode: building one beautiful chart that answers none of the real decisions.

Step 2: Build a classification model to normalize messy data

To compare uneven offerings, I created a shared taxonomy—essentially a “data contract” for the landscape.

What we standardized (examples)

Primary workflow focus: where the product anchors its value (even if it touches multiple steps)
Workflow breadth: narrow point solution → broad end-to-end platform
Automation mechanism: rules-based automation vs. AI-driven vs. hybrid
Integration posture: standalone tool → integrated suite → ecosystem
Domain relevance: relevance based on transaction complexity and operational needs (rather than vendor labels)

The key: explicit decision rules

I documented rules for edge cases, such as:

Platforms spanning multiple workflow stages
Suites that bundle unrelated modules
Tools that market “AI” but primarily deliver rules-based automation
Products that appear comparable but serve fundamentally different transaction contexts

This turned subjective categorization into something stakeholders could understand, challenge, and trust.

Step 3: Choose a “backbone” view for orientation

I started with Workflow Stage because it matches how most stakeholders naturally reason about real estate closing: as a lifecycle with handoffs and dependencies.

Why this came first

It gives immediate context to non-experts: “Where in the process does this help?”
It avoids premature ranking or “winners/losers”
It makes later views easier to interpret by grounding them in a shared mental model

Design principle: Always orient before differentiating.

Step 4: Avoid the single 2×2 trap—use complementary, orthogonal views

A single chart can’t responsibly represent a market where:

some products are broad platforms,
some are specialized,
and “AI” is not consistently defined.

So I designed a system of four views, each answering a different strategic question with minimal cognitive load.

The Solution: A Four-View Competitive Landscape System

1. Workflow Stage Landscape

Question answered: “Where does each solution primarily contribute within the closing workflow?”

**Why it works:**It helps teams understand the ecosystem without needing domain expertise. It also prevents false comparisons by showing that many solutions aren’t trying to solve the same problem.

How it’s designed for clarity:

Grouped by workflow stages with short “expectations” per stage (what buyers typically look for there)
A dedicated representation for cross-lifecycle platforms so multi-stage tools don’t distort stage-specific comparisons

2. AI & Automation Maturity × Workflow Breadth

Question answered: “How mature is automation/AI—and how broadly does it apply across the workflow?”

**Why it works:**This separates two things stakeholders often conflate:

maturity of automation capability
how much of the workflow the product claims to cover

How it’s designed for responsible interpretation:

“Maturity” is grounded in observable capability indicators rather than marketing terms
“Breadth” is framed as workflow ownership, not simply feature count

Design principle: Keep axes orthogonal so the chart stays truthful.

3. Commercial vs. Residential Relevance

Question answered: “Which solutions are most comparable to our operational context?”

**Why it works:**Transaction types differ in complexity, documentation, risk, and workflow variability. Without this lens, stakeholders may draw incorrect strategic conclusions from superficially similar tools.

How it’s designed:

A simple segmentation that scopes interpretation rather than ranking vendors
Helps stakeholders quickly identify “directly relevant” vs. “adjacent signals” in the market

4. Ecosystem Integration Landscape

Question answered: “What’s a tool we can plug in vs. an ecosystem that changes interoperability and switching costs?”

**Why it works:**Integration posture shapes adoption dynamics: procurement, implementation effort, dependency risk, and long-term flexibility.

How it’s designed:

Clear categories that highlight whether a solution is:
- a standalone product,
- part of an integrated suite,
- or operating as an ecosystem strategy

Design principle: Strategy isn’t only about features—it’s about constraints.

Making It Usable: Storytelling and Stakeholder Alignment

Progressive disclosure (how the readout was structured)

I presented the work like a product narrative:

Start with workflow stage to establish orientation
Move to maturity × breadth to discuss capability patterns
Add relevance to prevent misinterpretation
End with ecosystem integration to connect to strategic leverage and constraints

This sequence reduced debate and increased clarity: stakeholders could follow the logic rather than getting stuck on definitions.

Built-in “how to read” guidance

Each view includes lightweight framing—axis definitions, category labels, and reading cues—so the landscape can stand alone without the researcher in the room.

Outcomes

This work created an artifact stakeholders could actually use:

A shared vocabulary for discussing a fragmented market
A trustworthy classification model that made comparisons feel grounded
A decision-ready visualization system that supported strategy discussions without requiring deep domain knowledge
A framework designed to be maintained and updated, not a one-time research dump

(Deliberately omitted here: any market-specific conclusions or vendor evaluations.)

What This Demonstrates

This project is a snapshot of the kind of UX work that sits at the intersection of:

research strategy (defining what must be true to make a decision),
analytics and synthesis (normalizing messy inputs),
information design (reducing cognitive load),
and stakeholder alignment (building shared understanding through clear frameworks).

Key Takeaways I’d Reuse

Start with the decisions, not the data.
Normalize first; visualize second.
Use multiple simple views instead of one complex chart.
Make classification rules explicit so the work earns trust.
Design for scanning—then support deeper follow-up.

Modernizing document workflows in a complex transaction platform

Sun, 01 Jun 2025 05:26:35 +0000

Problem

Business & product challenge

Before: Document coordination lived in email threads and attachments—forcing manual tracking, follow-ups, and low confidence in ‘what’s latest’.

In complex, high-stakes transactions, “documents” aren’t a feature—they’re the operating system. Internal teams and external clients must request, collect, verify, and reference dozens of items across multiple parties, deadlines, and handoffs.

The legacy reality looked like this:

Requirements defined through contracts + back-and-forth Q&A
Documents arriving in scattered email threads and attachments
Manual tracking (“what’s missing, who owes what, what changed?”)
Version confusion and rework (duplicate uploads, wrong file shared, unclear latest)

This is a product problem (lack of shared visibility and trusted status), and a business problem (time and risk). Industry benchmarks show why this matters: “interaction workers” spend ~28% of time on email and ~19% searching/gathering information, and improving collaboration/searchability can create ~20–25% productivity uplift in the right conditions.

Users

Internal transaction teams (ops/service/processing): need a reliable source of truth to coordinate work, maintain confidentiality, and avoid errors.
External clients/partners: need clarity on what’s required, what’s outstanding, and confidence that the right version was received.

Why this was important

Document handling is repeated constantly. If the workflow is unclear, people default to email and personal workarounds—creating compounding cost (minutes lost per document × many users × many transactions) and compounding risk (wrong versions, missed requirements, delayed approvals).

Strategy

Research goal

To define a modern document workflow that:

makes requirements visible,
makes progress trackable,
makes document status trustworthy, and
scales to high volumes without forcing users back into email or local folders.

Approach: a program of research, not “one study”

I ran this as a multi-phase research arc where each phase answered the next logical question:

Discovery (workflow reality): What actually happens today—and where does it break?
Concept shaping (new mental model): What structure reduces ambiguity (checklists, status, ownership, visibility)?
Validation (does it work for real users?): Can internal and external users understand it quickly, act confidently, and avoid errors?
Scale (second-order constraints): Once adoption grows, what breaks next (organization, findability, versioning, automation)?

Methods

Because the work spanned maturity stages, I matched method to decision:

Interviews / workflow mapping to surface real breakdowns and system constraints
Prototype concept testing to de-risk mental models (terminology, status, ownership, visibility)
Design validation to confirm comprehension and usability before rollout
Later-stage discovery focused on scale issues (high doc counts, search behavior, version control expectations)

My decision rationale

Why interviews first

At the start, the users didn’t have a UI problem—we had a coordination system problem. Interviews and workflow mapping were the fastest way to:

uncover the real “jobs to be done” (request → chase → receive → verify → organize → reuse)
expose hidden constraints (privacy boundaries, handoffs, audit needs)
identify why “email + attachments” persisted (it filled gaps the product didn’t cover) Decision logic: If we guessed at the workflow, we’d build a beautiful interface around the wrong system.

Why prototype testing next

Once I saw the breakdown was “tracking + trust,”, I needed to validate whether a checklist/status model could become the shared source of truth. Prototype testing was the right tool because it let us:

test comprehension of status/ownership (without expensive build)
test terminology and “professional tone” early (a known adoption lever)
measure whether users could correctly answer “what’s left?” in seconds Decision logic: We needed behavioral evidence that the model reduced ambiguity—not just opinions about it.

Why design validation (internal + external)

The workflow had two audiences with different risk profiles. Validation ensured:

internal users could move fast without creating errors
external users could act confidently without needing an explainer
status changes and version cues didn’t create false confidence or confusion Decision logic: In document workflows, clarity is safety—validation is risk management.

Why organization + versioning later

As the system matured, the next bottleneck wasn’t “can I upload?”—it was “can I find the right thing and trust it?” At scale, long document lists and multiple versions shift the problem from interaction design to information architecture and reliability.

Decision logic: Once the checklist model reduced “what’s missing,” the system’s limiting factor became “what’s correct and where is it?”—so research pivoted to structure, search behavior, and version control.

Key decisions

Checklist became the coordination layer that connects requests, uploads, ownerships, status, notifications, and version confidence.

Reframe documents from “file storage” to “workflow tracking”

Decision: Treat document handling as an end-to-end workflow (requirements → request → receipt → verification → history), not a repository. Why: Email persists because it supports coordination and status tracking—so the product had to do that job better.

Use a checklist model as the shared source of truth

Decision: Anchor the experience in a checklist/status structure that answers: what’s needed, what’s in progress, what’s done, what changed, who owns it. Why: This reduces ambiguity for both internal teams and external clients, and creates a consistent foundation for later features (notifications, organization, automation).

Make ownership, visibility, and status explicit (not implied)

Decision: Design for role-based visibility and unambiguous status transitions (with language that users trust). Why: In transaction workflows, unclear “who owns this” creates delays; unclear “status” creates rework and risk.

Standardize organization defaults before adding “more flexibility”

Decision: Provide sensible default structure (folders/tabs/categories, sorting and filtering patterns, and “pin/priority” behaviors) rather than relying on everyone inventing their own system. Why: Ad-hoc organization scales poorly and increases search time and error rates—especially across teams.

Invest in version confidence as a first-class requirement

Decision: Prioritize version history and clear draft/final cues (including stacking, timestamps, and traceability). Why: Version confusion is a trust-breaker; users can’t move fast if they fear sharing the wrong thing.

What changed

Roadmap & scope changes

The roadmap shifted from “improve upload” to “support workflow clarity” (tracking, status, ownership, visibility).
Document organization and versioning were treated as strategic enablers—not nice-to-haves—because they determine whether the system works at scale.

Design & UX changes

Checklist-based experience became the core navigation layer for document work (what’s outstanding, who owes what, what’s completed).
Status language and interaction patterns were refined through iterative testing to reduce misinterpretation.
Organization patterns were elevated: default structures, better sorting/filtering, and pathways to reduce scanning and “where did it go?” confusion.
Version confidence was explicitly designed (history, recency cues, clearer distinctions between draft/final).

Stakeholder alignment outcomes

Research artifacts created a shared mental model across product/design/ops/engineering—so decisions could be made faster and with less debate about what users “really do.”

How research translated into action: key inisghts were turned into concrete product decisions and measurable experience changes.

Impact

Industry research suggests that a large share of knowledge work is consumed by communication and information retrieval:

~28% of time is spent managing email (reading/writing/responding)
~19% of time is spent searching and gathering information
Making information more available and searchable can reduce information searching time by as much as ~35% in some contexts

A checklist-driven document system directly targets both buckets:

fewer emails needed to ask “what’s missing / did you get it?”
less time spent searching across inbox threads and attachments
fewer wrong-version loops and duplicate handling