FIZZLE: A collaborative Project

~written by Swarnakshi Kapil~

My Team: ByteU

There are 16,000 Universities in the world, all of which bite students in the a**. However, our “byte” leaves a different mark. From the very first day, we wanted to do something for university students.

We picked “byte” as a part of our logo and team name, keeping in mind its importance in programming. The “U” stands for university. The name ByteU represents our teams light-hearted nature as well as its technical background.

Team members

Logo Design:

While envisioning on how to brand ourselves, we tried to incorporate our personality as well as our vision into our team logo. I sketched out multiple logos on paper out of which, the team chose the one that was in a calculator font. The choice of color for this simple design of a logo was the Tetradic color scheme, that is, blue, yellow, green and red. Google, Ebay, Microsoft, NBC logo’s are some of the most popular logos because these 4 colors show diverse and bold color palette that helps a brand to communicate an open approach to global cultures, race (skin color), preferences, and ideas.

Brainstorming for app idea:

We came up with multiple ideas that demonstrated a potential need in the world. We kept our target market University students and tried to think of an app idea accordingly. That was when we realized that college students everywhere have three common characteristics: lack of time, lack of money and love for alcohol. To be realistic, most college students don’t like the taste of alcohol and usually follow the “drink to get drunk” philosophy. This gave us the idea of improving the drinking experience for our user that is an average college student.

The moment when we got the app idea

Moreover, we needed to create something that was cost affective and not too heavy on the user’s pocket, while still creating a unique drinking experience. So, we decided on the main feature of our app: it would give users the list of all the possible mixed cocktail drinks that can be made from the limited ingredients the user already has.


Our team’s needfinding strategy was to create a set interview script. Applying our past cognitive knowledge, we created an unbiased set of questions so that there are lesser confounds. After I conducted my interviews with 3 interviewees, I compared my answers with everyone and realized that not only had we received a great response to our idea of Fusion, but we had also received tons of suggestions from our interviewees to make the app better.

Competitive Analysis :

There are websites, and others that help us prepare cocktails, but they aren’t the competition we are trying to fight with. The convenience we give the user of having it on his or her smartphone beats all the websites that offer similar features.

The other apps, TopShelf (iOS), Liquor Cabinet (iOS), Mixologist/MIxology (iOS/Android), Cocktail Flow (Android/ Windows), Drinks Master (AndroidopShelf (iOS))which help you prepare cocktails, with some basic features like adding notes to your cocktails, but none of these address the need of the people. What I saw through needfinding was that, people aren’t really interested in making fancy cocktails, but any form of drink mixed with alcohol that actually tastes good. The needfinding process armed us with the knowledge of what people want as well as need. So, we molded our application in a way that would appropriately help our users and well as provide them with a fun experience.

Personas and Storyboarding :

I created one persona, and a few storyboards from this persona. I imagined the possible ways this app could help people have a better experience with alcohol.

For instance, one persona is of a physician named Nick, who works at the UCSD Medical Center. He likes drinks, but does not have a lot of free time. Therefore, his needs include software that allows him to make delicious drinks based on available ingredients.

Now, based on information like this, we come up with different scenarios under which the personas would make use of our app

In the storyboard shown above, we imagined a scenario where a friend doesn’t consume alcohol for various reasons i.e. s/he doesn’t drink or is the designated driver. From this storyboard, we thought to add an additional feature to accommodate this guest — the app’s ability to make delicious but non-alcoholic drinks for non-drinkers. This allowed us a solid grasp of our app’s target demographics.

Parallel Prototyping :

From the class, I learned the importance of separate prototypes to get user feedback rather than collaborating to create a single prototype. This ensured more variety and lesser bias. In addition to working and going through multiple design ideas, we created two different initial low-fidelity prototypes unlike many other groups (one prototype). We were able to obtain two differing opinions and feedback thanks to our hard work.

Our low-fi prototype features a navigation bar on the left side, which closes into an hamburger menu, unlike the permanent buttons on the bottom as in prototype 1. This will result in a cleaner look because there is not much space on a phone screen. In addition, this prototype used popup screens to ease user experience navigating through the application.

User Testing :

Some ways we can solve the confusing navigation issues is to have consistent icon and naming at the top of each page that correlates with that ones on the sidebar. We might not need a sidebar, icons at the bottom or top of the screen may be able to suffice for navigation. Add a dedicated button for shaking instead of making the shake a mandatory thing to use features. Add a feature where users are able to put and see listings of parties. In the drinking buddies page, popup drink recipe on click on their favorite drink. Make the drink of the day sort of article the landing page for returning users. Make the user input ingredients when it is the first time using the app.

User Testing

Final prototype :

Our final prototype includes 5 navigation buttons at the bottom of the screen, each with a distinguishable minimalistic icon to help to user remember where certain features are located. When the user is on one of the screens, that navigation button becomes gray in order to provide a system status update for reassuring feedback.

Final Design Decisions and Obstacles :

One of the main design decisions that we had to take was changing the interface of our Buddies page. This page initially gave a list of users who signed up on Fizzle so that the user can select one of the other Fizzlers to drink with. However, our user feedback suggested that most users would like to see a description of the person they are drinking with, for example, a status in order to get to know them more. Users came up with many suggestions to help us finally come up with an interface that has been motivated by tinder’s concept of swiping. The Buddies page now displays a block with the Fizzler’s picture and description. If the user swipes right, he or she can send a message to the other Fizzler and decide to meet up.

In order for the design above to work, we needed to create an “about me” section in the Profile tab of the app which would give the user the option to have not only information like name, age and picture, but also a personal description. In addition to this, the user can also see the invitations and messages that other users have sent him or her on this page.

The Final Product :

Fizzle, an app designed to make the drinking experience enjoyable from the start. Drinks now come down easy, while making new friends.

My Learning :

Looking back at insights we gained in these past five weeks, we now stand here evaluating ourselves.

The most important lesson we learned is that we, as designers and programmers may find an idea appealing and so may focus on producing a particular product. However, what matters most is this question- “Does the demand we’re trying to address even exist?” In saying this, we mean that we learned to let consumers guide the flow of our research. In a situation where there is no audience for the problem we are trying to solve, we learned to pivot to a problem people actually have. Good design is not about what looks good to the designer, its about what is needed by the user. Therefore, we learned to collect data in various forms and to integrate it to our idea and design.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.