Product Domain 03 · Enterprise Management Design

Operational Visibility & Management

Making invisible operational work visible

Most operational work is invisible — it lives inside people's queues and inboxes, surfacing only when something goes wrong. This domain is about making that work visible: turning scattered activity into a picture a manager can read, and giving them the controls to assign, rebalance and unblock before problems bite.

VisibilityWorkloadBottlenecksRoles & permissionsAssignmentDepartment overview

The Business Problem

You cannot manage what you cannot see

With work spread across tools, the operation was effectively invisible to the people running it. Managers couldn't answer the questions their job depends on — who is overloaded, where is a file stuck, what needs a decision today — so management was reactive, discovering problems only after someone raised them. The design problem wasn't ‘build dashboards’; it was make invisible work visible.

Users

Who runs the operation

Team Manager

Runs a team's files. Goal: keep work flowing — assign, rebalance and clear bottlenecks before they bite.

Administrator

Owns roles, permissions and configuration. Goal: keep visibility and control coherent as the org grows.

One operation, four lenses

The same work, seen differently by each role

The insight that shaped this domain: the operation is a single body of work, but every level of responsibility needs to see it at a different resolution. The product frames the same underlying data as the lens the viewer's job requires.

Employee

My work

One person's owned files and next actions.

Department

Team & queues

A manager's team: workload, stages, bottlenecks.

Cross-department

The operation

Files moving across departments and hand-offs.

Executive

Health

The shape and health of the whole operation.

Workflow

How a manager steers

See

The whole operation

One view of every file, owner and stage.

Diagnose

Spot the risk

Read workload and bottlenecks at a glance.

Assign

Balance the work

Assign and rebalance across the team.

Unblock

Clear the path

Act on what's stuck or waiting on a decision.

Review

Approve & close

Sign off and keep the operation moving.

Product Decisions

Every decision answers: what operational problem forced it?

Decision: Give managers a separate product — not the employee view with more columns.

Reasoning

Manager needs differ in kind, not degree; a compromised single view fails both roles.

Trade-off

Two views on the same data to design and maintain.

Outcome

Managers read the operation at a glance instead of row by row.

Rejected alternativeThe employee view with extra columns — one view compromised for both roles would serve neither well.

Decision: Progress is computed from workflow state — not from manual status reports.

Reasoning

Managers were chasing employees for updates just to see where work stood.

Trade-off

Less flexibility for custom, narrative reporting.

Outcome

Reliable, real-time visibility with no reporting overhead.

Rejected alternativeManual status updates / weekly reports — they go stale, cost employee time, and make progress a story instead of a fact.

Decision: Group files by real workflow stage.

Reasoning

A manager reads state — In Progress, Awaiting Search, On Hold — not individual rows.

Trade-off

Requires a shared, accurate stage model.

Outcome

Bottlenecks are visible as a shape, not found by scanning.

Rejected alternativeA flat sortable list — bottlenecks would have to be hunted for instead of seen at a glance.

Decision: Make ownership and flow status primary.

Reasoning

The manager's first questions are always ‘who’ and ‘where’.

Trade-off

Those columns take prime real estate from detail.

Outcome

The two questions that matter most are answered first.

Rejected alternativeDetail-first columns — the manager's first questions would be buried below the fold.

Decision: Model roles and permissions as platform structure.

Reasoning

What each role sees and can do must stay coherent as the org grows.

Trade-off

A permissions model to build and govern.

Outcome

Visibility and control scale with the organization, not against it.

Rejected alternativeAd-hoc per-screen visibility rules — visibility and control would fragment as the organization grew.

Wireframes

Iteration as a record of decisions

The structure moved from a flat file list toward a stage-grouped operational view with ownership and workload up front.

Iteration 1

A flat, sortable list — too much to scan.

Iteration 2

Grouped by stage; ownership surfaced.

Final

Stage groups, workload and flow status first.

Final UI

Problem → screen → decision

The operation at a glance

Manager view — every file, grouped by stage

Problem

A manager couldn't see, in one place, where work stood across the team.

In the screen

All files, assignments and flow status grouped by stage (In Progress, Awaiting Search, On Hold), with priority and attachments visible.

Decision: Group by workflow stage and lead with ownership — read the operation as a shape.

Department overview

Boards and open work across departments

Problem

Managers needed to move between departments without losing the thread.

In the screen

Each department's boards and open work are surfaced together, adapting to what the manager oversees.

Decision: Frame the same data by responsibility — a manager sees departments, a reader sees their queue.

Impact on the Platform

What this domain changed

Operational Visibility gave managers a way to run the operation — not just a nicer employee view. It is the domain that demonstrates enterprise management design, and it closes the loop: the workspace does the work, validation makes the data trustworthy, and management steers the whole.