About the project
Kolay is Turkey’s leading HR startup based in Istanbul. It provides a core HR app and a surrounding ecosystem of performance management, payroll, and various apps. Shift is a workforce/shift scheduling application within the Kolay HR SaaS app ecosystem. It was funded by and built for a retail giant's Turkey branch with a headcount of more than 2000.

When I got onboard the project in my second month in Kolay, the Shift app was in development. The design process had been handled by a local UX design agency and handed off to our product team. However, our team was not satisfied with the result, as the designed solution did not seem to be satisfying the customer's needs and was not user-friendly. Therefore, our company owner and product manager asked me to take a closer look to figure out what we can do about it. I started by going through the documentation and designs.

Project Duration: 2 months (May 2018-July 2018) 
Team: Me (UX Designer), Product Manager, Design Director, 2 Developers
Discovery
Inspecting the current design
One major issue with the project was that the design documentation did not specify the use cases and there was no working prototype. Our UI designer had simply translated the wireframes from a Miro board into Sketch design files.
A small modal dialogue to rule them all?
Creating and assigning shifts is the primary task for any workforce scheduling app. In the initial design, the entire process was supposed to be handled on a small modal dialog. When launched, the dialog provided the days of the week, employee selection, shift and break time entry and repeat functionality.
The design did not cover the case of multiple breaks for a single shift, which forced us to consider the sizing limitations as well.
Another major issue with the modal-centric design is that the user is blocked from viewing the schedule. All scheduling takes place on the modal and the user has to save the shifts and return to the schedule view, and reopen the modal.
Another proof to the problematic design was the repeat functionality. When the user selects a shift on let's say Monday and click "Copy", modal switches to a "Copy" mode, but it only allows copying that shift to the other days in the same week. In that case, what happens if the user wants to copy Sunday of this week to the Monday of the next week?
Competitive research and domain knowledge
In parallel to the design inspection, to have a better understanding of what a workforce scheduling app does, I conducted a research about similar tools and the industry expectations. Furthermore, we also did several phone calls with the customer to learn more about their needs to verify the solution at hand. The competitive research also clearly revealed the direction we can take for the scheduling mechanism.
The problem
The existing design solution does not meet the requirements of a workforce scheduling application and is not sustainable.

Reframed as HMW statement
How might we design a scheduling experience that is simple, easy to grasp and is scalable without increasing the development time?
Ideation and Design
Whenever I'm dealing with a problem, I tend to jump into mapping. This time, before exploring design solutions, I started with mapping how the current problematic design would work. Turns out, it was problematic, as the cases we had discussed became more clear on the flowcharts.
This process also revealed the missing information we have that is necessary for the app to work as the customer expects. As I progress through the flowcharts, we did several calls with the customer to define certain functionality and settings.
For the design solution, we did several sessions with the team. While I was scheduling a meeting on Google Calendar, I prototyped a team view and a schedule, and shared with the team. Turns out, it was the thing we needed.
This solution was also in line with the competitive research, as it is a common approach to scheduling workforce on a schedule view. As we were all convinced of the idea, I moved on to Sketch app for the UI design iterations.
A closer look at the shift creation process flow on Whimsical. Many legal restrictions bring many cases where the user might stumble upon error messages.
The design solution was composed of two dialogs; one for adding shift and one for adding break. However, as we talked to the customer, we learned that each shift has to have a break which was also mandated by the law. In the light of this, after discussing with the developers, we bundled them into a single dialog, with an option to add up to three breaks.

The first iteration of the live design.

Outcomes
➕ The design update made shift scheduling easier, as stated by the customer and our internal testers.
➕  The app got more aligned with the future competition in terms of functionality and design.
➕  We saved several months of development time thanks to simplified design and detailed documentation for development. This way, we also opened the app for customer testing earlier than expected.
Shift (Vardiya Yönetimi) is product of Kolay.

Other Works

Back to Top