Case Study 1

WFM Software Dashboard Redesign

… about redesigning the dashboard of a Workforce-Management Software by including User Roles, accessibility and adaptable and flexible components

In House

2025

Assist Digital

Overview

Product

Product

Product

Workforce-Management Software suited for Call Center Purposes

My Role

My Role

My Role

  • UX Strategy

  • UX Research

  • UX Design

  • UI Design
    - short: UX Team of One!

Team

Team

Team

me, myself and I

Tools

Tools

Tools

Figma

FigJam

ChatGPT

Google
Docs

Pen+Paper

Methods

Methods

Methods

Exploration
  • User Stories

  • "How might we…" Statements

  • Problem Statement

  • User Journey

Ideation
  • Low-Fi Wireframes

  • Low-Fi Wireflow

Final Design
  • High-Fi Prototype

  • High-Fi Wireflow

  • Deliverables

Objective

Objective

Objective

This concept was created for a former employer:

For the upcoming major release of the software, the dashboard needed to be redesigned with a strong user-centered focus. The system was originally built solely for time tracking, and additional workforce-management features had been added gradually over time.

As a result, the existing dashboard still only reflected time-tracking functionality. Since not all user roles relied on this feature, the dashboard no longer aligned with the actual needs of its users. The goal of this project was to address this gap and transform the dashboard from merely functional to genuinely useful, ensuring that each user group received relevant, meaningful information at a glance.

Read about my detailed design process below.

Ready for a deeper look?

This case study includes long-form content, complex layouts, and detailed visuals that are best experienced on tablets or desktops.
On mobile, you’ll find the overview and a short walkthrough video — perfect for getting the big picture.

bigger device

bigger device

on a

and read this

to your eyes

to your eyes

Be nice

Be nice

Exploration

As outlined in the design brief, a major driver for the redesign was ensuring that the dashboard would meet the needs of all user roles. The extent to which this had not been the case so far became evident from the fact that users working with the autonomous shift distribution feature didn’t even access the dashboard at all — instead, they started with an alternative view after logging in.

To refresh my understanding, I revisited the insights gathered in an earlier User Research campaign:

Personas

Design Mantras

Compilation of identified pain points

During this process, I noticed that the available information regarding the manager (WFM) role was still too superficial to derive meaningful design decisions from it. Since no additional user research was planned for this project cycle, I decided — in alignment with the Product Owner — to focus in this cycle on the employee (MA) and team lead (TL) roles.

Design Mantras

Visibility of System Status

“Keep users informed about what is going on, through appropriate feedback within a reasonable amount of time.”

Hick’s Law

“The time it takes to make a decision increases with the number and complexity of choices.”

Postel’s Law

“Be liberal in what you accept, and conservative in what you send.”

Design Thinking

Using Design Thinking methods as
 "User Stories" and "How might we..." statements led me to ask myself a few key questions:

?

What is a dashboard actually for?

!

A dashboard should provide a smooth and intuitive starting point for using the application.

?

How can a dashboard achieve that?

!

For workforce management, it needs to offer a clear overview of the here and now, helping employees and team leads navigate the tool more easily.

The phrase “here and now” turned out to be a big aha! moment for me — one that ultimately shaped my problem statement.

PROBLEM STATEMENT

How might we

redesign the Dashboard of the WFM-Software

so that

all user roles can quickly gain an overview of the "here and now"?
(hierarchical and autonomous employees and team leads)

We’ll know we’ve achieved this when

all users actually start their session with the dashboard.

I concluded the exploration phase with user journeys. From that I gained the following starting points:

1

I noticed that a lot of potential for user satisfaction was being lost because key information wasn’t readily available — users had to actively search for it themselves.

2

Another major source of frustration was time stamping, which carried a negative connotation. As a result, it was often avoided, creating additional work for other user roles.

3

As the “Daily Plan” page was the most frequently used view among all teamleads as well as autonomous employees, it would be valuable to adopt some of its qualities for the new dashboard.

UX Design Process

There was quite a bit of work! Since we had two shift-distribution concepts and two user roles (employees and team leads), we needed to create four separate dashboard variants.

Dashboard Variant 1: Hierarchical Employee

Let’s start with the version closest to the original application: the dashboard for employees in the hierarchical shift-distribution model. As a reminder, this user group recorded their working hours by clocking in and out within the system.

For this concept, I used my favorite tools — pen and paper. Still the best way to think (and even scientifically proven!). I also followed a mobile-first approach. Although the product had mainly been used on desktop so far, the user interviews clearly showed a demand for a mobile version. So it made perfect sense.

concept Decision
Idea 1

Using an analog clock and a visible redesign to send a clear signal to users: something is changing

Leveraging the analog display to create positive associations — in our fast-paced, high-efficiency world non-digital objects evoke familiarity, clarity, and a sense of comfort

Communication between development and design is still in its early stages — implementation carries a high risk of things going wrong

Vs
Idea 2

Largely retaining the original framework to support recognition for existing users

Reduction of development effort

Providing more structural components for communicating information

Less flexibility for visual design

Since implementation cost is a key factor, this strategy ultimately prevails

Via a Workflow I collected all ideated improvements in one overview.

Key Considerations

The clock-in process should reflect employees’ real workflows, so separating shift start, shift end, and breaks is essential.

User actions should be visible through micro-animations to support visibility of system status (e.g., a timestamp appearing in the daily view).

The system should support clocking in and out through gentle nudges, such as a bouncing button near shift start or end.

User-relevant shift information (planned, completed, remaining) should be clearly displayed.

The system architecture should connect related elements to ensure intuitive navigation.

Dashboard Variant 2: Autonomous Employee

I then developed the dashboard for employees in the autonomous shift-distribution model. This user group did not record their working hours by clocking in or out. Instead, they used the system to access team-wide views for assigning shift intervals.

Key Considerations

Hiding all time-tracking elements

Iteration of "Internal Daily View":

Add today’s staffing needs so users can quickly and independently respond to shortages.

Ensure consistency by using existing view patterns already applied elsewhere in the system.

Provide an accessible display option for this element.

Present system-generated tasks in a structured way to increase efficiency and reduce the need for manual initiative via a task board

Dashboard Variant 3: Hierarchical Teamlead

For teamleads, the iterations and development of entirely new elements represents a meaningful step forward, as they will finally have access to a useful dashboard. In the hierarchical shift-distribution model, team leads do not perform time tracking themselves. Their needs are primarily reactive and organizational.

Key Considerations

Developing an "Attendance Overview":

Provide a view of the team’s current attendance status

Reuse existing patterns from the daily view for visual consistency

Display attendance by time interval to reduce mental load

Dashboard Variant 4: Autonomous Teamlead

The dashboard needs of team leads in both the hierarchical and autonomous shift-distribution models were largely the same. Neither user group performs time tracking through clocking in. Both must be able to see team attendance at any given moment. Only team leads in the autonomous model additionally need insight into staffing needs, as these can shift throughout the day.

Key Considerations

Display staffing needs within the internal daily view

Final Design

My ideation process led me to a solution that introduced four core interaction elements for the dashboard:

Time Tracking

Internal Daily View

Task Board

Attendance Overview

These elements could be shown or hidden depending on shift model and user role, each offering its own user-specific variation.

The major advantage of this approach was that it created a robust foundation for future iterations. Its layout served as an early form of a bento-grid structure, allowing the interface to remain flexible, responsive, and expandable. This makes it possible to add additional elements later on, supporting the need for personalization expressed in the user interviews.

REsponsiveness

The new dashboard concept was developed with a strong focus on responsiveness. Since the existing system contained many points of friction and errors in this area, a truly responsive dashboard would directly improve overall usability.

For the final submission, I focused on unambiguous, straightforward presentations — regardless of potential software features — because transferring Figma designs into the product had previously been a common source of errors.

Tiny style sheet

With this project—my first opportunity to make intentional decisions about the user interface concept—I created the foundation for a style sheet. It consisted of core UI building blocks such as:

Color Sheme

Icon Library (initially project-specific)

Button Component (hierarchy, states, device variants)

The goal was to establish the fundamentals for consistent design implementation and to build a design system that could evolve with each new project and redesign.

Thank You

Thanks for spending a moment with this case study.
If you’d like to chat, I’d be happy to connect.