Background

At JRNI, we provide our clients with the ability to easily manage appointments, and tools for their customers to book these appointments. This is all driven by a complex scheduling engine; it calculates compatibility between Staff, Resources, Services and Locations, and their availability at any given time. An important part of this calculation is the Staff Member’s availability on a given day (i.e. what hours they are working, and what other appointments/events they have booked that day).

In 2021, JRNI began evaluating the Schedule Creation & Management toolset. This includes all of the interfaces involved with creating shift patterns for staff members. Through our in-app feedback form, CSAT questionnaires and general feedback from our Support team, the Shift tool was highlighted as a particular problem area. As the Senior UX/UI Designer on this project, I put together a condensed Discovery plan to investigate what the issues were, benchmark the quality of the tool today, and build out a plan for designing and implementing improvements over a short-to-mid period of time (2 to 3 months total).

Here is my four-step, three week Discovery & Research plan:

This plan was signed off by the business, and the next step was to find out the current state of the product. We already had a good idea of some issues with the Schedule tool (from our internal monitoring and feedback forms etc), but needed to validate them with real customer data. As such, I summarised what I considered to be the current issues, which would become our hypotheses to validate with user research.

User research

I wrote up a research plan, and got in touch with our Customer Support team to identify clients who are either heavy-duty users of the Schedule Editor, or had an unusually high number of tickets raised against the feature. I needed users from both of our key verticals (Finance & High-street Retail), as well as a range of floor staff, branch managers and HQ staff, to make sure we were capturing the full gamut of requirements.

Over the next three weeks I interviewed users of 9 clients (including Morgan Stanley, B&Q, HSBC, Nordstrom, US Bank), with the Product Manager taking notes.

Once completed, I summarised the things we learned in three ways: An Affinity Map to group issues together by theme, a Spectrum of Variables to highlight commonality between users, and Proto-personas to start thinking about these issues in human terms. These methods are all very effective tools to help explain research results to stakeholders & the wider business.

I used the affinity mapping & spectrum to create a set of proto-personas. These are not fully fleshed out at this point; they simply highlight the key frustrations and attributes I found were common amongst the interviewees.

Competitor research

One of the biggest takeaways from the user interviews was that JRNI’s clients generally thought of the Schedule tool as either a replacement, or a complementary addition to their existing, third-party Workforce Management tool. As such, I made the decision to focus the competitor research on various market-leading WFM products to investigate how others have handled the issues we were facing. I identified six market-leading WFM tools (RotaCloud, Deputy, Kronos, WorkForce, Shyft & When I Work) and performed a thorough feature analysis. This quickly identified where our own product was falling short, and what the market expectation was in terms of functionality.

Outcomes

I identified 5 key themes that were raised during the research project. 

1. Stability
   Our users do not trust our system, as it is unreliable and buggy. Users need to be able to trust our system, and our schedules must be a source of truth.

2. Usability
   Interviews highlighted many usability issues, both small and large. Common tasks, in particular, were more difficult than they should be.

3. Compatibility
   All of our customers used our tool as part of a wider ecosystem of digital products. We currently don’t do a great job understanding the ecosystem and integrating with it.

4. Forecasting
   Industry is trending heavily to intelligent systems and predictive behaviour. We need to improve our ‘smart scheduling’ toolset to keep up.

5. Scale
   There is no one-size-fits-all solution for our users. The behaviours exhibited by Floor Staff have very little in common with Branch Managers or HQ users.

I summarised these and added supporting quotes/data where necessary - this is an important step when presenting these findings in a clear and concise way to my project stakeholders.

These 5 themes became the core pillars of our design work. I’d like to highlight two high-level design decisions in particular that were informed by my customer research. 

The first decision made as a result of this project was to split the tool in three. We would design functionality for Floor Staff Persona (e.g. shift swapping, holiday requests, sick leave, min/max hours, in-app notifications). We would design functionality for Branch Managers (e.g. updated calendar for creating shifts, better bulk management of many employees, holiday/sick leave approval systems, long-term shift planning, basic capacity forecasting). We would design functionality for Head Office staff (e.g. New analytics & data points, seasonal trends, streamlined integrations with third-party tools, advanced forecasting for long-term strategy). If these happened to overlap, then all the better for it, but I made a conscious decision to tackle these use-cases separately, and not insist on sharing functionality unnecessarily between them.

Another big departure from our old approach was to detach the shifts themselves from a particular staff member. Currently, when creating a shift, it needs to be assigned to a staff member immediately. I found, during our research, that while floor staff are usually only assigned their shifts between two weeks and three months ahead, the Branch/Area Managers want to plan the shifts (without assigning staff to them) much further in advance (often 6 months to a year). As such, we developed a system whereby a Branch Manager could build shift patterns far ahead of time, and apply conditions to them (such as specifying particular Services/Skills, Remote appointments vs Face-to-face, number of staff needed). Specific staff, however, would not be assigned until much closer to the time. This change fulfilled the conflicting requirements of both personas, and also helped streamline issues raised around staff turnover and having to re-assign shifts/bookings all the time (especially in Retail).

Conclusion

What went well

• Interviewed a good range of clients from across our key verticals. This gave me confidence that we are targeting the correct people, and the correct issues.

• Thorough planning meant interviews went smoothly and provided valuable feedback. Often short (30 min) interviews can get easily derailed; having a structured process helped keep us on track.

• Transcripts, recordings and written summaries provided an in-depth record of interviews. This was especially helpful when writing up summaries for stakeholders.

• WFM-focussed feature analysis armed us with knowledge for in-depth, technical client discussions.

Room for improvement

• Organising interviews with clients took a long time and added over a week to the overall duration. Stricter, more formal planning with CSMs may mitigate this in the future.

• A lot of interview time was spent discussing areas not directly relevant to the Shift tool itself. Next time I would probably prepare a background doc that could be sent to interviewees ahead of time; this could help clarify the purpose of the interview.

• Lack of hands-on workshops due to COVID-19 resulted in a lack of user testing (and a lack of benchmarking System Usability, TSR etc). I believe solid benchmarking is key to tracking improvements to a product, and it was a shame it was curtailed in this case.

• Lack of free tiers for WFM tools meant we had to rely on websites that could introduce bias; painting a rosy picture of their feature-sets. Allocating and agreeing a detailed research budget could help account for this.
  

What’s next?
While working on this project, it became apparent that the effects of the COVID-19 pandemic would be with us for a long time. JRNI had to re-prioritise much of its roadmap to proactively work on features and functionality that would be most important during the global crisis. As such, this Schedules work was put on the back-burner in exchange for more immediately valuable projects (such as improving the Virtual Appointment functionality, for example).

As frustrating as this was, the groundwork I put in to summarise and document the process will hopefully mean that when we do return to it, we will not lose any of the clarity regarding the above insights. This is a rarely spoken of benefit to documenting your process; projects sometimes get de-prioritised, or moved to different teams, and ensuring the evidence of your work is detailed and easy-to-understand can be exceptionally helpful in these scenarios.