Product systems / Confidential client work

Operational
Visibility.

Scan first.
Inspect second.
Analyze third.

A confidential operational product system that turns a small set of station events into a shared, role-aware view of what needs attention across a manufacturing floor.

Get the short version

AI-generated contextual reconstruction

Conceptual isometric illustration of a fictional small manufacturing floor grouped into three areas, with teal, amber, and coral station indicators and an abstract station-to-area-to-facility rollup.
AI-generated contextual reconstruction illustrating station conditions rolling into area and facility awareness. It does not depict a client facility, production interface, or real operational data.
Less noise. A clearer picture.

My role

Connect the system.
Clarify the decisions.

As Lead UX Designer at Big Room Technologies, I designed workflows and a shared design system for a manufacturing client.

My contribution

  • Product architecture
  • Operational UX
  • Interaction design
  • Prototyping and handoff

In progress

Production implementation, testing, adoption, and operational impact remain unverified.

The short version.

The system, in a minute.

01

Problem

Paper, radios, walk-throughs, spreadsheets, and individual memory gave each role a partial view of the floor, but not a shared operational picture.

Read the chapter

02

Approach

I started with what the product could know reliably: badge activity, Working / Idle / Down state changes, timestamps, and a reason only when a Down state needed context.

Read the chapter

03

Solution

Those events roll from station to area to facility through one state language and one progressive path: scan first, inspect second, analyze third.

Read the chapter

04

Outcome

The work produced a confidential, in-progress product framework and high-fidelity prototypes for stakeholder alignment and developer handoff. Production use, testing, and measurable impact remain unverified.

Read the chapter

The guided story

From isolated floor signals to shared operational visibility

At Big Room Technologies, a software agency, I design enterprise systems for a manufacturing client. This public reconstruction explains the design logic without exposing the client's screens, processes, or data. It is not a demonstration of the deployed software.

01PROBLEM

Local knowledge did not become shared visibility

Operators, supervisors, and managers could each understand part of the floor through observation, radio calls, conversations, paper, spreadsheets, and memory. Those perspectives did not automatically become one trustworthy view of what was happening or where attention was required.

AI-generated contextual reconstruction

Conceptual isometric illustration of a fictional small manufacturing floor grouped into three areas, with teal, amber, and coral station indicators and an abstract station-to-area-to-facility rollup.
AI-generated contextual reconstruction illustrating station conditions rolling into area and facility awareness. It does not depict a client facility, production interface, or real operational data.
02PROCESS / SOURCE SIGNAL

Begin with the smallest reliable signal

The product could depend on only a few events: badge activity, a station-state change, its timestamp, and a reason when a Down condition required explanation.

AI-generated contextual reconstruction

Anonymous gloved hand presenting an unbranded badge to a fictional rugged workstation terminal with teal, amber, and coral status controls.
AI-generated conceptual illustration of a minimal badge-and-status interaction. It does not depict a real employee, workstation, client interface, or implemented hardware.
03OPERATING MODEL / STATE LANGUAGE

Three states create one operating language

Working, Idle, and Down provide a small shared vocabulary across operator input, station cards, filters, summaries, alerts, history, and future analysis. Timestamps and Down reasons preserve context without expanding routine reporting.

RECONSTRUCTED SYSTEM DIAGRAM

Three-state operating model

One shared language.

Working

Active station state

TimestampReason when Down

Tap a state to inspect its meaning.

Reconstructed three-state operating model. Timestamp and Down reason support the primary states; no client interface, values, or production behavior is shown.
04DECISION / CONNECTED HIERARCHY

Let detail roll upward without losing its source

A station event creates the current state and interval history. Station conditions roll into area summaries, and area conditions roll into facility awareness while users retain a path back to the originating event.

RECONSTRUCTED SYSTEM DIAGRAM

Event rollup hierarchy

  1. 01

    Badge / status event

    Small reliable source signal

  2. 02

    Station

    Current state and interval history

  3. 03

    Area

    Conditions grouped in context

  4. 04

    Facility

    Shared awareness across areas

Alerts

Conditions needing attention

Activity

Recent event record

Analysis

Historical questions; unverified

↶ Each summary retains a path back to its source event

Reconstructed event-to-facility hierarchy showing shared derivation and traceability. It is a system model, not a production architecture or client dashboard.
05DECISION / PROGRESSIVE DISCLOSURE

Scan first. Inspect second. Analyze third.

Managers begin with a facility-level scan, inspect an area or station without losing context, and open deeper history only when necessary. Each layer answers a different question instead of repeating every detail.

RECONSTRUCTED / ANONYMIZED INTERFACE

Progressive investigation path

  1. 01 / SCAN

    SAMPLE FACILITY

    Recognize where attention may be needed

  2. 02 / INSPECT

    AREA A / STATION 01

    Review condition without losing context

  3. 03 / ANALYZE

    FULL HISTORY

    Open deeper history only when necessary

Reconstructed progressive-disclosure sequence using generic labels only. It illustrates verified interaction logic, not the appearance or implementation of a client interface.
06DECISION / TIME HORIZON

Separate what needs attention now from what explains a pattern

Current condition, alerts, and recent activity support immediate work. Historical comparisons and trends belong in analysis. Separating them prevents every event from appearing urgent and keeps overview screens scannable.

RECONSTRUCTED SYSTEM DIAGRAM

Current and historical questions

NOW

  • Current condition
  • Active alerts
  • Recent activity

Supports immediate operational attention.

OVER TIME

  • History
  • Comparison
  • Recurring patterns

Historical analysis is proposed and implementation remains unverified.

Reconstructed separation between immediate and historical questions. Historical analysis is proposed; implementation and production use remain unverified.
07CURRENT STATE / PRODUCT DEFINITION

Use prototypes to define the system before rules harden

High-fidelity prototypes connected facility, area, station, operator, and administrative journeys while exposing unresolved behavior, terminology, ownership, and metric definitions for stakeholder review and developer handoff.

RECONSTRUCTED / ANONYMIZED INTERFACE

Product-definition artifact board

STATE MODEL

  • Working
  • Idle
  • Down

CONNECTED HIERARCHY

  • Station
  • Area
  • Facility

OPERATOR FLOW

  • Badge event
  • Status change
  • Down reason when needed

INVESTIGATION PATH

  • Scan
  • Inspect
  • Analyze

COMMENTS / SHIFT HANDOFF

  • Ownership unresolved
  • Behavior needs verification

PROVISIONAL CONCEPT

Reconstructed and anonymized artifact board assembling verified product logic. Comments and shift handoff remain provisional; the board is not a client deliverable or production interface.

What the work established

A coherent product architecture built from limited signals

The work established a shared state model, connected facility-to-station hierarchy, role-aware workflows, progressive investigation, current-versus-historical separation, and reusable interaction patterns for stakeholder alignment and developer handoff. Its strongest demonstrated outcome is the product architecture itself—not a claim of production adoption or measured operational improvement.

CONFIDENTIALITY AND MATURITY LIMIT

Public visuals are reconstructed and anonymized. Exact production status, usability testing, adoption, and operational impact remain unverified, so this case study documents design judgment and system structure rather than client results.

Clarity starts with a shared language.

Keep exploring

Another kind of signal.

SignalOS — a personal research tool for deciding what deserves a closer look.

Next case study

Let’s make something
worth caring about.

Open to staff and lead product design roles, design engineering, and creative technology collaborations in Greater Boston and remotely.

Say hello on LinkedIn ↗Download my résumé ↓See what I’m building on GitHub ↗