Building the operator workspace · Manufacturing · Enterprise AI

Designing the operator workspace

Operator and supervisor tools for a factory floor, one of three products I designed in a manufacturing AI program.

Operator workspace
Team
Sole designer
Timeline
10 months
Worked with
PM, AI engineering, data science
Status
Shipped

My role & impact

Product Designer, sole designer on each product, working with the PM, AI engineers, and data scientists.

  • Sole designer on all three products in a shipped program credited with 10–25% productivity gains.
  • Owned the operator workspace end to end, from desktop through tablet
  • Built a clickable prototype used in a senior-leadership presentation
  • A stakeholder recommendation, off the back of my work, led to a follow-on engagement

My responsibilities

  • Information architecture
  • Interaction design
  • Responsive design
  • Visual design
  • Prototyping
  • Stakeholder alignment
Table of Contents
  1. The brief
  2. Approach
  3. The design
  4. What I got wrong
  5. What changed
  6. Reflections

The brief

Design AI-assisted tools for a factory floor.

The work was to design the surfaces for a set of AI capabilities being built for a factory floor: tools for the operators running production and the supervisors overseeing it. I was the sole designer on each product, new to manufacturing, and the suite kept growing as I worked across it.

One condition shaped everything: I didn't have access to the people I was designing for. I never observed an operator on any of the three products. So the central question wasn't which screens to draw. It was how to design a floor tool well when you can't watch the floor.

Approach

With no users to test against, I leaned on the people who knew them, and on a visual system that already existed.

I made the team my window into the floor. The AI engineers, the data scientist, and the PM had prior exposure to operators and the realities of the environment, and I treated their knowledge as the closest thing to observation I had. Where I'd normally test an assumption with a user, I checked it with them.

I also didn't start from a blank canvas. A senior designer had built an earlier manufacturing app, and I took that as my reference: a loose UI kit and a shared visual language I carried into the products I designed, so the suite stayed cohesive. The dark theme was already set before I arrived. Working inside an established system, rather than inventing one, was the right call for a fast, multi-product program, and it kept the three products feeling like one family.

Where I couldn't verify, I designed conservatively. Clear states, generous spacing, and the two habits I fall back on when I can't test: show only what matters on a busy screen, and follow patterns people already recognize so nothing needs learning.

The design

One product, shown in depth. The operator's home screen for a shift, with AI support kept one tap away.

The operator workspace is the "what do I do right now" surface for a shift. It brings the shift's plan, handover notes from the previous shift, current performance, and prioritized alerts into one view, so an operator isn't stitching the picture together from separate tools.

The AI support sits in a drawer beside the plan rather than on the screen permanently. That placement was proposed by the stakeholders, and I agreed with it for a specific reason: an operator mid-shift shouldn't have an assistant taking up space until they actually want it. A drawer keeps the workspace focused on the work and the help one tap away, summoned when needed, gone when not.

The operator workspace: a shift plan, handover notes, current performance, and prioritized alerts in one view, with an AI support drawer open at the right.
The operator workspace. AI support sits in a drawer, summoned when needed.
The operator workspace: a shift plan, handover notes, current performance, and prioritized alerts in one view, with an AI support drawer open at the right.

What I got wrong

I'd sized the desktop for an office mouse. Operators use it on the floor, in gloves, so a surface I'd finished was wrong.

I started on desktop, picturing supervisors and in-office use, and sized the controls accordingly: normal targets for a precise mouse. When the brief extended to tablet for operators on the floor, I sized those targets for touch and considered it handled.

Then, in a conversation, an AI engineer mentioned that operators often work in gloves. That one comment undid an assumption I hadn't noticed I was making. I'd treated "desktop" as "office," but operators use desktop on the floor too, sometimes gloved, so the precise-mouse targets I'd already signed off on were too small for the people actually using them. I went back and resized targets across both form factors: bigger hit areas, clearer state changes, spacing that assumes imprecise input.

The fix itself was small. What mattered was that it surfaced in time, and it surfaced because the people who knew the floor were close enough to catch it.

What changed

  • Owned the operator workspace across desktop and tablet
  • Kept AI support in a summonable drawer, present at the point of work without crowding it
  • Resized touch targets across form factors once I learned operators work gloved
  • Carried an existing manufacturing UI kit across the products I designed, keeping the suite cohesive

Reflections

When you can't watch the users, stay close to the people who can.

I never observed an operator, so the team was my read on the floor. The gloves detail is the proof it worked: it reached me through them, in time to fix the targets before ship. Staying close to the people who know the environment surfaces what you'd otherwise miss.

Designing inside someone else's system is its own skill.

A senior designer's earlier manufacturing app gave me a UI kit and a visual language to build on. Extending it well, so three products felt like one family, mattered more here than inventing something new.