Automating scheduling. Improved experience and stickiness.
Hellohire’s high-volume customers ran the same interview schedule every week. They rebuilt it by hand, or had Hellohire support do it for them. Forget once, and candidates hit an empty interview scheduling page.
Recurring sessions flipped the default: instead of acting to keep using the product, customers would now act to stop, and the work support had been absorbing by hand went away.
- Role
- Daniel – Product, content, and UX design
- Timeline
- 2023
- Platform
- Web app + email
The problem
Hellohire’s strategic customers are BPOs, contact centers, and recruitment agencies that run 5 to 15 interview sessions a week, on the same days, indefinitely. The product treated every one of those sessions as a one-off to schedule by hand.
The failure mode wasn’t inconvenience, it was silence. When someone forgot a week, the candidate scheduling page simply had nothing on it. Our support team had started scheduling on customers’ behalf to stop that happening.
Following patterns and standardizing components
I reviewed familiar systems for recurring scheduling like Google Calendar, Calendly, and HubSpot. Following established patterns, I kept one “Add session” flow and introduced a “Repeat weekly” toggle to reveal a day-of-week picker and an end date, rather than splitting the creation of series into a flow of their own.
Neither the toggle nor the day picker existed in Hellohire’s design system. Toggles were in the product but had never been standardized, so I built both as shared components, not one-offs, allowing us to build this experience and improve platform consistency at the same time.
Repeat weekly, off
Repeat weekly, on
Indicating recurrence
I explored options, such as a recurrence version of the action icons, but landed on adding a new column to make it unambiguous which sessions repeat and on what days. The icon variant was visually messy and still could not say which days a session repeats.
Rejected: icons on every action
Shipped: a dedicated Repeats column
Confirmations that state consequences
Deleting or shortening a series can cancel interviews candidates have already booked. A generic “are you sure?” asks about the click, not about the people whose morning is about to change.
So the confirmation names the consequence: how many candidates are affected, and that they will be asked to rebook. It also splits the action, separating “delete sessions without candidates” from “delete all”, so a safe path is available.
The delete confirmation
Oh no, my inbox!
In-product changes can have out-of-product consequences. Suddenly we were flooding inboxes with emails as sessions were automatically created.
I needed to manage how the email notifications showed up in inboxes and calendars. Sending a series would mean one email and one recurring event for Google Calendar or Outlook to show, but would not allow us to manage when individual sessions were updated or removed within the series. Prioritizing accuracy, I stuck with sending an email and event for each session, but removed the date from the email subject to collapse it all into a single thread.
Before: a thread per session
After: one thread
The outcome
The case for building it was already on the books. Support had been scheduling sessions on customers’ behalf, by hand, every week. Paying people to paper over a product gap is a strong argument for closing it, and shipping recurring sessions took that work back off them.
What changed for customers is the default. Before, staying scheduled meant acting every week, and forgetting meant an empty page for candidates. Now sessions continue until someone stops them. The product holds the schedule instead of asking customers to remember it, which is also what lets it serve more accounts than support could ever cover by hand.