Boost is an order-ahead app localized to colleges and universities across North America. It was also one of CDL’s most popular products, so as Boost was undergoing a brand update, the design team was approached to propose north star solutions that the team could design towards.
Three designers in the kitchen
Due to a couple of factors, the product team decided to task three designers with this redesign. However, the team opted for a more - gladiatorial approach. Where each designer would act independently, create their own prototype and measure how each prototype performed.
Each designer would act independently, create their own prototype and measure how each prototype performed.
The intention being that from there we could pick and choose the successful elements from each and Frankenstein them together to create the final redesigned app. Like I said this was an odd approach but one that the team made the best of.
What problem would this north star solve?
Each designer set out on their own to figure out what it was our customers needed with this redesign. I started by looking at what information our Data Analytics and UXR teams had collected over the past few months to develop a mixed-methods understanding of our customers. I also took a peek at our App Store reviews to see what our customers (churned or otherwise) had to say about Boost.
Using quantitative and qualitative research, I created a proto persona, nicknamed “Speedsters” since they cared about one thing. Getting food -fast. At its core, this north star would prioritize reducing the time it took for students to order.
At its core, this north star would prioritize reducing the time it took for students to order.
How deep was the rabbit hole?
We’d always known our menus were messy, but working on this project revealed just how deep the issue was. Boost operated across multiple sites. External and internal partners had their own nuances, menus and challenges when it came to how menus were distributed.
In the past, I had voiced concern and make recommendations to the product team about how a centralized control model wasn’t scalable across our decentralized client base.
But that would be a problem to solve another day.
Unfortunately one of the biggest pain points our users had about our menus was one that had roots far deeper than we could address in our redesign. And I soon realized that operations challenges can’t always be solved with an app update.
Creating north star wireframes
With the understanding that we likely needed to change our operations model, the team pressed on. Working with our UXR team we decided to test three core flows:
Account Creation: With an average time to register of 5 hours, the team was interested in bringing that number down significantly
Ordering an Item: Our existing menu structure was difficult to navigate and made adding sides or customizations difficult
Logging an issue with an order: When customers did have issues with orders their only option was to email a complaint to our support team, which created massive ticket backlogs
With an eye to these core flows, I proposed a north star solution that wouldn’t only aim to perform well with the testing flows. But one that would address user pain points, and that could scale as Boost grew into the future. Within these core flows, I proposed additional improvements grounded in user feedback and known business objectives.
Within these core flows, I proposed additional improvements grounded in user feedback and known business objectives.
Some features such as mapping, surge alerts, and upgrading to a combo might not have been technically feasible at the time. Many competitors in the space offered similar features, our product team was considering adding new features in and our users had been asking for some of these improvements.
Baking them into the north star helped the broader objective of hitting scalability.
Features such as order tracking and estimated time to pick up were also added based on feedback from our users and an understanding of our target audience.
I learned that it might be easy to add features like these in a mockup, but the road to launch is paved with concessions.
Being so close to these products for so long I learned that it might be easy to add features like these in a mockup, but the road to launch is paved with concessions.
What did the users have to say?
We ended up testing the three core flows across the three prototypes with twelve users, 6 current Boost users and 6 non-Boost users. The UXR team conducted remote interviews with users while the design team observed. To reiterate the three tasks were:
Account Creation
Ordering an Item
Logging an issue with an order
The north star I proposed are tagged as Prototype 3 in the results.
When it came to registration, the average time it took users was 42 seconds, well under the industry benchmark of 22 minutes and significantly lower than our previous average of 5 hours. Obviously, one test doesn’t tell the whole story.
When it came to registration, the average time it took users was 42 seconds well under the industry benchmark of 22 minutes
My hypothesis is that forcing registration before users can see the value proposition of the app causes most users to abandon registration or delay it, driving up the average time, but this would need to be tested.
With these designs, we were able to get the time to complete an order to under 2 minutes which was an improvement from our baseline of over a minute to build an order.
Some of the design decisions that potentially led to this outcome might have been due to the removal of the “select a pickup time” flow as well as changes to the overall menu design that made it more similar to our competitors.
But this hypothesis would need to be tested with a larger audience.
Due to the nature of Compass operations reporting issues was something that came up often. Our current process involved emailing support which created massive ticket backlogs and often frustrated customers.
One of the biggest concerns with this design was the introduction of the hamburger menu. But users were quick to locate the issues section, although many felt that issues should be linked to recent orders.
Bringing the North Star life
We opted to test out grayscale versions of our north star so that interface decisions wouldn’t affect how users responded to the designs.
That being said I did get a chance to conceptualize what our north star could look like prior to testing with users.
Where is Boost now?
In my time at CDL I had the chance to work on many modules within the application and across all of our core products, and I’m proud of how far we’ve come since I joined the team.
Some of the features and flows I worked on never made it off the cutting room floor - for any multitude of reasons. But some of the work outside of menus has been in the hands of users. And during my time at Compass I had a chance to contribute to our redesign effort - Novus
.
Novus update
Novus update
Conclusion
Unfortunately, I left the CDL team before I could see the implementation of features that were conceptualized thanks to this north star design challenge.
Although north stars are valuable they need to be grounded in data, lest they just become dribbble shots
When reflecting back on this project I think having three designers working independently instead of together might not have been the best idea. And although north stars are valuable they need to be grounded in data, lest they just become dribble shots instead of real products.