Intuit Expert Portal

The Intuit Expert Scheduling platform onboards and maintains the seasonal and contract workforce of tax experts and accountants that support TurboTax Live and QuickBooks Live. IEP is a dashboard of widgets that includes new hire forms, shift scheduling, notifications, appointment handling for QB clients, and more.

The IEP Scheduling widget is not “just a calendar.” Background rules optimize staffing for the business. Experts support two types of customers.

Initial brainstorms for the scheduler included enabling the user to pick specific shifts by going through the calendar week by week, allowing the system to choose the best schedule based on priorities, or letting the user choose a general schedule and having the system return matches.

Wireframes of the basic shift picker. This design incorporates elements of option A and C, above. Users can set their time zone and choose days and times, or let the system pick for them and make tweaks later.

The picker with days and times selected. Shift blocks can be added and removed by clicking the + and – handles underneath the block (the remove – is missing from this particular design by mistake). Designs are shown in the order they were supposed to built and launched, but in reality we launched the base schedule creator after we launched the existing schedule editor. This change influenced the design of the base schedule creator later in the project.

This version of the schedule picker gave users multiple options. They could choose new hours (as shown in this UI), import schedules from last year for experts who had previously worked for Intuit, or choose their schedule more generally and allow the system to grab those hours for the entire system.

This screen shows the system picker whereby the user could select general shift times, such as mornings, evenings, or prime time (standard workday approximately 9a – 5p).

Once the user clicks Continue, the system tries to grab the shifts the user has requested. This design shows the month view as well as the season view that shows after the schedule is generated. Blue shows the shifts the system was able get, red shows the shifts the user requested and the system was not able to get, and green with an outline shows suggestions the system is making for alternative shifts.

But what exactly is happening behind the scenes and why can’t the user get all the shifts they requested? When it comes time for the experts to pick their shifts, the Scheduler will open in waves. Higher seniority experts, i.e., experts who have worked for Intuit in previous seasons, will be grouped and be able to access the Scheduler before other experts. Within those groups, experts are selecting shifts at the same time, so it’s possible for an expert to not get the shift they requested.

Drilling down into the week view, users can see the exact times of the shifts. At this level, blue represents a confirmed shift, red is a shift requested but not available, green are open shifts that are available, and a blue square around a green shift is an open shift suggestion by the system. The season view on the left shows weeks where there is an issue (such as shifts not available or minimum hours not met), and enables users to quickly move through the calendar to fix problems.

Partway through the project, we received some new requirements that would add features to the design. As it turns out, the engineers would not be able to build the schedule suggestion feature so we removed that option here. The product also needed to support different schedules for peak periods during the season. For example, during tax season there are months where more customer activity demands a greater number of hours from experts. These times are called peaks, and are divided into first, second, and third, which respectively indicate the intensity of the peak.

This is the month view with no rule violations shown. Shifts were editable via a popover menu (shown later). I had originally proposed a model whereby the user could drag the shift to move it or delete it, but at this point in the project cycle the engineers were not yet able to do this so that is not shown here. We also added a countdown timer that gave the user 15 minutes to complete their schedule and commit it. User studies indicated that this would better serve users as a “timeout” counter rather than “countdown.” Therefore, if the user only had one minute left, they could simply take an action and have it reset to 15 minutes. The timer was simply a feature to ensure that experts weren’t sitting on hours that could be released to others during base schedule creation.schedule creation.

In early iterations we decided that once a user has fixed all rule violations (typically not meeting minimums or exceeding maximums for certain days a weeks), we would allow the user to save their base schedule.
Later in the process the ops team became concerned that experts would drop out of the process if they had too many errors and were not allowed to proceed. In a design not shown here, we would allow the users to save their base schedule even if they had some rule violations. They would then receive this popover message.

While experts could make tweaks to their shifts after they’d committed their base schedules, the timing of tweaks was significant. Prior to the user’s start date, they could delete existing shifts at will. After their start date, they would be required to “request time off” if they wanted to remove a shift. Note also that at this time engineering did not think they could support dragging and dropping of the shift blocks in the calendar, so I added a popover to enable users to make those edits.

After the user’s start date, they could no longer delete existing shifts as the schedule was now set and changes could leave gaps in the schedule that would affect customers and ultimately, the business. In this design, post start date for the expert, clicking on a scheduled shift opens the popover that shows that the expert can request to take the time off instead of deleting the shift. Taking time off would require permission as it could leave a non-covered gap in the schedule.

There were also periods where Intuit could become overstaffed, meaning that the call/chat volume was lower than anticipated
In these cases we needed to push “voluntary time off” or VTO to experts’ schedules. In this example, the VTO shift blocks are shown in blue with a purple outline.
VTO hours are full or partial shift blocks that an expert could take off without requiring manager approval.
Intuit wanted to encourage experts to use this option since we were required to pay these experts for their time regardless of whether they were receiving calls, but we could not make it mandatory for them to take this time off.
Eventually the engineering team found a way to make the shift blocks draggable, so I added controls for this. We were still using the popover for other functionality, which is why it remains.

VISUAL DESIGN APPLIED

Final visual design applies some nuances using color and labeling that weren’t available in the wireframes
This is the final result incorporating all the challenges of ops requirements, dynamic staffing, backend limitations, and user needs
This splash screen contained most of the text that was pulled out from the base schedule screen. Although it’s not actually a two-step process, this screen helped introduce users to the process
User testing revealed that experts did read this text, and appreciated the level of detail, especially experts who had used the legacy tool before and found it lacking in information

Initial base schedule state
Error icons because no hours meeting the min/max has been entered yet, also help to identify tabs that are incomplete.

Shows click and drag functionality (I mocked this even though I think the engineers may have had some built-in code they could use to create the interaction; the designs helped to explain to other stakeholders how it worked)
As hours are added or removed, the total daily hours are updated.

Total weekly hours are shown in the right sidebar, along with whether the rules have been met
The explanation about mandatory lunches and breaks is also in the sidebar.

Shows dragging behavior with visual design applied.

Once the user clicks Continue, we try to create the requested schedule. If we cannot grab some requested shifts, we message that. Shifts we cannot get for the user may or may not cause rule violations.
We removed the ability to show shifts that the user did not get, as it later turned out this was not possible due to technical limitations (reliance on a 3rd party app). For the future the team is discussing getting rid of this app to remove these limitations
This 3rd party app also caused a 7 day “purgatory.” This is a period 7 days before the user’s start date when their schedule becomes read only. (Another reason to try to stop reliance on the 3rd party app.)

Messaging exceptions was a huge part of the workflow for this tool, an enormous amount of behind-the-scenes rules drove the overall system to ensure optimal staffing.
At the same time, it was important to not make these exceptions so frustrating to the user or difficult to manage that they could not create or maintain a reasonable schedule.
Past research indicated that a small number of experts would resign if unable to obtain the hours they needed due to restrictions.
The UI always messages exceptions but does allow a degree of flexibility when the user commits their schedule
We allow the user to proceed even if all rule violations are not cleared. It remains to be seen how much manual work in the future this will generate for managers who must fix staffing deficits.
During peak season, min daily and weekly shifts were different than during off peak, usually requiring the expert to work more hours.
Experts had complained that they were unaware of these changes and the shift rules seemed arbitrary, so we looked into ways of making the changes more obvious on a weekly basis (would also probably work during month view but this was not explored here)

Core to this design was the need to balance somewhat inflexible business rules with a user base that would only tolerate so many restrictions and unknowns. User testing indicated that frustrations arose around lack of messaging for why things happened in the UI and what the user could do to solve problems. Encouraging experts to return season after season required a scheduling app that made it easy for them to work what was often a second job for them. At the same time, the business could not afford to have customers left in the lurch if shifts were not staffed. Business rules result in exceptions, which result in messaging for the user. Messaging was key to keeping the experts in the loop.

These screens show schedules after they are set and the user has come back in to view or make edits after their hire date
In month view you can see if a day has available hours, your specific shifts, and whether VTO has been pushed to any of your shifts.
This also shows the At-A-Glance sidebar (formerly called Season View) closed

This is fairly close to what was launched for version 1 (before base schedule was built). This design shows explorations for when we thought experts might “crossover” and support both TT and QB Live. This has not yet materialized but might be a future scenario for this project
QB Live experts would be able to see appointments with clients as shown here (actual appointment editing was done in the appointments widget)
Some things to note about this screen are that the lunch break boxes in gray are required by California law and the system automatically inserts them if the shift goes over five hours. Unfortunately, due to this requirement, the user cannot choose when the lunch break occurs and the system chooses based on staffing needs during that time.

This shows the final visual design applied to the shift editing behavior in the week view. In this example, the expert supports both TurboTax and QuickBooks and can view TurboTax time and QuickBooks appointments on the same schedule.