Slowing Down the Lunchtime Rush
Hearing from stakeholders of the online meal ordering platform Foodsby that their novel business model—saving customers money by organizing and consolidating restaurant delivery times and locations—was struggling to connect with and hook new customers, I strived to understand exactly where the user experience was breaking down and conceptualized new features to bridge the critical gap between user expectation and reality.
Role: Research, Design
Tools: Pen and Paper, Sketch, Google Forms, Google Sheets, Miro, Keynote
Methods: Competitive Analysis, Rapid Prototyping, Kano Analysis, User Journey Mapping, User Flow Diagramming, High-Fidelity Wireframing, Annotation
The Big Picture
Client
Foodsby:
Online platform specializing in low-cost lunchtime food ordering and delivery coordination
Project
Conceptualize and propose new platform features to improve customer onboarding experience within a defined development budget range
Recommendation
Improve first-time user workflow by increasing user feedback, education opportunities, and incentives to order
When Business and User Models Clash
Competitive Analysis showed that the challenges of the ordering model were similar across the board. Did they have to be?
Upon first digging into Foodsby’s platform, I found myself in a rare position. As a busy professional in a densely-populated area—who was getting hungry—I was able to truly embody the experience of the target user: a worker looking for an easy, inexpensive lunch.
Even having received a high-level overview of the problem space from stakeholders, I found myself a bit disoriented upon entering the Foodsby environment. As a new user, I had to sign up before seeing my ordering choices. Then, after logging in, I was met with an apology telling me that I had missed that day’s order window.
In short, I wasn’t going to be able to get my lunch from Foodsby that day.
Conducting a competitive analysis of similar platforms led me to suspect, however, that the challenge wasn’t unique to Foodsby; it seemed to be endemic to the model. Consolidating delivery times and locations, despite its attractions as an environmentally-friendly and cost-effective option, appeared to force the user to think differently about their priorities. Affordable or accommodating? Sustainable or predictable?
Working to reimagine the new user flow from the Foodsby marketing main page.
“It’s a little bit of a commitment. . . That commitment to [ordering early] is what helps us keep costs down, but it limits flexibility a bit.”
— Stakeholder describing challenges for the user in ordering from Foodsby versus more typical food delivery options
Hand-drawn wireframes of feature suggestions and accompanying descriptions presented for consideration by the design team and Foodsby developers.
Quick Ideas for Playing the Lunch Long Game
Rapid prototyping helped to brainstorm features that could bridge the gap between the user’s expected ordering flow and the Foodsby model.
Foodsby stakeholders themselves noted the challenge in convincing new users of the value their service when it was so easy, perhaps even common, for users to miss the early order cut-off times. After all, most people are used to ordering lunch at lunchtime, not before. What would help to mend that initial disappointment for a new user enough for them to try again the next day?
Reviewing prior user test findings from Foodsby, my competitive analysis notes, and Foodsby’s own website, I began to think about changes or new features that could help to alleviate some of the burden of a more strictly-regimented food ordering procedure than users would likely expect.
Through rapid prototyping, I ideated features that were primarily intended to:
Create opportunities for flexibility into the user’s flow to more closely mirror the feeling of a standard online food ordering experience.
Play up the unique opportunities that the Foodsby model provided to users with new tools that highlighted them.
The design team consulted with Foodsby developers to get an estimate of the feasibility and time investment required for our feature ideas. It proved to be an excellent opportunity to hear more about what features Foodsby had already been considering or had heard requested from existing customers and partners.
As the people who quite literally knew Foodsby from the inside out, the developer’s thoughts ended up being highly influential as the team reviewed and voted on the dozens of feature concepts to selected a curated slate for additional evaluation. Users, though, would have the final say.
Doing the Math on User Needs
Kano Analysis highlighted directions that would most impact the user experience, but was there something still missing?
To get a sense of how users would respond to each selected feature concept, my team conducted a Kano analysis of current Foodsby users who were new to the platform. The results suggested that most features would, at best, be pleasant but unnecessary additions to their experience, but one concept put forth by another team member—prompting users to order ahead for the next day when the current day’s orders were no longer available— showed improved performance potential.
I was encouraged enough by the data to apply 2 of the 4-5 development weeks budgeted for the project to this feature, and proceeded to develop high-fidelity wireframes. But I soon found that there was something missing from our previously scoped features that needed exploring.
Kano results for each feature surveyed, highlighting the two features that appeared to be the most likely to excite users.
“I did not think you could order ahead but that is good!”
— User comment on Kano survey showing the opportunity to better communicate to Foodsby users that they can order well in advance to avoid disappointment.
User Journey Map showing the workflow from awareness through first order completion for a new Foodsby user both within the current and proposed environment.
Changing the Trajectory of the User Journey
Realizing that users were potentially falling off the Foodsby train prior to reaching the order page, I worked to resolve the issue by advocating for a feature that hadn’t been scoped.
Reviewing my user journey map, I noticed that the next-day order prompt would intervene in one of he user’s lower moments: realizing that they couldn’t order that day. But the feelings of frustration preceded that moment. . . and, I discovered as I again perused the prototype ideas the team had produced and scoped with the developers, no one had yet come up with a good solution for it.
During my competitive analysis, I had found that users who were outside of the service area would receive immediate feedback about their status. Users who were within the service area, however, were asked to commit to creating an account before receiving the same level of feedback. It was a bit like the online equivalent of going into a restaurant and not knowing if it served a MacDonald’s or Michelin star-rated menu until the diner had already been seated and started nibbling at the bread basket.
To address this issue, I ideated a feature that would give the user positive reinforcement by teasing the restaurants that served their area prior to signing up. Not knowing how the features would impact the development budget, though, I knew I had to connect with my team to discuss.
In the end, I had to concede to compromising a bit of what I was envisioning for the sake of keeping the development budget intact. I wireframed a pared-down version of the feature that was similar enough to other proposed UI updates that I could reasonably estimate its development time. I didn’t give up on the personalized, location-based experience I had been imagining, though, and tacked it on as an extended recommendation to be explored should the spirit—and the time—arise in the future.
Outlining the Potential
In wireframing high-fidelity versions of each feature proposed, I relied heavily on existing design systems and content strategy to make an experience that would integrate seamlessly into the current Foodsby environment.
Having settled on my feature set, which I rounded out with some voluntary user education content peppered throughout the ordering flow, I spent time gaining comfort with Foodsby’s design systems and voice. It was important, I reasoned, for the stakeholder to be able to see themselves in the new features.
To that end, I made as much use of the current platform’s layout and aesthetic—both for web and mobile—as possible to show how new features could be integrated while maintaining the Foodsby identity.
Finally, in packaging and annotating the wireframes for the stakeholder, I made sure to highlight the areas where the flow would stay the same, just as well as the proposed differences. Why change what isn’t broken?
Excerpts of the annotated prototypes packet presented to Foodsby featuring both web and mobile views of the proposed features.
The Takeaway
There are a lot of ways for products and services to meet user needs. Sometimes, though, serving one need sacrifices another.
Finding ways in those moments of sacrifice to empower the user—with knowledge, choice, and clear direction—can go a long way toward highlighting the values of a service and dimming the trade-offs. And the best strategies for building that empowerment may not arise until we’ve spent enough time in the user’s shoes to see exactly where the moments of greatest need appear. When we find them, though, we have to be ready to make sacrifices of our own for the same of creating an experience that works for everyone. . . including the client.