Competitive Analysis | 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.

Voice Interaction Design: Food Journaling via Voice Assistant

Thu, 07 Mar 2019 06:32:08 +0000

Overview

My Role: UX Researcher and Designer

Methods: Literature review, Interviews, Competitive analysis, Journey mapping, Heuristic evaluation

Data Sources: Interview transcripts, Literature

Deliverables: Research report, Dialogic flow, Sample conversations

Tools: Google Assistant, Amazon Alexa, Google Sheet

Background/Context: Studies following diabetic patients and weight watchers found food journaling to be an effective means of managing one’s diet. Although automating the journaling process using smart devices could increase adherence by decreasing the effort and mental burden required, it could also lead to a decrease in users reflecting on collected data. After searching the field, I failed to find a well-designed voice-based interface that supports food tracking.

Project Overview: The overarching goal was to answer the question “When people track foods they eat daily (food journaling) via a voice assistant, how can we design the dialogic flow to facilitate users’ reflections on their eating habits?”.

Table of Contents

Objective

Understand users needs and pain points in food journaling
Design the flow of the conversation and its underlying logic to facilitate voice-based food journaling
Adapt Nielsen’s heuristics to evaluate voice-based interface

Opportunity and Process

Opportunity

The study of automated food journaling show that such automation could lower the burden of tracking and increase adherence (Beenish et al., 2016), but it could lead to a decrease in users reflection on collected data(Choe et al., 2014). Also, the majority of these studies leverages only graphical interfaces, building on the legacy of hand-and-finger input devices.These approaches are limited by the required input since users might not always be able to log their entries.

Voice assistants like Amazon Alexa, Apple Siri, and Google assistant are getting more and more ubiquitous. Their support of hands-free interaction makes voice-based food journaling an ideal use case for voice assistants.

Voice Assistants are more accessible than ever. Photo: Stratablue.com

Process

In order to define the users’ requirements, I conducted a competitive analysis of existing tools that support voice-based food journaling. I also interviewed two participants who have previously used their mobile phones for food journaling to understand users’ needs, behaviors, and motivations of the user during the journaling process.

Using the information collected from the field review and interviews, I wrote a series of sample dialogues to capture the “sound-and-feel” of the interaction under different scenarios. These sample dialogues convey the flow that the user will experience and allow me to experiment with different design strategies, such as how to promote the discoverability of new features or how to confirm a user’s request.

At the usability test stage, a friend who is unfamiliar with the project was asked to role-play the simple dialogues with me. This helped me curate the conversation, defining the flow and the underlying logic that represents the complete food journaling experience. I also conducted system evaluations with a set of adapted heuristics to expose usability issues.

Strategy

Exploratory Interviews

My initial goal of exploratory interviews was to understand users’ needs in the journaling process. Two interviews were conducted with informants who had experience journaling the food they ate.

Heuristic Evaluation

1. Awareness of system status

The Nielsen heuristics emphasize the visibility of system status. Although visibility does not apply to voice-based interfaces, user awareness and feedback are still important. The system needs to inform users about what it is doing in a timely and appropriate fashion.

2. Error prevention

As with any system, it is best to prevent errors from occurring or handle them in a way that is less intrusive to user experience. This becomes even more important in a system with no visual interface since people cannot “unsay” what they have previously said. This system addresses this issue by providing users their options for the next step explicitly in the conversation.

3. Flexibility and efficiency

Novice users become experts after they become familiar with a system, and experts benefit from efficiency. As a result, some instructions, which would be helpful to novice users, may become redundant to experts. The logic flow supporting setting up customized shortcuts for frequently used terms to speed up the process.

4. Accessibility

Voice based interaction is great for people who are unable to use a graphic interface. It doesn’t require input from hands which offers more accessibility since users could interact with the system while carrying groceries, cooking a meal, or driving a car.

5. Ambiguity

People don’t communicate in syntax the way computers do. They sometimes use metaphors or slang. They sometimes forget words or pause when speaking. Voice technology should accommodate the users’ communication style and needs. When the user pauses, the system just repeats the previous response with a much more detailed instruction of what users can do until they make a selection.

6. Discoverability

The invisibility of a voice-based interface makes it difficult for users to explore new ways of interacting with the system. In this logic flow, new actions will be introduced in the form of quick tips at the end of each conversation (except those involving specific customized shortcuts). During the reflection stage when a user views their journals on a display, the system suggests new interactions that are more efficient that would increase the accuracy of the users’ food journaling.

7. Multimodal Reflection

In the five-stage personal informatics model proposed by Li et al.(2010), the reflection stage may involve looking at lists of collected personal information or exploring or interacting with information visualizations. For a voice-based system, exploration is inherently difficult for exploration and visualization is impossible. To address this, the logic flow allows for short-term reflection by repeating and confirming the list of input items during every conversion. The system also expands to another modality for long-term reflection. The design flow falls back to a visual interface after collecting information. A user can access their journaling data on their smartphone and on the website where auxiliary graphical interfaces would be available. However, this part is not accomplished during this project.

Outcomes

Dialogic flow for food journaling via voice assistant
Sample dialogue for voice-based interactions

The logic flow of conversation shows four stages of the voice-based food journaling system. In the beginning, users start with the voice assistant by saying specific trigger words. In the collection phase, novices and experts can take different approaches. The reflection stage suggests a multimodal approach – short-term reflection is embedded in the conversation while long-term reflection involves reports and visualizations viewed on another display. At the final stage, users can take actions after they reflect on their food journal. They can correct something that was incorrectly recorded via speech, set a shortcut for more efficient interaction, or explore new ways to interact with the voice assistant.

Sample Conversations

A novice user adding Food. (Inputs from the user is highlighted)

- Hi My Food Journal,

- Hi! Welcome to My Food Journal. I can help you add new food to the journal or check previous journals. Which would you like?

- Add new food.

- Okay, go ahead and say the names.

- Ummm…

- You can add food by saying its name and serving size. Go ahead.

- One in-n-out double-double, French Fries, and Chocolate shake.

- Got it. Would you like to add more?

- No, that’s it.

- Sure. I got one in-n-out double-double, a medium French Fries, and a medium chocolate shake. Is that correct?

- Yup.

- Alright. Quick tip: You can always add more food by saying “Hi My Food Journal, quick add.”

In the sample conversation, note that the system always provides an affirmation when it gets any information from the users. At the end of each conversation, new actions are introduced in the form of quick tips to increase discoverability.

Quick add and customized shortcuts (Inputs from the user is highlighted)

- My Food Journal, quick add.

- (A response tone playing indicating the system is listening)

- “McDonald Lunch Combo”

- (A confirmative tone playing indicating the system have received your information)

In this example, a user has set up a shortcut named “McDonald Lunch Combo” which includes a list of food they usually get from McDonald. This way the user could skip the instructive steps and complete the journaling in a much more efficient fashion.

Conclusion/Reflection

The focus of this project was on the bottom-up process of conversation design. After gathering insights from competitive analysis, interviews, sample conversations, and adapted heuristic evaluations, I delivered a dialogic flow for food journaling via voice assistant and sample conversations. The next step would be to expand the dialogs based on the flow and implement the system using a real-world voice assistant platform.

Design Patterns: Help small non-profits build trust and engagement

Mon, 01 Jan 0001 00:00:00 +0000

Overview

My Role: UX Researcher in a team of five (5) researchers

Background/Context: Donors are often the core providers of a charity’s resource. Without donor support, some charities quickly struggle to function and are likely to enter a path of decline. Thus, it is important for charities to connect with their donors in order to gain their trust and increase their motivation.

Project Overview: I worked as part of a team to design best practices for facilitating online monetary donations to small charities and non-profits. Through interviews and analyses of established non-profit websites and their users’ behaviors and motivations, we developed design patterns allowing non-profit organizations to increase trust and engagement among donors.

Methods: Interviews, Competitive analysis, Design patterns, Literature review, and Desk research

Data Sources: Interview transcripts and Literature

Deliverables: Report describing research and suggested design patterns

Tools: Google Docs, Google Slides, and Google Forms

Table of Contents

Objective

What stops a motivated user from making donations to small charities online?
How can we convert a user’s motivation to donate to small charities online?
How can help small charities design their online presence to establish trust and engagement?

Opportunity and Process

Opportunity

Most HCI research related to non-profits focuses on facilitating transparency in order to build trust among stakeholders (Marshall et al., 2016, 2018). However, there is still little understanding of how a non-profit’s website and its features impact donors’ motivation and engagement.

Process

We analyzed charity websites to understand the design processes they follow to convert user motivation into calls for action. We interviewed nine (9) donors to understand their perspectives on these websites. We focused our research on establishing online trust and engagement through better design.

We delved into the Persuasive Design literature and created design patterns that enhance the experience for millennials visiting small charitable websites. Effective design patterns translate research findings into executable solutions and assist web designers and developers. They contain:

A concise and memorable title
Statement[s] describing the problem or challenge
Description and discussion on solving the problem
Solutions that are likely to succeed
Solutions that are typical yet undesirable

We identified impediments to charitable donations and recommended four design patterns that can help convert users’ motivation into action.

Strategy

Competitive Analysis

We analyzed websites of well-establish charities to explore different donation models, including WWF, UNICEF, Facebook Fundraisers, GoFundMe, etc.. We examined their user bases, information architectures, messaging approaches, calls to action, emotional designs, accreditations, and social influences. The competitive analysis provided us with key insights and informed our development of interview questions.

Interviews

We conducted interviews with nine (9) individual participants who either were active online donors or had donated through the above websites. The interviews highlighted the aspects that either motivated or discouraged donors as they navigated through the charity website. After our interviews, we inferred a relatively comprehensive list of statements taking the form “a person donates if he or she…”. We synthesized these statements into more general themes relevant to donors’ motivations.

Persuasive Design

We followed Fogg’s behavior model for persuasion to guide our designs. The behavior model highlights three factors relevant to accomplishing target behavior - motivation, ability to perform, and trigger.

There is some debate about the ethics of designing charity websites with the sole intention of encouraging people to donate their money. However, our goal in creating design patterns was not simply to persuade people to donate:

We wanted to leverage persuasive design for potential donors that already have medium levels of motivation but are missing ability and triggers to act on it.
We wanted to understand what discourages motivated people from performing actions related to donations in online platforms and how HCI can help address these aspects.

Outcome

Importance of trust

Trust is often critical when converting charitable motivations to actions
Monotonous, one-way interactions do not help donors help engaged or fulfilled

Suggested patterns

Our design patterns were concise and memorable with explicit descriptions of the relevant problems and common pitfalls that should be avoided.

The patterns that emerged were “Trust through reputation”, “Trust through transparency”, “Trust through social circle”, and “Commitment through Engagement”.

Delivered Design Patterns

Conclusion/Reflection

In this project, we conducted competitive analysis and interviews and analyzed user behavior/motivations pertaining to charities. We developed design patterns for non-profits seeking to increase trust and engagement among donors.

In the future, we hope to create additional design patterns incorporating other factors that are useful when designing a successful non-profit website (e.g. social media marketability, attractiveness to volunteers, etc.). These additional design patterns would eventually form a pattern language useful for converting different users’ motivations into actions furthering the non-profits’ overarching goals.