Research preparations

Generative research was necessary, as the team lacked insights into users' primary tasks when managing their schedules on the app. Meanwhile, the team also had to proceed with the re-engineering efforts, which included a necessary design overhaul of the shift details screen.

Though my original plan was to use the insights gathered from the generative research during redesign and then test the solution, I had to do generative and evaluative research in parallel due to time pressure.

Scoping the generative part of the research

To establish a generative research goal, I did a brainstorming workshop with our PM and Tech Leads using Julia Cowing's Customer Question Board framework. The goal was to identify our knowledge gaps about our users' scheduling behaviors.

Research questions categorized into research methodology quadrants and organized into similar topics.

Based on the outcome of the workshop I created a two-part research plan:

• Interviews and contextual inquiries with Shift Workers to understand how they manage their schedule and how the app fits into their workflow. This was the main focus of the research because Shift Workers were our largest user base (around 85%).
• Interviews with Schedule Managers to learn about their main tasks during schedule management.

Apart from the qualitative research plan, I converted the quantitative behavioral research questions into events we had to implement tracking for so we could conduct analytics on the scheduling features.

Note: The original scope included a survey to gauge Shift Workers' preferences toward certain schedule management features which we had to scrap due to a lack of proper survey distribution channels.

Interview scripts

I created the interview script for Shift Workers and Schedule Managers and pilot-tested it with 2 users.

Based on the collected questions, the interview script for Shift Workers was focused on preparations for shifts, communicating sickness and absence, and doing shift transactions. The script for Managers comprised questions about schedule management (both long-term planning and ad hoc schedule changes) and handling employee availability.

I pilot-tested the script with 2 Shift Workers who currently use the app. During the testing, I found that those who use the app in Danish might not be familiar with certain product-specific terms in English. Therefore, I rewrote the script to contain both the English and Danish versions of such terms.

You can read the final version of the interview scripts for Shift Workers and Managers.

Scoping the evaluative part of the research

After finishing the preparations for the generative interviews, I started preparing for the second, evaluative part of the research.

The first phase of the redesign focused on the heavily utilized shift details screen, which also encompassed the shift transaction flows. Shift Workers could see basic information about each assigned shift and initiate shift transactions, like swapping shifts with a colleague.

Old version of the shift details screen and the shift swap flow. Screenshots are from the Android version.

As the engineers had to start the refactoring, they needed high-fidelity designs as soon as possible. Though I didn't have time for direct user research before the redesign, I still wanted to base my design decisions on user feedback. Therefore, I conducted internal interviews with Planday colleagues working in customer-facing teams to gather information about our users.

Internal interviews

I interviewed 3 Customer Success consultants about the most important shift information we should display for Shift Workers based on customer feedback.

The main learnings from the interviews were:

• We are legally required to show the exact time when Workers need to take their breaks (not just a summary). Omitting breaks information prevents us from being compliant in many countries, and is particularly an issue for large-scale organizations with strict legal liabilities.
• Many Managers assign shift types (a color-coded tag) to shifts for administrative purposes only. Therefore, most Shift Workers ignore shift types.
• Most content about the shift details gets truncated to one line, which might cause Shift Workers to miss crucial information. This is especially problematic for customers who operate across multiple work sites and use long names for their locations. One of our prospective enterprise customers was about to churn due to this problem.

The internal interviews revealed a major issue that impacted our conversion:

Prototyping: How might we provide richer shift details?

To address the problem of insufficient shift information, I created a layout that provides an overview of work breaks via a shift timeline and removed all text truncation. I also added iconography to make the content more scannable but avoided any major changes to the UI until we gathered more information about user needs.

I created a usability testing script with simple tasks like swapping a shift and messaging a colleague. I couldn't do a pilot test with real users due to time constraints, so I pilot-tested the prototype with 12 internal colleagues via unmoderated usability testing. I made small adjustments, like adding better icon signifiers and automatic navigation transitions.

Design changes on the shift details screen based on the internal interviews and pilot tests.

User interviews & usability tests

Shift Workers comprised 85% of our user base, so we focused on gathering their input, while Managers were a secondary target group. We recruited 5 Shift Workers and 2 Managers, all working within hospitality (our main target industry).

I also involved our developers as note-takers in the research process to educate them about our users. I interviewed Shift Workers and tested the prototype with them, while Schedule Managers were only interviewed.

Research notes for each participant (E stands for employees and M for managers) organized by topics we covered during the sessions and color-coded based on the type of user feedback. The first two sessions were pilot tests, hence the gray background.

Organizing the findings into topical clusters in an affinity diagram.

After gathering and analyzing the data, we realized that some of our initial assumptions were wrong:

Initial (wrong) assumptions

Research findings

Shift Workers don't care about shift types.

Shift Workers do find shift-type colors useful because they can signal absence or work tasks during the shift.

Shift Workers need to see a detailed overview of their scheduled breaks.

Hospitality employees don't care what time their breaks are officially scheduled because they take breaks irregularly.

Shift Workers benefit from a shortcut to sending messages to their colleagues.

Shift Workers communicate outside of the app and rarely use Planday's messaging system.

Example quotes from users pertaining to the shift details screen.

The scope

After introducing a better way for users to see shift details, we zoomed out to focus on how Shift Workers get an overview of their company's work timetable via Schedule. Schedule was a central calendar displaying the scheduled shifts for all employees across the company.

Old implementation of the Schedule screen. Screenshots are from the iOS app.

Besides refactoring the old codebase, our goal was to understand how Schedule fits into the tasks and workflows of Shift Workers and whether we could simplify our mobile app architecture by merging other functionalities into Schedule.

Compared to the previous phase of the project, which was more generative, this next phase was chiefly evaluative, as we already had some understanding of user preferences and pains. Therefore, I decided to prototype an improved version of Schedule based on the previous findings and do rapid iterative testing.

Preparing for prototype evaluation

I reviewed and summarized the findings from the previous research. The event tracking we implemented also allowed us to conduct analytics on the usage frequency of certain functionalities.

"There's a person who has the same first name as me and sometimes I confuse her shifts with mine."

"I want to know which people I'll be working with so I can mentally prepare for the day."

"It's kind of messy, there are a lot of people and positions. There's no gridline, which makes it hard to match shifts with days."

Besides slow loading times, one of the most mentioned problems with Schedule was the confusing interface, which made it difficult for users to find information (e.g. when trying to find their assigned shifts or looking for a specific person).

Experimenting with new designs for Schedule

To make it easier to find information in Schedule, I experimented with a new layout: instead of showing the employee or position names as horizontal dividers, I created a layout that emulates a spreadsheet with the employee names in the header column.

I planned to test how fast users can find information in the new layout versus the old one by comparing task times.

Different layout versions for testing

I also wanted to find solutions to the other pain points we uncovered during the previous research. Combining the previous findings and the analytics, I came up with some hypotheses that I wanted to test:

Findings from previous research

Design hypothesis

50% of users who enter the date picker screen (with a monthly overview) do not change to a different date range.

Users use the date picker to get a monthly overview of shifts. Replacing it with a dedicated monthly schedule view can help with long-term schedule planning.

1/3 of Shift Workers use the Schedule to look at their assigned shifts specifically (instead of their colleagues’ shifts). Finding assigned shifts is also difficult, especially when the list of employees is long.

Placing the user's assigned shifts at the top of the screen will decrease unnecessary scrolling when searching for their shifts. An option to filter for assigned shifts would be useful as it removes irrelevant shifts.

Shift Workers check Schedule the day before their shift to see whom they're working with tomorrow.

A single-day schedule view would be helpful for employees since they’re always browsing their colleagues on one specific day.

Based on the hypotheses, I created a prototype with various time range views, options to switch between sorting presets, and a filtering option that shows only the user's assigned shifts.

Example screens from the prototype: Week view in Employee and Position sorting, Filtered for own shifts, and Month, 3-day, and Day view (iOS version).

Besides evaluating the new design concepts, I wanted to find out how Schedule fits into the overall schedule management tasks of Shift Workers, so I wrote the script accordingly.

You can read the usability test script for Shift Workers.

Usability testing

After pilot-testing the prototype with 2 internal colleagues, we recruited 4 Shift Workers from the hospitality sector for the rapid iterative tests. Unfortunately, I could not continue after the 4th iteration due to time pressure.

Research notes for each participant organized by topics we covered during the sessions and color-coded based on the type of user feedback.

Rapid iterations

Prototype iterations included both visual adjustments and larger-scale changes, like adding a cross-department view and replacing the Day view with an Agenda.

Showing all departments when filtering for own shifts

One user made an interesting remark when looking at the filtered view and seeing only their assigned shifts for a specific department:

"I like that I see all my shifts from all different workplaces in one screen."

...even though that was not the case. This gave me the idea that allowing users to see all their shifts across every department can provide a better schedule overview.

Replacing Day view with Agenda view

Participants didn't find the Day view useful, as it made them lose context about other days in their schedule.

"I don't like the 1-day view. I want to know what I'm going to do tomorrow as well. Like, if I'm working this evening, and I'm working tomorrow morning too, then I know that I need to get home and get some good sleep."

This gave me the idea to replace the Day view with an Agenda view. Such a list-like overview would make other parts of the app redundant, which would allow us to simplify the product architecture.

Findings

Based on task times, the new layout performed better: on average, users managed to find a specific shift 2.5 seconds faster in the new layout.

Based on the findings, I could also evaluate the initial hypotheses:

Replacing the date picker with a dedicated monthly schedule view is useful. Participants said having a monthly overview is helpful when planning ahead: "Ah that [month view] is nice. I can plan ahead with my vacation!"

Placing the user's assigned shifts at the top is convenient because they can compare their schedule to the list of open shifts and see which days they can request unassigned shifts.

A Day view is not helpful for Shift Workers, as it makes them lose context about the other days in their schedule: "If I have multiple shifts in a row [on consecutive days], I want to see them on the same screen."

Conclusion
Great start, abrupt ending

We received praising comments in the app store for the updated feature, though users missed some of the functionalities we left out from the MVP. Yet, only 1/4 of users switched back to the old Schedule, which signaled a 75% satisfaction rate.

The new design for Schedule was also one of a kind among schedule management apps — reviewing our direct competitors, none of the apps provided similar calendar layouts for viewing shifts. Therefore, we knew it was an opportunity for us to innovate.

Due to changes in business strategy, the project was, unfortunately, discontinued after releasing the MVP, and our team had to deprioritize the refactoring of scheduling features. Yet, it was evident that we had to pick up the project again later because easy schedule management was the main selling point of our app.