How can dense research be easily accessible and usable in various views?

Designing a research workspace

Analogy group builds structured knowledge from unstructured sources. Clients use our platform to conduct research, visualize findings, and use that evidence to make organizational decisions. I worked as the product designer with the engineering team on a comprehensive product redesign.

The central tension was between flexibility (wanting to have as many useful features as possible) and clarity (wanting to avoid feature bloat and clutter). The underlying system needed to support many kinds of entities in the data, adress domain-specific edge cases, and be customizable. But the product needed to reduce that possibility space into a clear experience.

Context

The product served two types of users:

• Internal researchers, who orchestrated research runs, reviewed outputs, and helped clients get useful data into the system.
• External advocacy and legal users, who were less technical and needed to explore findings, understand relationships, and make decisions from the interface.

The platform’s features were obscured by challenging UI (or lack of any UI at all). The redesign happened as the team was rethinking the data model. Engineering was moving toward a more flexible graph-backed system, but the product question was still open:

How should users actually work with a huge, editable knowledge graph?

Problem

I began sketching and auditing the current product features.

Audit of the current product.

Additionally, the three main products in the platform---a table of data, a network map of data, and a written report---might describe the same underlying findings, but each one was generated and maintained separately.

This resulted in major roadblocks to usability. Users kept multiple tabs open to compare a research table against a network map. They exported CSVs, or our team would use custom scripts when they needed to add a row, change a column, or inspect a smaller slice of the data. The internal team reran similar queries just to let the same data appear in a different format.

The challenge was not to remove flexibility. Flexibility was the point of the platform. The challenge was to decide which affordances should be exposed as product actions and which ones should remain infrastructure. Without that constraint, the interface would become a configuration surface for the backend rather than a usable research product.

Research & Landscape

I used the platform end to end, audited every major surface, and talked with the team conducting research to understand the repeated parts of their work. I also worked closely with engineering during the database redesign so the UI could reflect it.

The key pattern was that research did not behave like a clean pipeline. A project might start nationally, narrow to one state, add a new actor type, generate a report, then run new background research that should update the graph and explain what changed.

Knowledge graph display explorations — comparing where ontology, graph overview, source review, and node detail should appear.

Strategic Directions Considered

Solution

A table, map, report, or summary is not a separate product; it is a view into selected nodes, edges, attributes, sources, and update history.

Project home — one landing page for graph health, active research, recent updates, and available views.

I restructured the project landing page around the state of the underlying model. Instead of sending users into separate products, the home page shows what exists in the graph, what research is running, what changed recently, and which views are available. That gave both internal researchers and end users a shared place to orient themselves before opening a table, map, or report.

Knowledge graph — the data model itself, with nodes and edges users can inspect instead of only seeing source documents.

In the graph, user can inspect entities, relationships, attributes, and source provenance, then narrow the graph into a working slice such as one state within a national dataset. This mattered because the same national research base could support many different project views without rebuilding the data each time.

Node detail — a selected entity keeps relationships, attributes, and source provenance visible in one inspectable view.

Research table — a structured slice of the same graph, optimized for scanning and comparison.

Query workflow — modular steps for adding nodes, edges, attributes, and sources to the graph.

The workflow model broke research into specified, modular steps. Users could search, scope, extract, validate, dedupe, and add to graph without needing to understand the CLI or agent orchestration. Each step exposes inputs, outputs, and the graph change it proposes, so users can pause, rerun, or branch a workflow before committing data.

Project page — ontology and project views stay close together so users understand what kind of data they are creating.

Report view — narrative output connected to live data, with top-line update summaries when research changes the graph.

Reports were designed to be live outputs of the graph rather than static deliverables. When research ran in the background, the project could surface top-line summaries of what changed: new entities, changed relationships, stronger evidence, or gaps that still needed review.

Key Decisions

Considered

Keeping tables, maps, and reports as separate product areas.

Chose

Unify them as views of one graph-backed project.

Because

Users were already comparing those views manually. The product needed to make that relationship explicit.

Trade-off

The landing page had to explain more system state up front. I handled that by organizing around model status, active work, and view entry points.

Considered

Making graph edits mostly conversational.

Chose

Use modular workflows with explicit inputs, proposed changes, validation, and commit points.

Because

Adding a node or edge changes the shared source of truth. Users needed clarity before the system mutated the graph.

Trade-off

More structure than chat. Worth it because the workflow becomes understandable, repeatable, and reviewable.

Considered

Expose the full set of platform affordances as configurable controls.

Chose

Translate platform primitives into opinionated product actions: scope, extract, validate, dedupe, commit, and view.

Because

The users needed to accomplish research tasks, not assemble the underlying orchestration system.

Trade-off

Some edge-case flexibility moved out of the main flow. That made the primary experience easier to trust and easier to repeat.

Considered

Showing reports as final artifacts after each research run.

Chose

Connect reports to live graph updates and summarize changes at the project level.

Because

Background research is only useful if users can tell what changed without rereading the whole report.

Trade-off

Requires careful update hierarchy so users see material changes without alert fatigue.

Reflection

• Users could work with slices — a national dataset could be narrowed to one state, one actor type, or one relationship pattern without creating a separate project.
• The internal team had fewer bespoke runs — repeated research patterns became reusable workflow steps instead of one-off CLI work.
• Reports stayed connected to research — background updates could surface as top-line project summaries instead of buried regenerated outputs.
• The data model became inspectable — users could see how sources became nodes, edges, attributes, tables, maps, and report claims.

The biggest lesson was that flexibility needed to be balanced with clarity, and not every single parameter and affordance needed to be exposed to the user. This work gave the founders and engineering team a clearer product architecture for the redesign: one research model underneath, with distinct user-facing surfaces for orientation, exploration, reporting, and graph updates.

It also created an incremental roadmap. Some work depended on the graph-backed data model, while smaller UI improvements, like pinned outputs, clearer page hierarchy, better labels, source counts, search/filter consistency, and update summaries—could improve the current product sooner. Most importantly, the redesign shifted the product from a set of generated research artifacts toward a workspace where users could understand, slice, and safely change a shared body of research.