Providing a Consistent Overview
Redesigned header that makes it easy for users to quickly and confidently understand the task at hand
Understanding the Header
A Small Component With a Big Job
The Problem
A Hodgepodge with No Clear Hierarchy
The current header lacks a consistent organizing framework in terms of its contents and how that content is visually presented, making it difficult to quickly scan and understand.
The header's presence across Work Order pages, and its role in providing easy access to essential, frequently referenced information made this redesign a high-impact opportunity for improving product clarity and consistency.
Our Goal
Make it easy for users to quickly and confidently understand the task at hand
Research
Audit
I started by documenting every existing header state. There were a lot. With all the permutations, there were more than 30!
Static information about parts and customers sat alongside dynamic status and alert information without clear differentiation. Alert information was not consistent, either in content or placement. So many opportunities for improvement!
The audit helped me understand the full range of scenarios the header needed to support, from a simple situation where work had not yet begun to a complex situation with work underway, multiple active alerts, and multiple user-created tags.
A selection of different Header alerts and statuses
Consider Customer Priorities
First Iteration
Static vs. Dynamic Information
I began iterating and explored separating alert and status information from static “who, what, and where” information.
I gave alerts a consistent home and experimented with visual hierarchy options for different types of content.
Stakeholder Feedback
Static is King
Stakeholders strongly agreed with a consistent home for alerts because this provides predictability and improves noticeability.
They thought static “who, what, and where” information should receive greater priority because it provides context and is always present. Dynamic content such as alerts and status should appear beneath where they can provide descriptive details.
Stakeholders thought actions should also be contextually specific.
Second Iteration
Structure & Hierarchy
I reorganized the header so that static information received visual priority, and I experimented with giving elements of static information less visual prominence.
I experimented with ways to provide dynamic information as well as actions in a context-specific manner.
I also began considering how this system would adapt to smaller screen sizes, like tablets.
Desktop
Tablet
Stakeholder Feedback
Actually, It's Parts
As I reviewed designs with Stakeholders, it became apparent that floorworkers orient around parts rather than work orders.
Our visual hierarchy needed to reflect that parts should be the center point.
Third Iteration
Refocus on User Priorities
I rethought the design to give visual prominence to the part being built.
I also reorganized the presentation of static information so that all of it consistently appeared above dynamic information, ensuring a clear separation from statuses and alerts.
Stakeholder Feedback
But What Can I Do?
When sharing the design with Leadership and Sales, it became clear that key actions need to be immediately visible so they can't live in an overflow menu.
I needed to find them a home.
Fourth Iteration
Easy Access to Actions
I created a new design that included a dedicated, always visible place for actions so that users could quickly understand what was possible and get work done.
Wait, There's More
I reviewed the design with Engineering and uncovered additional scenarios that needed to be addressed. We're talking alerts that I didn't know existed!
Learning that we had lots of new alerts made it clear that we needed an alerts framework to effectively communicate information and cue appropriate actions.
Fifth Iteration
Finalize the Structure
My final iteration addressed identified issues and clarified the system, creating a clear, predictable structure that scales across scenarios.
Alerts have a dedicated bar that only appears when an alert is active
Alert styling varies based on severity and required action
Status information appears in a persistent area, separate from alerts
Introducing a New & Improved Header
A Scalable Solution
Works for multiple scenarios
Accommodates the full range of scenarios, from a simple situation where work has not yet begun to complex situations with work underway, multiple active alerts, and multiple user-created tags.
Header with no alerts and minimal status information
Header with multiple alerts and many types of status
Visual Hierarchy Aligns
Part is prioritized
Because floorworkers orient around parts, the design gives visual prominence to the part being built.
Predictable & Findable
A Home for Everything
Alerts are presented in a dedicated area that only appears when an alert is active.
Status information appears in a persistent area, separate from alerts.
Context-specific actions live in a dedicated, always visible place so that users can quickly understand what is possible and get work done.
Alerts
Status information
Context-specific actions
Time to Build!
I created a developer hand-off document that described the new header design and how it should behave across different scenarios.
While we were collaborating, the developer and I uncovered two edge cases that needed to be accounted for in the design, so there was rapid turn-around involved.
The project was on a fast timeline, and my development partner worked at lightning speed to complete the project in less than two weeks!
Cetec Version 4.23
Expected Release Q4-2026
Final Thoughts
This project was an opportunity to build my rapid iteration muscle. I learned to become comfortable with ambiguity and constant change as the team thought through priorities and worked against a tight timeline.
In addition, we fit this work in alongside other ongoing efforts, so I learned to juggle my time and my thought processes as I moved back and forth between design efforts.
