TouchBistro Scheduled Reports


This scheduled reports feature allows restaurant owners and managers to email groups of reports to their accountant, investors, themselves or other stakeholders in the company. We also found through our research that users predominantly use this feature in order to get a daily or weekly snapshot of how their business is doing, or to download a group of reports at once, which is something we hadn’t intended. I came up with two different concepts to solve the issues with the initial feature and decided to conduct a series of A/B tests to confirm which concept would be best for our users.

Problem
Users need to be able to send recurring reporting information to their boss, accountant, and other stakeholders without taking too much time out of their day. 87% of users felt they needed this feature in order to more easily manage their business.

My product manager and I had assumed that this feature may not be well liked or widely used, since many users we had spoken to didn’t seem to know it existed. We sent out a survey in order to confirm or deny our assumptions. We assumed that 40% or fewer of customers would be upset if we removed the feature, but we found that 64% said they’d be very disappointed and 23% said they’d be somewhat disappointed. So clearly this feature has more value than we expected. We set out to define the pain points customers were experiencing:

  • Managing several aspects of scheduled reports on separate pages was causing unnecessary steps and confusion for first time users.

  • Organization of reports was not easily readable.

  • Emails users received didn’t look professional. They actually looked like they could be spam.

  • Emails don’t have the option to embed the report in the email for a quick snapshot.

  • Users didn’t know some fields were dropdowns because of how they were designed, causing them to be unaware of all the options available to them.


Research
Restaurant owners and managers are very busy people who need a way to clearly see business insights and have a process set up to get other stakeholders the data they need.

Research Methodologies: Survey and A/B Testing.

Our initial course of action was to send out a survey to our entire customer base asking about their usage of scheduled reports. This is where we discovered that the majority of our users found this feature useful. Most users said they were using the feature to do further analysis or get a quick snapshot of how their business is doing.

  • About 60% of customers who answered the survey didn’t leave us any specific feedback, but of those who did, we found that most people cited issues with general performance and bugs.

  • About 5-10% mentioned visual issues such as visuals being too complex or emails being difficult to read.

  • One of the biggest pain points was the feature requiring users to manage multiple related tasks on different pages. For example, managing email recipients on a separate page, which isn’t necessary.

  • Through analyzing user behaviours via Heap, I found that many users were consistently sending the same reports at the same time of the week or month, instead of scheduling them to automatically be resent. I assumed this is because the default field setting in this case is actually a dropdown but there’s no indication that there are other options.



Information Architecture

I made task flows for the current experience in order to identify any major issues and then created flows encompassing the possible improvements. I chose to remove one of the initial flows entirely, which was managing a list of email recipients on a separate page, prior to being able to send them reports. I felt there are other ways to handle email management that puts less strain on the user.


Wireframes

I then created wireframes of a couple of different ideas. The first concept had all the reports listed so that users could see them all at once and select what they wanted to schedule. This is clear but also potentially overwhelming because our product contains fifty reports.


Concept One Wireframes

wireframe sketches


My second concept was trying to make users feel less overwhelmed with their choices. To solve that I made each report section a tab. Once the user selects that tab, the relevant reports appear below. The only issue with this concept is that previously selected reports are hidden until the user reopens the section.


Concept Two Wireframes

wireframe sketches


Issues I found with the forms during the research phase were more clearly defined; users needed to clearly see what their options were, so I kept all options visible as tabs. Since there were only ever two to three options for the user to choose from, I didn’t feel it was helpful to hide this information behind a dropdown. I weighed the pros and cons of each concept but wasn’t feeling secure in any given option without an A/B test.



Mockups

I created mockups for both concepts; this feature mainly utilized existing elements within the design system I had created for this product. In the first concept, I had initially placed the list of reports first on the page and the form was below. I still felt that seeing a list of fifty reports as soon as you load the page was overwhelming to the user, so I switched the two elements so that the form was above the list. I also ensured that as per our users’ feedback, that I was creating less complicated and more cohesive visuals.



Concept One Mockups
scheduled reports for email scheduled reports for email
Concept Two Mockups
scheduled reports for email scheduled reports for email scheduled reports for email

User Testing

Testing the First Concept: 15% increase in task completion accuracy.

For our A/B test we released the first concept to 50% of our customers alongside the original design as a control. I aimed to see a large reduction in task errors and I was successful in this; originally 25% of users repeatedly scheduled reports as one off emails and we reduced this to about 10%. Which means that this 10% are probably using scheduled reports in order to download reports in bulk, which is a feature we now considered adding. The 15% reduction was due to the UX previously being poor.


Testing the Second Concept: 10% more errors than the first concept.

Our team then released the second concept to 50% of our customers alongside the original design as a control. I wanted to know if users understood how to go back to edit their report selections or if them being hidden was an issue for them. By the end of this test there were still about 20% of users that seemed to not fully understand the interface and seemed to be forgetting where their reports were located. Because of this our team ended up selecting the first concept and releasing that to all of our customers due a lower error rate.


Release Metrics

Due to the error rate when testin the second concept, my product manager and I decided to release the first concept. Over the next month, this is what we found:

  • Task success increased by about 70% due to a less confusing interface and presenting clear options to the user.

  • User happiness with the feature also increased, we had about 5% of users who made complaints about the interface in the survey we took, and many users who didn’t realize certain functionality existed now realized it did.

  • The feature is still being adopted at a steady increase, as it has been for the last 3 years.

  • User engagement still happens on a weekly or monthly basis (depending on the type of user), which is expected since this feature is scheduling an automtic task.

  • 80% feature retention is now up from its original 50%

  • 15% of support calls were about this feature, this was now reduced to about 5%.



Reflection
Based on my UX improvements the feature was much easier to use and required less involvement from the users, which made them much happier and reduced support calls. These improvements also increased the number of people using this feature, as well as increased retention.
  • Performing A/B tests was a great learning experience for me and is not something I was well versed in.

  • If I had more time I would have also liked to have done qualitative research in order to further understand their behaviours.