Title Hub

The Operating Model

Title Hub did not replace a single tool. Before it, the operation ran on a scattered stack — six broad areas of work, each split across different applications, spreadsheets and human memory. The design task was not to consolidate tools; it was to change the unit around which work is organized.

Title Hub did not simply consolidate tools. It changed the unit around which work was organized — from applications and departments to the operational file.

The Challenge

Employees were not struggling because Outlook was bad. They were struggling because work itself was fragmented — the operational knowledge that kept files moving lived inside people's heads and across a dozen systems, not inside a product. The clearest way to feel this is to follow a single, ordinary task.

Nine steps, six tools, and repeated jumps backward — for one file, many times a day, across every department.

Framed correctly, this was an organizational transformation problem. The interface would only ever be the visible outcome of getting the operating model right.

The Organization

Before designing a single screen, the work was to understand the operation itself: its departments, the roles inside them, how a file moves between them, who owns each step, where decisions are made and where information enters and leaves. The product could only ever be as good as this understanding.

Operations are organized by jurisdiction and product line — each department runs its own boards and queues, yet they share files, data and clients. The product had to respect this structure while making the whole legible.

Departments and roles don't work in isolation — a file passes between them, and information, data and decisions flow across the boundaries. Mapping these relationships showed why point solutions couldn't work, and why the operation needed a shared operating layer rather than better-integrated tools.

A single file crosses hands and departments through a defined lifecycle. Above the line is the role that owns each stage; below it, the information and artifacts the stage depends on. Mapping this became the backbone the product was later organized around.

The same file is touched by several actors with different responsibilities, visibility and moments of action. Making this explicit is what later justified role-based views and a permissions layer rather than one screen for everyone.

Research

This was product discovery, not UX research in isolation. I met with department managers and operational employees, observed real workflows, mapped how work moved across departments, documented bottlenecks and ownership, identified repeated manual work, studied communication patterns, and learned which information each role actually needed.

Recurring patterns across interviews and observation — reconstructed here, not quoted verbatim.

Each observed behavior was traced to the operational problem underneath it, and then to the product opportunity it pointed at. This is the bridge from research to strategy.

From Research to Product Strategy

Findings on their own don't build a product. The real work is the translation: each observed problem becomes a product decision, justified by a reason, and delivered as a platform capability. This decision framework is where the product strategy is actually defined — before a single screen exists.

The findings pointed at a fork. Three approaches were genuinely on the table, and the whole platform depended on which one we committed to.

We selected Option B. Tasks, emails and documents are all just facets of a file — organizing around any single facet would have left the others fragmented. Only the file could hold the whole.

Why the File?

Everything else in Title Hub follows from a single choice about the unit of work. Rather than asking people to move between systems, we moved the systems around the file: every capability the operation needed became an attribute of the file itself.

Instead of asking employees to move between systems, we moved the systems around the file.

The Architecture

With the file as the organizing unit, the platform was structured as three layers: core navigation that orients any role, file-workspace modules that carry a file's context, and platform services that operate across every file. This architecture is what let dozens of capabilities feel like one product — and what made role-based access and permissions coherent rather than bolted on.

Separating the cross-cutting foundation from the product domains was a deliberate architectural decision: it let each domain evolve independently while permissions, search, notifications and activity stayed consistent everywhere.

Which surfaces the most important truth about Title Hub: it is not one product. On the shared foundation sit three distinct products, each serving a different job.

Everything Connects to the File

If there is one diagram to remember, it is this. Every capability the operation needs — communication, documents and data, workflow and governance — is an attribute of the file. And because it all lives on one model, both products are just different views onto it: the internal HUB executes the work, the portal exposes a controlled read of it.

One file, every capability, two products — this is why the whole platform holds together.

Extending the Platform Beyond Internal Users

While the HUB served internal operational teams, I also designed a lightweight portal for external departments, management and business stakeholders. Instead of exposing the full operational workspace, the portal offers controlled, read-oriented visibility into file progress, communication and outstanding issues — built on the same underlying data model with role-based permissions. Same data, a different audience, far fewer actions.

Three Product Domains

Read separately, each domain is a complete product with its own users, problems and design story. What follows is the deeper story of each — how work gets done, how data becomes trustworthy, and how the operation is managed.

The workspace is where readers execute work. The design problem was to give each person a single place to see what they own, work a file end-to-end, and communicate — without leaving the file. The board organizes every file by priority, state, questions, proofing and flow status; the role-based home surfaces exactly the queues a person is responsible for.

Operational data is only useful if it can be trusted. This domain turns manual cross-checking into a review workflow: the system surfaces and compares data on the file, flags what doesn't match or is unknown, and keeps a human in the loop for the decision. The checklist on the file makes each validation step — and its state — explicit.

Rather than automate blindly, the interface encodes a simple decision model so a reviewer always knows what a value needs.

Managers do a fundamentally different job than readers, so they need a fundamentally different view of the same data. This domain is about seeing the whole: workload across people, where files are stuck, what needs attention, and the health of the operation — with the controls to assign, rebalance and unblock.

The Design System

That is the only question this section answers. The design system was less about color and type than about a small set of operational patterns — each defined once, then reused across every domain. The payoff was threefold: consistency (a table behaves the same everywhere), scale (a new module is assembled from known parts, not designed from scratch), and maintainability (fix a pattern once and every module inherits it).

Where It Stands

Title Hub shipped and is in daily use. It replaced the scattered mix of tools with a single operational home, now relied on by hundreds of people across multiple departments and offices — including New Jersey and New York — up to manager level. It was adopted well across the teams it was built for, and it keeps growing as new operational needs are added.