A passion project application aimed at improving the way users research and plan an evening out with friends.
Application Design, User Research & Testing, Design Iteration
Team of 3 UX Designs
Scrum Master, UX Designer, UX Researcher, UI Designer
Sketch, Invision, Photoshop, Illustrator, Keynote, Trello
Competitive Matrix, Screener Surveys, User Interviews, Affinity Mapping, Persona Creation, Journey Mapping, Feature Prioritization, Moscow Mapping, Design Studio, Sketching, Wireframes, Iterative Testing, Prototyping, Usability Testing
Whether blowing off steam at happy hour with co-workers, getting together with close friends for a bar trivia, or even just sitting at a quiet wine bar with a good book, we all have particular needs at particular times when it comes to going out. But how do people research and choose where they'll go? It's what my team hoped to discover and whether a solution may aid the user in their search for their next time out.
Before we began, our team got together to share our thoughts and concerns regarding our new venture. If we were to find a solution for our users, we want to roll out our service to a confined geographic area while we refine and hone our features. After some initial research, we selected New York City. It had a diverse set of users, as well as boasting over 25,000 nightlife establishments. Generating a total economic output of $35.1 billion a year it could also be quite a lucrative area to launch a product.
Our team would send out a screener survey to find more about users' behaviors: how often people go out, what types of places do they go to, and what factors are most important to them. Our finding would help shape the direction of our research as we learned what influenced users' choices when going out:
Using our screen survey as a guide, we prepared to interview five users of diverse backgrounds to find out more about how location, costs, amenities, and friends influence their nightlife choices. We also hoped to glean additional insights that might provide further avenues of exploration.
Can you tell me about a recent time you went out?
How do you usually find out about the bars/clubs to go to?
Are there any tools that you use to select where you go?
Users generally found out about bars by word of mouth from friends.
Users wanted other activities when they go out besides just drinking.
Users felt stressed to pick “the right bar” for a group when that group consisted of good friends.
Users went to Google Maps, Yelp, & Instagram to find places to go.
To find events, they would call bars directly or use Eventbrite, which was not ideal.
We were starting to get a sense of who our competitors might be in this space. Users had already mentioned Google Maps, Yelp, and Eventbrite. With a bit more of research on our end, we could flesh a full list and plot them on a competitive matrix. Our arrays would range from how explicitly focused competitors were on nightlife, and their level of social media engagement, a factor that was emerging as relevant to our users.
With our research in place, it was time to start synthesizing our data. This process would be a vital step, allowing us to empathize with our users by better understanding their goals, needs, behaviors, and pain-points. These would become the building blocks of our solution.
We had interviewed our users and gleaned crucial insights into the factors they consider when planning a night out. Placing these insights into an affinity map, we could begin to see patterns amongst our users. After arranging the insights into like categories, we could then form statements from the perspective of the user that would help us develop our persona.
Amanda likes to catch up and spend quality time with friends over drinks, but with everyone's busy schedule and different locations, sometimes it can be hard to coordinate.
"I want to plan a night out where my friends and I can all have a good time."
"I need to find places that are centrally located from my friends and me, and have the activities that I am looking for within my price range."
"I spend too much time searching across multiple apps and websites, but end up with places that don't fit all my needs."
"I usually get recommendations from friends via Instagram or text on where to go out, but I also find places on my own through Yelp, Google Maps, and event apps."
In Amanda, our team now had someone we could empathize with as we continued to hone in on the problem our users face. But to fully understand "a-day-in-the-life" of Amanda, we wanted to go a step further and create a journey map. We would walk through a task as Amanda to see our pain-points in action. From there, we would have a fully fleshed out idea of the issues our users face, which would aid us in formalizing our problem statement.
Amanda texts friends to go out.
They all agree Saturday night in Hell's Kitchen. Amanda volunteers to organize, though she doesn't know the area well.
Amanda uses Yelp & Google Maps to search for bars.
One friend texts the group, "Won't trivia be fun?" Amanda's other friends all agree excitedly.
Amanda searches Yelp & Google Maps for Trivia, but can't find relevant results.
She searches Instagram and goes direct to bar websites, but can't find any info.
She resorts to calling bars to find out if any have trivia tomorrow night.
Amanda picks a place on Yelp in between all her friends. It doesn't have trivia, and she's not sure if any of them like the bar.
"I'm psyched to see my friends!"
"I love trying new places with my besties!"
"Hmm...how am I going to find a place that's good for everyone?"
"This is impossible, I've searched and searched and have nothing!"
"This is frustrating! And no one is answering the phone at these places."
"This is impossible, I've searched and search and have nothing!"
When bar-goers choose an establishment for a night out, they must consider their preferences as well as the various preferences of any companions.
Before we started to think through our MVP, we felt the need to first look at the tools Amanda uses to plan and coordinate her evenings out. Looking at the primary function of these apps play in Amanda's planning process, we found three overarching categories. Overlaying these categories on one another, we would start to pinpoint the sweet spot we would want our product to live.
It was time to brainstorm features that would be necessary to Amanda while she coordinates a night out with friends. During our research, we learned there could be a multitude of options that could improve her journey, but to launch a product to incorporate every idea would be laborious and costly.
Instead, we would MoSCoW map the features that our app must, should, could, and won't have at the time of launching our product. Paring down to just the essential functions for Amanda to complete her task, would reveal our MVP.
Our MVP was taking shape, but we would need to think through one final decision. What platform would best suit our solution? We would need to consider not only our business goals but what was also best for Amanda. After careful consideration, we decided that an app developed for the iOS platform would be the best place for our initial product launch based on the following factors:
Users' data stored on their devices and can be accessed quickly and securely.
Settings saved so users will not have to log in every time they want to use the app.
Ability to provide results based on users' real-time location using location services.
More iOS users in the US. iOS users also bring in more revenue on apps than compared to Android users.
It was time to put pen to paper and begin visually piecing together our MVP into an app solution. With each iteration, we strengthened our designs with our collective ideas and input. At each step of the process, we would check back in with our persona, Amanda, to make sure it was helping her in planning her evening out with friends.
In total, we would sketch over 75 different ideas and iterations that focused on key points of user interaction in our design.
6-8 sketches from each person followed by group presentation and critique.
Solo sketching based on critique.
1 refined sketch from each person based on group critique and learning.
1 sketch combining individual ideas and used as the starting point of user prototyping.
A few of the group design studio sketches that would influence our app solution.
With our MVP now decided, and a group consensus reached as to the best possible layout of those features, it was nearing time to test our attempt at a solution. We would first need to create a prototype that users could physically interact with to see if our features and layout were understandable.
We would start with a paper prototype. This prototyping method was both a low-cost effort and time investment. Also, testing in a lower fidelity would ensure that our core functions were as intuitive as possible.
A series of scenarios and tasks would create a standard test to formalize benchmarks for our prototype. We would observe our users as they performed the task to note any areas of delight, confusion, or frustration. In the end, users would also rate our product and give feedback on its usefulness.
Click below to learn more about each scenario and task:
You’re in the Flatiron District right now, but tonight you are meeting with your friends Ben and Amy in Hell's Kitchen. You aren’t sure exactly where to go in the neighborhood, but you know they are big fans of bar trivia.
Using our app, select a bar that meets these needs and send it to Ben & Amy to decide if they like it.
You’re having a great time out with Ben and Amy. That bar turned out to be a great find!
Let your other friends know in the app this is a bar worth checking out.
You are going out with Alex and Tom this week. They weren’t sure what you were in the mood to do, so they sent you a couple of bars to look at and rate.
Using the app, let Alex and Tom know if these bars would work for you.
You just got home from a bar you’ve been to many times before and have previously recommended on the app, but are not happy. This bar recently switched management and has been going downhill ever since.
With the app, let your friends know this is not a bar you endorse anymore.
We had three users attempt to walk through our paper prototype with varying degrees of success. We observed two main issues while users were completing their tasks:
Paper prototypes are terrific for quick experimentation, but their lo-fidelity level can lead to confusion with users in more complex tasks.
What was intuitive to us was not intuitive to our users. Some functions would need a bit more thought in their process.
The beauty of a paper prototype is that it provides the opportunity to fail forward. We were able to find areas of improvement in our design before we committed to building a working digital prototype. Importantly, users expressed excited about our product and loved the proposed features.
It was time to take what we learned from testing with paper and apply it to a functional digital prototype. We would want to improve the fidelity, but not so much that we were distracting the user with colors and graphics. After all, we still needed to iron out our functions and layout, which would be the backbone of our app.
While users were able to find a bar using the filtering features, sending that bar to friends for voting was a bit harder.
Due to placement, users completely overlooked the paper airplane icon. In the mid-fi, we moved it closer to the rest of the functions on the page.
Write & Close
Users had no way to start a new message thread or close out of the send screen in the lo-fi prototype.
Screen Real Estate
The entire send menu moved down to cover the main navigation. By doing this, we eliminated visual confusion and exposed more contacts.
Users had no issue finding the recommend button. But when pressed, users were not sure if anything had happened.
In mid-fidelity, we have the button change states. Both the color of the button and the wording change to indicate the function was successful.
Navigating to the message screen was no issue for users, but there was division over completing the bar voting task.
One user completely overlooked the bar polling tab and instead went straight to typing a message. In mid-fi, we highlighted this section in a different color to give it more prominence on the screen.
We had left no way to indicate successful voting on our original paper prototype. The mid-fi prototype corrects this by changing the color of the selected "hand." Also, to show users that their vote transmitted to the other members of the message thread, a written message indicates that the user has cast their vote.
Users went right to the account section when completing the unrecommend task. Unfortunately, we had not thoroughly thought through the process.
The mid-fidelity prototype completes this function by having users swipe left to reveal a delete button. This two-step process also acts as a fail-safe if users accidentally click the incorrect bar to delete.
We put our mid-fidelity prototype into three new users' hands and had them try to complete our tasks. All users failed to share a bar with friends (Task 1) and unrecommend a bar (Task 4). Also, users expected certain information to be available to them when voting for a bar (Task 3).
No users completed the share bar task. They were unclear as to what the paper airplane icon represented.
When voting for a bar, users wanted to click on the bar to get more details, instead of just relying solely on the bar's name and picture.
After users voted for a bar, they wanted to see how their friends voted.
No users completed the unrecommend task. It was not intuitive for users to swipe left to reveal the delete button.
It was once again time for us to iterate on our design. So far, we had spent a great deal of effort working on the function and flow of our app. With the Hi-fi prototype, though, we would add in fonts, colors, and fully fleshed out visual graphics. These design elements would have to compliment the work done up to this point and not overwhelm or over-complicate our solution.
We would take visual cues from neon bar signs to build out the look of our brand. By keeping the ground color of our app dark, we wouldn't blind users checking their phones while in low-light bars and clubs. Even the name of our app, Social Hour, would get substantial consideration. A play on words of "Happy Hour" and the social aspects of our app.
We once again gathered three new users to test the hi-fidelity prototype. Previous testing on the lo-fi and mid-fi prototypes had allowed us to work through user flow issues, letting us concentrate on visual upgrades in the hi-fi prototype. Users completed 91% of all tasks successfully.
Overall, our users highly rated their experience with our app, as well. They particularly noted our highlighting of special events, bar voting feature, and visual design.
After beginning to develop our app, we noticed the need for a second persona. This would be the bar managers or event coordinators that would be entering the bar event schedules.
We felt this would be a great opportunity for bars to take a certain level of autonomy around their bar listing. We would need to complete user interviews and synthesize that data to make any definite conclusions.
When you have a subject you connect with it can definitely make a project go as smooth as a well-aged bourbon. Social Hour is something that my team and I will keep working on. We started this project thinking that we would find an overly crowded market of apps, but what we found was a complete void in the market. It just goes to show what you can find if you follow what your users need.