Mobile iOS design, user experience design, interface design, user research, usability testing
Patron is a seat reservation application designed for students looking for study spaces in cafes. With Patron, one can easily see which cafes have available space. If there are no seats available in desirable cafes, the user avoids wasting time they otherwise would have spent going to cafes in person. The app was designed to decrease the time between planning to work and actually doing work by addressing the lack of cafe capacity information currently available to students, as well as helping them reduce time lost waiting for a spot to open or moving between locations. For cafes, this could help bring in more traffic and fill open seats.
I designed Patron over the course of two weeks.
A quick Marvel prototype showcasing high-level filtering, search, and reservation flows.
Select final screens.
Many students, myself included, enjoy studying in cafes near campus. However they repeatedly encounter problems finding seats, which force them to wait around for an opening or relocate, both of which delay productive work. If they're unlucky, they might encounter the same problem two or three times and waste valuable time in the process.
There's a lack of predictability and information about cafe capacity. Students often set out for cafes hoping that they will find open seats but have no guarantee. Those who can't find a seat feel annoyance and frustration and are hindered from reaching their productivity goals. Quite ironically, valuable time is lost trying to find a place to study.
On a higher level, a lack of certainty gives rise to wasted time and effort.
Though the inspiration for Patron was rooted in my own struggles to find cafes to work in, I began this redesign with a casual survey of 20 Cal students on their cafe-going habits. This was to test my assumptions to make sure that there was an actual need to be designed for, rather than me just designing in a personal vacuum. I also took a step back and interviewed 5 friends about their studying habits to better understand their behavior and motivations. I also went to several cafes around Berkeley and observed customers.
Survey and Interviews
Inability to find seats was something every respondent encountered. For some, this didn't impose too much of an inconvenience, since they would wait around for seats to open. Others replied that it was a problem they frequently encountered that inconvenienced them. Two interviewees shared that they would wait five to ten minutes at a café before leaving for another location, and agreed that it was a hindrance to their productivity.
Lack of ideal seats was mentioned repeatedly (for instance, if seats were available but they were far from outlets or tables). One interviewee responded that while he rarely had trouble finding a seat, he would actively monitor for better seats to open up, which prevented him from doing “real work” until he got an “official seat”.
Outlets, lighting, and Wi-Fi quality were important factors in deciding where to go. Current location, amount of work, drink quality, and café interior also factored into the decision making process.
Around three quarters of respondents stuck to the same cafes, and had a list of 3-5 "go-to" spots. Interviewees said they enjoyed light buzzing and company in cafes, but that the noise level could be distracting if they were left without ear buds or headphones.
All interviewees expressed that they went to cafes with some study goal and having to move around was as a waste of time. They usually made the decision to study at a cafe the day of or the night before, not making plans further in advance unless it was with someone else.
My respondents also agreed that they did not have any way to obtain information on cafe fullness. One respondent referenced the Popular Times feature on Google, but it didn't affect their behavior. No respondents ever called a café about space.
I also went to several cafes around Berkeley and observed customers. Across the cafes I observed, I saw some customers entering and glancing around before leaving. For those with seats but not tables, some glanced around periodically for seats open at tables. At one cafe, a casual queue formed for table seats. I personally had a seat I had been eyeing taken by another customer while I was ordering my drink.
- Students study in cafes since they feel more productive there.
- Students regularly encounter difficulty finding seats in cafes.
- Not finding seats or not finding ideal seats distracts from work and wastes time.
- Students lack an effective means of knowing café fullness without going in person.
- Students don't normally plan far ahead to study in cafes. They usually decide the day of or the day before.
- Other common problems with studying in cafes are with Wi-fi connection and outlet availability.
- Outlets, Wi-Fi, lighting, noise, drinks, familiarity, and distance are external factors that impact café choice.
Armed with research insights, I started brainstorming potential solutions. I wanted to optimize the existing experience rather than create new behaviors. While a more ambitious solution could be to somehow help students be productive and motivated to study wherever they are, I constrained my design goal to getting students into their ideal study spots – in this case cafes – as quickly and easily as possible. I wanted to design a solution that was as effective as possible for students and easy for cafes to implement.
Crowd-sourcing reports of fullness was an idea that popped up, but it didn’t seem significantly different from Google’s “Popular Times” feature. While the information was valuable, it was still an intermediate step in the process of getting a student into a seat at a cafe. I recalled LED signs above roads near shopping districts in my home city of Guangzhou, China that reported the number of openings in mall parking lots. Presenting a specific number for a given café was certainly helpful, but wouldn’t show which seats were available and wouldn’t guarantee the student a seat. I also drew from flight bookings, which allowed travelers to select a specific seat.
I converged on an idea for a reservation-based solution that could guarantee a student a seat they were happy with. For cafes, this could help redirect foot traffic from overcrowded locations to those with vacancies. Users could see the number of open seats in nearby cafes, make an instant reservation, and check in via scanning a QR code fixed to the desk. Through this process I referenced Airbnb, OpenTable, Yelp and Instagram to see how different applications handled reservations and search. I also drew from my visits to Workshop Cafe in San Francisco.
Based on research, there were three possible use cases for Patron, in order of importance.
- Reserve Now: The user wants to reserve a seat instantly or for the same day.
- Reserve For Later: The user wants to reserve a seat some time in the coming week.
- Information Search: The user is curious about cafe capacity and comparing capacity across cafes, but doesn't necessarily want to reserve a seat.
With a direction in mind, I started putting ideas to paper in my notebook, with a focus on the first use case, Reserve Now. I laid out the main user flows of searching for open seats, making reservations, and checking in. I also sketched out major screens and laid out key elements.
Early sketches--user flows and low fidelity wireframes.
Based on research insights, I drafted a search view, for users to find any open seats, and a favorites view, for users to see if their go-to spots had open seats. This eventually evolved into Search, Upcoming and Past Reservations, and Favorites.
I elected to use cards over lists as they were more effective and clear in displaying all the information a user would need to make a decision where to go. Since the campus has a reasonably limited number of cafes nearby, cards created clearer separation of cafe information without dramatically increasing mobile scroll distance. I designed using a filter dialog due to the limited content in the app. I used a tab bar as the primary form of navigation to make the major app views immediately apparent, to clearly signal where the user is, and make it easier to shift between views.
My original idea included a seat selection feature designed to address the issue of students arriving at cafes only to find the only open seats are far from tables or outlets. Users could view a seat map of open seats and reserve a specific seat. After confirming their seat, they could check in, ask for more time, or cancel their reservation. Upon arriving at the cafe, they could check-in by scanning a QR code affixed to the seat they selected, after which their session would end. However, seat selection would require significant input from cafe owners, and was less feasible in implementation. The seat selection interface also created tappability issues due to limited screen space. Though the problem could have been mitigated with a pinch-and-zoom interaction, some individuals I interviewed expressed that they cared more about getting a seat than getting specific seat. Furthermore, allowing users to reserve specific seats could create reservation cherry picking that could create frustration if the most coveted seats were constantly booked. There were also challenges with designing a streamlined check-in flow that was non-disruptive for users and low-effort for cafes to implement. I questioned the need of the feature itself and ultimately removed it in favor of generic seating reservations that .
Though Patron has defined benefits for users, I questioned the Patron's feasibility and viability for cafes. Though Patron could help redirect traffic to emptier cafes, cafes may be unwilling to implement a reservation system designed for students because it might promote "seat-squatting" for a long period of time without purchasing food or drinks, decreasing revenue. A full cafe could also cause walk-in customers to go to another business. The business's interests could be potentially addressed through some form of credit system, though it would be more financially costly for users.
Due to the time constraint of two weeks, it was important for me to prioritize the most important aspects of the app--finding and reserving open seats. Over the course of the design, I tried to assess various UI elements and components.
Potential confusion arose regarding chain cafes like Philz Coffee, Peet's and Starbucks. Additionally, lighting and noise level filtering options were difficult to qualify, but could utilize crowd-generated contributions. I wasn't able to fully explore how to display cafe capacity in the most optimal manner, and would also reassess the need for "Available Seats" on the cafe page given how users no longer have the option to select a specific seat.
Early low-fi wireframes for the search and reservation flows.
Earlier search and filtering screens.
Icon set based off of iOS 10 icon styles, as well a a quick illustration for the confirmation page.
Color palette iterations based on mock-up feedback.
Different versions of the home view with the expanded search bar.
Feedback and Testing
Though I was limited by time, I conducted quick usability sessions with three college students. I showed them static screens on my phone and asked them to talk through how they would go about completing tasks like searching for available seats or searching for a cafe they had in mind. All three were able to navigate through the search and reserve flows as I had intended, but one of my testers was confused as to whether he could edit his reservation details on the cafe page. To make this more clear, I revised the text color to be more in line with the existing text hierarchy.
After finishing high fidelity screens, I reached out to a designer at Square who very kindly critiqued my work. His key points touched on color accessibility and text legibility. In response, I tweaked the color palette and ran the hex codes through a web accessibility color checker. I also increased my type size for greater legibility. I viewed my screens on my phone for good measure.
His other comments for me were:
"Is this a good business model? Studying sessions usually take hours, do cafe owners want that? "
"There are missing puzzles, does the flow make sense if you put the screens together?"
The first point of critique hit on the product level challenges I had encountered earlier--Patron could provide great added value for cafe-goers, but what incentives do businesses have to join? While my initial assumptions gave me the liberty of not having to extensively think about a concrete business model, as an app that is connecting two parties, both necessarily need to benefit for the concept to be realistic. At this point, I thought more about ways to sweeten the benefits to cafes, such as a small booking fee and opt-in reservation availability. I went around to some cafes around campus and asked managers what they thought about reservations. Independent small businesses that didn't get too much traffic were much more interested in Patron as a concept than businesses that had a constant stream of customers. However, the overall sentiment of cafe workers and managers towards students studying there was positive and welcoming.
Due to time limitations, I focused on designing the ideal case, and wasn't able to deep dive and explore the design for unavailabilities, disincentivizing no-shows, and specific interactions, but it is something that I would love to revisit in the future.
Patron was born out of my personal frustration at wasting time to get started with studying. I based my design decisions around the goal of helping students find a cafe workspace as quickly and easily as possible. The app seeks to inform decision-making with real-time capacity information, provide a guaranteed space through reservations, and minimize time between setting out to work and actually doing work.
As with any design, there is infinite room for usability testing and revision towards a more thorough, helpful, and pleasant product. There are always improvements to be made and iteration to be done, such as refining filter options and designing a way to effectively present predicted capacity data for the Information Search use case. Nevertheless, I believe that Patron directly solves a problem that no existing offering adequately addresses.
I end my design with further questions for exploration. Though the current design audience is college students, should working professionals and other individuals be able to use the app? Though the current design is limited to cafes within a three-mile college campus, should the coverage be broader? What might be the prevalence of cancelations or no-shows? How could I design to mitigate such behavior? How can the product better benefit cafes as well? Is there a way to help students be more productive regardless of where they study?