Context

Service managers at automotive dealerships experience inefficiencies with managing their team’s work schedules in their Dealership Management System (DMS). The process is time-consuming and costly for the dealership:

• Third-party scheduling tools are often expensive and don't integrate with core operational tools like shop capacity and shop loading*, making it challenging to balance workload and maximize potential revenue.
• Service managers must stay focused on efficiently delegating tasks to technicians, and having to also remember rotating schedules adds mental load.
• Since the Dealership Management System (DMS) often lacks automation and mobile accessibility, many service managers resort to pen-and-paper, spreadsheets, or hire extra staff just to manage scheduling.

*Shop capacity is the maximum potential workload the dealership can handle. Shop loading is the actual assigned workload at the dealership in a given timeframe. Revenue is maximized when shop capacity and shop load is balanced because the dealership is managing vehicle work efficiently.

Situation

Task/Problem

How can we create a roster management system that supports 99% of dealership scheduling scenarios while minimizing developer effort?"

I received a Slack message from the Lead Front-End Developer asking if there was a design for a Jira ticket that she received. It contained a screenshot of Outlook’s recurring schedules functionality and the request that it be built into UpdatePromise’s scheduling tool ASAP.

WHEN PROJECTS GO TO DEV WITHOUT DESIGN

A screenshot of the Jira task with a humorous meme that captures what happens when projects skip the design phase! This "straight to dev" moment highlighted the need for some thoughtful content strategy and structured UX thinking.*

UpdatePromise’s scheduling tool was currently limited to creation of single or consecutive day shifts, and the ability to assign Service Advisors to those shifts.

• UpdatePromise's stakeholders requested that all of Microsoft Outlook’s appointment recurrence scheduling features be added to UpdatePromise.
• My colleague expressed uncertainty about where to start, noting that it would take at least one year to develop a full-functioning scheduling tool like Outlook. Unfortunately, we lacked the resources and time for such a project.

FULL SCREEN OF SCHEDULING (BEFORE NEW FEATURES)

This image shows a full screen of what UpdatePromise's interface looked like before introducing recurring schedules. Service managers could only create single or consecutive day shifts and assign advisors to those shifts.

Process

I applied the Triple Diamond Framework, with Object-Oriented UX bridging research and design, to create a solution focused on the problem space.

The Triple Diamond Framework

1. Research the problem—What is the context? What are the issues?
2. Structure the problem space—Where in the system do the issues exist?
3. Design solutions—What content changes do we need to resolve the issue?

The Triple Diamond Framework

The Triple Diamond Framework focuses on structuring a complex problem space before designing a solution.

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Suspendisse varius enim in eros elementum tristique. Duis cursus, mi quis viverra ornare, eros dolor interdum nulla, ut commodo diam libero vitae erat. Aenean faucibus nibh et justo cursus id rutrum lorem imperdiet. Nunc ut sem vitae risus tristique posuere.

Research and structure the problem

During the research and structure process, I uncovered several key insights that shaped my content strategy decisions:

• Dealership interviews revealed most clients needed simple weekly and monthly recurring schedules, not complex recurrence patterns
• Competitive analysis of standard scheduling tools identified industry-consistent terminology that I incorporated into the interface.
• Object mapping showed the relationship between scheduling elements, helping me create clear, consistent labeling across the system.

Design the solution

I created a comprehensive content framework for the recurring schedules feature that would be intuitive for dealership users while meeting technical requirements:

• Developed a terminology guide to standardize language across the system, ensuring consistency and clarity for both users and the development team.
• Created detailed attribute tables for each scheduling event type to specify conditional rules, default values, and required fields that weren't easily conveyed in UI mockups alone.
• Designed content for high-fidelity prototypes addressing six common scheduling scenarios, with intuitive interface text, clear navigation paths, and helpful error messaging.

These deliverables significantly reduced development complexity by focusing only on essential scheduling features while maintaining a consistent user experience throughout the system.

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.

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 crafted content for 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.

Conclusion

By focusing on essential scheduling features informed by dealership workflows and user research, I created a targeted design solution that the development team implemented in just three months instead of the initially estimated year. This strategic approach directly contributed to measurable business outcomes for UpdatePromise.

Result

• Contributed to an increase in potential revenue by ~$2,500 per month from existing clients and ~$10,000 per month from new clients.
• Reduced development time from 12 months to 3 months by focusing only on features required by the dealerships.

Citations