In an effort to increase customer supply, Sawyer initiated a transition of their sales model from a high-touch to a low-touch SaaS model.

With higher expected sales volumes, the onboarding team would not be able to keep up, therefore, our goal was to make the product intuitive enough for new users to onboard themselves.
‍
In addition, churn due to usability issues accounted for 10% of total churns. We had a leaky bucket and when accounting for CAC and LTV, poor usability was costing the company over $100K/year.

During the initial discovery phase, we used several frameworks to help us understand the problem from different perspectives, ex. journeys, product pillars, and task flows.

Our final model helped us separate new opportunities (expansion) from existing functionality (simplification), which narrowed our scope. The task framework also helped us separate categories of existing usability issues and how we would approach each of them:

UX low hanging fruit, for the most part, could be done in isolation. We would therefore approach issues as one-off tickets, using an impact over effort matrix to prioritize.

Standard Tasks are really a series of interconnected steps. Solving one step at a time would fail to solve the problem as a whole, therefore each task had to be approached as an epic.

From an execution perspective, some of the “UX low hanging fruit” had dependencies and overlapped with the standard task redesign. To avoid redundancy, we needed to prioritize our tasks and understand more of the project scope before we began ticketing global problems.

I put together a research plan to identify the top priority tasks and came up with a formula that would help us quantify our insights for stakeholders.

Task Urgency = Task Length x Task Ease

Using a survey, we listed a set of abstracted business tasks and asked our customers how much time per week they spent on them. We then asked, on a scale of 1–5, how easy the task was to perform. After receiving 121 survey responses, we analyzed the results and identified the highest multiples.

The 2 most urgent tasks were scheduling new activities and editing existing schedules, which conveniently had a lot of technical overlap.

Now that we had a focus area, it was time to delve further into the problem space. We conducted a round of interviews focused on schedule creation and management. Our research goal was to understand the existing usability issues associated with creating and editing schedules.

To make sense of our observations, we bucketed pain points into 3 distinct user contexts and created user stories to standardize the user problems up for consideration.

In order to start taking registrations and making money with Sawyer, a business owner needs to schedule activities for purchase. This task is among the first set of actions a new user must perform and often represents the first impression with the software.

This task should therefore be intuitive enough so that a new user can complete it on their own with limited mistakes or reliance on the service team. New users should know what they can do, where to start, and if the tool will be a good fit for their business.

Below is the core problem we identified with schedule onboarding along with the solutions we came up with to solve it.

Once a new user has committed to Sawyer, they'll start scheduling the rest of their activities. This task can be a very time consuming and may take days to complete.

Ideally, we want the schedule creation process to be a fast, seamless, and non-repetitive so our customers can focus on content instead of the configuration.

Below is the core problem we identified with schedule creation along with the solutions we came up with to solve it.

Activity edits are even more common that activity creation. Some of the most common scenarios include editing price based on the attendance, or overriding capacity to accommodate more students. Either way, the desired behaviour for this task is to be quick, easy, and flexible—especially while editing multiple activities at once.

Below are two of the problems we identified with schedule management along with the various solutions we came up with to solve them.

In our research, we learned that users find what they're looking for in one of two ways: 
1) by scrolling, sometimes through hundred of scheduled activities
2) by searching, usually with the browser search (⌘+F)

To make "scroll finding" easier, we needed to update the UI. To start, we made schedule containers collapsible, which gave a higher level perspective and reduced both scrolling and page load time. At this level, we also added activity dots to give "shape" to the schedule and provide information scent to what's inside. We also updated the information design within the container, making use of hierarchy, contrast, visual cues, alignment, and grouping, all while keeping the same sequence in which the activities were created. Finally, a smaller nav bar opened up the page real estate to hold all the necessary activity information. The information design alone reduce "find time" drastically and even made comparison across activities easier.

To make "search finding" easier, we added a search bar at the top of the page that could query the most common data: activity name, location, instructors, and day of the week. The search results page showed matches that were editable.