Business challenges

Recurring schedules were a critical need for auto service departments, but UpdatePromise’s scheduling tool lacked this capability. Limited scheduling features created avoidable inefficiencies, added administrative burden, and increased staffing costs.

Lack of recurring scheduling features

UpdatePromise’s scheduling tool integrates with several major Dealer Management Systems (DMS), but doesn’t support recurring shifts, time off, or holidays.

Rotating shifts are common in the industry

Most dealerships use rotating team schedules to extend service hours by 50% without increasing headcount (WardsAuto, 2019). Without recurring scheduling, managing can become tedious and error-prone.

Manual scheduling reduces efficiency

Service managers often spend hours manually adjusting schedules, which pulls them away from higher-value tasks like overseeing technicians or supporting customers.

Staffing costs continue to rise

Some dealerships hire dedicated staff just to manage work schedules. With 50% turnover each year and $15,000 per new hire, these staffing costs add up fast (Hireology, 2023).

My role

I focused on creating a solution that could be implemented quickly and scale with dealership needs. My contributions included:

• Designing a recurring scheduling solution using content-driven strategies and Object-Oriented UX (OOUX).
• Collaborating with UpdatePromise’s Product Manager and Lead Front-End Developer to define requirements and technical constraints.
• Interviewing UpdatePromise’s Onboarding Manager and Sales Director to understand how dealerships currently manage schedules and where the gaps are.

Research the problem

I collaborated with Product Manager to interview internal stakeholders, UpdatePromise’s Onboarding Manager and Sales Director, to uncover how dealerships used recurring schedules in their daily operations. Stakeholders shared that the lack of recurring scheduling caused extra manual work for service managers.

Across the UpdatePromise’s client base, we identified three main scheduling behaviors:

• Didn’t use the scheduling tool even though they had it, missing out on valuable shop loading and shop capacity capabilities.
• Used the tool regularly, but found it time-consuming to manage due to the need to manually update shifts each week.
• Refused to purchase the scheduling tool until recurring scheduling was supported.

At least 15 dealerships requested the ability to create weekly and monthly recurring schedules in UpdatePromise, and each shop had their own unique scheduling patterns.

RECURRING SCHEDULING EXAMPLES

Image comparing the scheduling rotation patterns of three different dealerships.

The stakeholders also shared sample rosters to illustrate how clients currently manage shifts. Shifts were often written on a large whiteboard in the service manager’s office, or managed in an Excel spreadsheet.

SAMPLE TEAM ROSTER

Screenshot of Classic Honda’s team roster in Excel. Service advisors worked in teams and rotated which days they had off on a weekly basis.

Discover and define the problem

Rule out 3rd-party calendar integration

I explored integrating Outlook Calendar but found it lacked in key functionalities that dealerships needed and misaligned with UpdatePromise’s business goal of unifying dealership tools into a single, streamlined system:

• Outlook didn’t have different event types—it didn’t differentiate between work shifts and out-of-office schedules.
• Outlook would be challenging to integrate with the UpdatePromise’s shop capacity features—appointment availability depended on many factors like service advisor and technician schedules, as well as auto parts and transportation availability.
• Not every recurrence functionality may be needed—rather than building every Outlook calendar feature, it’s better to protect our developer’s time and prioritize user needs.
• Would add another platform to manage schedules—it was likely that regular adjustments would be required in Outlook’s settings.

Conduct competitive analysis

I conducted a competitive analysis of four popular online calendars—Outlook (Mac), Outlook (Windows), Google Calendar, and Apple Calendar—to understand the industry standard terminologies and common features. To document findings, I took screenshots of all key functionalities and documented feature comparisons in Google Sheets for easy reference.

The competitive analysis helped streamline content strategy and product decisions, ensuring the final solution was intuitive and efficient for service managers. It helped answer the following about the online calendars:

• What features did they have in common? Identify industry-standard functionality.
• What features could be left out? Avoid unnecessary complexity and focus on dealership-specific needs
• What words were used to describe each feature? Maintain consistency with widely recognized scheduling terminology.
• What words should be used for the best user experience? Ensure clarity and usability for service managers.

COMPETITIVE ANALYSIS: Online calendars

This image shows a spreadsheet comparing scheduling attributes from four popular online calendars..

Due to multiple ongoing projects across both design and development teams, we deferred lower-priority features:

• [Deprioritized] Ordinal occurrences for repeating schedules – We didn’t need to support complex recurrence patterns like "repeat every week for 3 times and then stop" or "repeat every 2 months for 3 times and then stop."
• [Deprioritized] Custom advisor selection for holidays – Holidays apply to all service advisors, so there was no need to assign them individually.

By focusing on dealership-specific scheduling needs, we ensured the solution was both efficient to develop and practical for service managers to use.

Structure the problem

To translate complex scheduling needs into a coherent system, I applied Object-Oriented UX methodology to establish a framework for the recurring scheduling feature:

• Created an object map that defined core scheduling elements (Events, Shifts, Holidays) and their relationships, providing a shared mental model for both design and development teams.
• Developed a comprehensive terminology guide that standardized language across the platform, ensuring consistent naming and reducing confusion during implementation.
• Prioritized essential features by analyzing scheduling patterns across dealerships, allowing us to focus development efforts on high-impact functionality.

This structured approach established a solid foundation that directly reduced complexity and accelerated the design and development process.

Object-oriented UX

I used Object-Oriented UX (OOUX) to structure recurring scheduling around real-world dealership concepts, creating a shared mental model for design and development. My approach included:

• Introducing two new core objects: Time Block and Holidays.
• Expanding the existing “Event” object as a base for Shifts, Time Blocks, and Holidays since they shared multiple common attributes.
• Defining clear relationships and attributes across all recurring schedule objects: Event [Base], Shift, Time Block, Holiday, and Service Advisor.

RECURRING SCHEDULES OBJECT MAP

This object map shows what new objects needed to be added to UpdatePromise’s platform to implement the recurring schedules feature.

Terminology guide

To ensure clarity and consistency across the project, I created a terminology guide that:

• Clarified the definition and purpose of each object and their unique attributes.
• Standardized language across development and design, improving collaboration between teams.
• Helped prevent duplicate or conflicting definitions as the product grows.
• Ensured words used for the UI labels, fields, and repeat configurations matched industry standards for scheduling.

TERMINOLOGY GUIDE

Terminology guide defining key terms for the recurring schedules solution.

Design the solution

With the problem space clearly structured, I designed practical solutions that balanced user needs with technical constraints:

• Built logic-based wireframes in Airtable that simulated real-world scheduling scenarios, validating functionality with stakeholders before committing to detailed UI designs.
• Created detailed attribute tables to specify field requirements, conditional logic, and default values for each scheduling component, eliminating ambiguity for developers.
• Designed targeted high-fidelity prototypes for six common scheduling scenarios, including intuitive UI patterns, simplified recurrence options, and clear error handling.

This structured approach to design transformed a complex scheduling problem into a manageable solution that met both business and user requirements.

Logic-based wireframes in Airtable

Designing a full set of high-fidelity screens would have taken over 100 mockups and several days to complete. To design faster and validate logic early, I used Airtable to prototype the system’s content structure and recurring scheduling functionalities.

My prototyping approach

• I created one Airtable form for each object: Advisor, Shift, Time Block, and Holiday.
• I converted object attributes into field inputs for each object.
• I applied industry-standard labels identified during competitive analysis.

Benefits of this approach

• Created a fully-functional prototype that simulated real-world dealership scenarios.
• Covered nearly all scheduling use cases that would have been impractical to build in Figma.
• Enabled our product team to validate logic with stakeholders before UI development.
• Reduced ambiguity across design, development, and stakeholder teams by aligning content early.

AIRTABLE FORMS INTERFACE

This image shows how the objects and attributes from the object map were applied to the Airtable forms interface to create a logic-based wireframe.

LOGIC-BASED WIREFRAME IN AIRTABLE

This gif shows the logic-based wireframe created in Airtable. Stakeholders tested the form to ensure it met our client’s recurring scheduling needs before I proceeded with high-fidelity designs.

Deprioritization of Time Blocks

Based on stakeholder testing of these logic-based wireframes, I deprioritized Time Blocks and shifted the design focus to Shifts and Holidays. My reasons for this decision included:

• We needed more client feedback before implementing Time Blocks.
• The system already prevented scheduling with an advisor if no shift was available.
• Time slots could be left empty or multiple shifts could be created around a blocked period to achieve the same outcome.

Attribute tables

I created detailed attribute tables for each scheduling event type. These tables served as content specifications that helped define the structure, language, and logic for each recurring scheduling feature.

Benefits of attributes tables

• Clarified conditional rules, default values, and required fields that weren’t easily conveyed in UI alone.
• Reduced development time by eliminating guesswork and aligning backend logic with frontend labels.
• Supported consistent messaging across screens, tooltips, error messages, and validation rules.

ATTRIBUTE TABLE FOR WEEKLY RECURRING SHIFTS

This table outlines the attributes of the weekly recurring shift event type, including descriptions, data types, default values, and whether each field is required or optional.

High-fidelity prototypes

I designed 6 high-fidelity prototypes in Figma that addressed common recurring scheduling scenarios. I based these prototypes on user stories to ensure the features supported real-world dealership workflows.

RECURRING SCHEDULING USER STORIES

This chart shows the 6 different scheduling use cases that the hi-fidelity prototypes in Figma aimed to address.

HIGH-FIDELITY PROTOTYPE IN FIGMA

This gif shows a high-fidelity prototype of the weekly recurring shift flow created in Figma.

Schedules tabs

Rather than mixing shifts and holidays, I designed a separate "Holidays" tab to reduce cognitive load. Holidays were meant to be infrequent, set-and-forget events, unlike shifts, which required regular updates.

Schedules tabs: Shifts and Holidays

This image shows the new "Holidays" tab, which allows service managers to schedule company-wide closures.

New recurring types

I simplified the Shifts UI by prioritizing only the most relevant repeat options—Daily, Weekly, and Monthly—and reserving Yearly repeats for Holidays. I introduced a new “Repeats” checkbox to show and hide the repeat options for a more lightweight experience.

New Recurring types: Weekly and monthly

This image shows the "Repeats" checkbox being selected, revealing options for recurring shifts, including Daily, Weekly, and Monthly, for automated scheduling.

Reccurrence frequency settings

I simplified recurrence setup while still offering flexible configurations by limiting weekly repeats to only 4 weeks, since my research showed that 1–3 week rotations were most common in dealerships.

RECURRENCE FREQUENCY SETTINGS

This image shows service managers configuring shift recurrence by selecting how often the shift repeats (up to 4 weeks) and specifying the days of the week it applies to.

Start and end date settings

I kept the default Start and End Dates (current day and one year out) for Weekly and Monthly shifts. This matched the behavior for Daily shifts, reducing cognitive load and keeping recurrence logic consistent across the system.

START AND END DATE settings

This image shows a service manager setting a Start Date and an End Date for a recurring shift.

No end date setting

I added a "No End Date" checkbox, which allowed shifts to repeat continuously until changed or deleted. This reduced how often service managers needed to manually update shifts.

No END date setting

This image shows the "No End Date" option, allowing shifts to repeat indefinitely until they are manually changed or deleted.

Error handling

As I developed the prototypes, I identified an edge case where service managers might try to schedule a weekly or monthly recurring shift that has no occurrences. I crafted a clear, actionable error message to help service managers quickly understand and resolve this issue.

ERROR HANDLING: invalid shift

This image shows an error message indicating that a shift has no occurrences due to incorrect repeat settings or date configurations.