A tool for managing multiple employee schedules, used by admins for both small business and enterprise level organizations.

Sprout’s Date tagging of Schedule (DTS) feature enables an HR Admin to manage and create the work schedules for their employees--a fundamental part of running a company.

The initial goal was to simply clean and revamp the interactions of the broad DTS features. It was such a legacy product that it was mired in conflicting data loops, inaccurate data visualization and representation; and it even had a severely limiting, and dated, interface.

With fixes to several glaring UI problems and fragile UX flows; partnered with data from numerous client interactions, usability tests, ideations, and design reviews; we were able to push a complete redesign that accommodated the needs of varied industries and user experience levels.

The new design is such a fundamental improvement that it’s the precedence for the the modern aesthetic and usability direction of the entire product line.

Our first step, as with any redesign project, was to understand what we were going to work with. We catalogued the pages, reactions, modals, and flows in the old design. This cursory review gave us a general idea about the effort needed to revamp things. It looked doable, but with some minor adjustments to obviously glaring issues.

Our first step was to focus on easiest issues to solve--the glaring UI problems such as: the toggle design, the visibility of the selected users, the layout of the data, proximity of data, button hierarchy, etc. And to aid in this new information architecture, we also better defined an understanding of the feature’s overarching purpose, as well as those in each page. Which made clear as to what bits of information were of primary, secondary, and tertiary importance.

With all the bits of information vetted, fitted, and aligned, firmly in a new responsive screen template, the second step involved integrating the seamless transitions between each step in our happy path user journey. Our users, admins, want to create a new hour for a hundred employees. Easy.

But what happens when we introduce the uniqueness of each employee? Let’s say some employee only need to clock-in once at the start of the day while the others have to at the start and end of their shift? Still easy.

But what if we start introducing employees who have different lengths of total working hours? Or, more complicated, if some of them only have different required hours of work in each day? Or what if some of those employees have total hours calculated not by day but by week?

And once you get the interaction matrix done for working hours and clocking-in/out, what if your admin is working with a distributed team and some of those employees have a local non-working holiday while others don’t?

There are so many levels of complication present in this system. The usual action for it is to cull some of them down and work only on the primary scenarios, not probably. But what if you’ve already done that, and we’re still left with a huge set of flows? Those that we can’t easily classify as extreme scenarios due to the nature of the (now passé) “new normal”.

Looking back at our process, the most impactful method we applied was asking ourselves “Does this thing align with the primary goal?”

Whenever our Sales Team or Customer Success Department bring to light a curious little related scenario that one client had we ask if it’s applicable to the general user base, and if it’s aligned with the primary goal of the feature. Whenever there’s a new scenario before ask those questions to gauge whether it’s something worth tackling it here, or if we take note of it for another probable different but related feature in the future.

In the end, it was a good, and successful practice of systems thinking design.