Not all connections should last forever. Buzz is a messaging app focused on risk-free communication. Unlike most messaging apps where phone numbers, emails, static usernames, or profiles are given to another party, Buzz uses a temporary, unique identifier called a Buzz Code.
Conversations will only last for 72 hours, after which, both users must indicate that they want to continue communicating. This makes giving contact information less stressful and allows users to keep their personal contact information private.
Hanna: Co-Founder & Designer
Matthew: Co-founder & CEO
Brian: Co-founder & Backend
In July 2015, I left my job at Tango and helped co-found FortyWings with Matthew Groves and Brian Albright. Before I joined, Matt and Brian were already tossing around the idea for the app and had already begun initial work. I thought the idea was incredibly interesting and wanted to help see it through.
As a key member of the founding team, I was involved in all the major decisions for the creation of Buzz. I worked with the team to help create the branding and product. I helped determine the MVP and designed both the iOS and Android application. When Matt was busy coding the front-end, I took charge of marketing design, development of buzzmessenger.co, as well as reached out to investors, influencers, and writers. We even applied for a provisional patent.
When I joined FortyWings, there was nothing branding wise besides the name (Buzz). Since we wanted the MVP out quickly, I had all the co-founders do a quick branding exercise: we listed what we wanted Buzz to represent as well as what we wanted to avoid. We placed the sticky notes on a wall and discussed our thoughts and opinions with each other. The sticky notes were left up so we can always glance at them for guidance.
This laid the groundwork for designing Buzz.
Based on our discussions, I found images and references that aligned with what we wanted to represent. I printed them to share and talked about what we liked about certain apps (e.g. hexagons profile images!) and what we might want Buzz to eventually look like.
I also created a moodboard then added & removed images while discussing with my co-founders. My goal was to capture the playfulness (a word from our sticky notes) of the bee theme yet still be tasteful (another word).
In the end, I decided to make the application a golden honey yellow with small bee callouts: themed chat background, honeycomb profile pictures, bee stickers etc.
For the Buzz logomark and app icon, I wanted an icon that was shaped like a bee but also subtly resembled a chat bubble.
Similar to MusicPix, we launched both iOS and Android applications at the same time. Due to the nature of messaging applications, we wanted to make sure users could talk to all their friends regardless of platform. Plus, I viewed Buzz as a learning opportunity and wanted to try creating both applications from scratch.
In this case study, you’ll see me jump between Android and iOS because that’s how I was designing and creating the applications in real time. I laid out basic frameworks in Android, basic frameworks in iOS, then worked on more refined UI on Android, then using what I just learned, refine it more on iOS and so forth.
Instead of creating one interface, I made sure both applications felt native to their platforms. For example, navigation on the two platforms were different.
Back when I was designing Buzz, google had no bottom bar navigation (came out 2016-17). I wanted to use a familiar pattern for Android users and opted to keep within Google's design system and used the navigation drawer
iOS had (and still has) tab bars as their primary navigation. Buzz had a bottom tab bar as it's navigation on iOS
Since Buzz was a little different than normal chat applications, I wanted to make sure our first time user experience explained and answered user’s questions.
When I first began working on the project, I sketched a rough user flow with sharpie and paper. After discussing the sketches with the team, I moved onto a more refined flow, information architecture, and wireframe.
During initial testing, most people tapped sign up instead of swiping through the tutorial pages. Since such a small percentage of users would see the pages, I decided to scrap the swiping tutorial for our MVP.
Instead, I moved the tutorial screen to after profile creation. I also removed resizing/editing the profile photo from our MVP. Most center cropped images were fine and we didn’t plan to have a dedicated profile page in our MVP anyway.
When we did further user testing, we noticed that users were incredibly confused about the photo icon. At the time, I had placed an “empty user” in the center of hexagon when there was no photo chosen. When we tested the screen, users didn’t know where they were supposed to tap. To fix this, I tried adding photo and gallery icons. However, this was still confusing... what happens if you tap the middle photo?
In the end, I found that simplifying the screen and adding the text Add a Photo was the most straight forward and least confusing.
Here's the final flow on our smallest iOS device.
We wanted to help users avoid the risks and hassles associated with exchanging contact information with strangers. Connections in Buzz weren’t permanent; users had to decide within 72 hours if they want to connect or let their conversation fizzle out. If both parties indicate they want to continue to chat, the thread “unlocks.”
Design-wise, I needed users to quickly understand how much time was left, what conversations were expired, and who were permanent connections.
The clearest indicators were coloured bands next to each of the chats. The bands transitioned from green to red, expired chats were greyed out, and permanent connections had no indicator.
The coloured bands also sparked an idea: chat bubbles within a conversation could also indicate how long a user had to chat.
We knew users had a lot of choice when choosing a messaging application. Because of this, we wanted to make sure Buzz had all the expected features a chat application would have: text, emojis, pictures, stickers, and GIFs.
When designing the chat well, I kept the options as simplified as possible. I didn't want too many choices to interfere with the chatting experience. The plus button opens the chat drawer, emoji button opens the emoji drawer, and send button sends messages
After a few iterations, I decided to put pictures, GIFs, and stickers within the chat drawer. The drawer slides open from the left. Later on, Facebook Messenger redesigned their chat well to look similar to Buzz. We both came to a similar conclusion: easy access without too many choices
When we created Buzz, the Android default keyboard did not include emojis. Since we thought Emojis were a big part of chatting, we made sure to embed them within Buzz
We also thought stickers were a huge part of the chat experience
Since the default iOS keyboard already had emojis, I replaced the emoji button with stickers. I moved the stickers bar to the bottom to match the iOS tab bar
Since iOS icons were thinner than Android icons, I created different icon sets for the two platforms
I wanted to provide Buzz with something a bit more fun than just emojis. Since I had a focus in illustration back in college, I decided to roll up my sleeves and create some adorable emotive bees.
Back at Tango, I was one of the designers who brought stickers into the application. There, I had already analyzed most frequently sent emotive words and emojis sent between users (love and kisses have always been the most popular!). With that list, we hired illustrators to draw stickers that corresponded with the most frequently sent emotive words. I critiqued and edited the stickers to their final state.
Since this was such a large and involved project of mine at Tango, I remembered most of the frequently sent emotions. This helped me decide which bees to illustrate first as well as placement order (which bees were above the fold).
Before Buzz launched, I created mediakits and a onepager to send to reporters. I was able to get Buzz featured on Techcrunch. I was even the one who was interviewed!
A few days after Buzz launched, Buzz was featured as one of Apple’s Best New Apps. During the feature, Buzz hit Top Free Social Networking App (#12) and Top Free App (#48).
Buzz Bees was featured on the iOS App Store in numerous categories in more than 120 countries including Canada, United States, Japan, United Kingdom and all of the EU. Since launch, Buzz Bees have been downloaded nearly a quarter of a million times.
Screenshot of Buzz Bees featured in Sprinkle on Some Cute (UK)
Screenshot of Buzz Bees in the top free iMessage chart (USA)
When I left my job to help build Buzz, I never imagined how much I would learn creating a startup from scratch. I learned how to incorporate and run a business. I learned the difficulty of getting funding. I learned how to motivate myself working alone. I learned their were mountains of administrative tasks needed (taxes! lawyers! banking needs!) that wasn’t the glamorous startup life I had imagined.
At FortyWings, we were one team. We discussed everything from start to finish and worked closely together throughout the product life cycle. Thoughts, ideas, and critiques were constant. I never had a chance to retreat and lock myself away in a design cave. This made Buzz stronger and my designs better.
I used this knowledge when I led design at Gfycat. Product managers, developers, and other designers were part of constant whiteboard discussions even before the feature was fleshed out. Listening to each other also caused us to trust each other more. While we might have arguments about what was the best, we presented why we wanted to do things a certain way. And when it came down to it, design still had ownership and final power over UI/UX decisions.
Another thing I learned was a well made product can get featured. At Locket and Tango I thought the only way to get an Apple or Android feature was by pitching to App Store Editors. Buzz and Buzz Bees got featured without us doing anything. We just woke up one day, confused why our server spiked so much.
When it came to features, I also learned about the importance of localization. Buzz was english only but was featured in different non english speaking countries. Using this knowledge, when I created Buzz Bees stickers. I made sure to localize the app store screenshots. This caused us to be featured even more frequently in more prominent places than Buzz was.
Finally, I learned that a well-made product does not mean you’ll get users. This was one of the hardest things I learned. As someone creative, I always imagined that if you built something well people would want to use it. This… is far from reality. Users do not care if an app is beautiful, polished, or loads fast if does not solve a need. A mentor once told me “if you release something you're not embarrassed by, you released it too late.” We released ours too late. If we released it sooner we could have gotten real world feedback much quicker.
Buzz got a decent amount of downloads. Users and press seemed interested. When we user tested, users seemed like they were keen to the idea and excited… but all of that was too artificial. We didn’t see users interact with the product alone for a long period of time. When it came to real users, their interest soon fizzled out. While our app was polished, it just didn’t have the secret ingredient that caused people to become daily active users. I mean, when you really think about it, if all your contacts locked after 72 hours… who’s bringing you back into the app?
Looking back now, would I do things differently? Release things sooner? Honestly, probably not. My goal was to release two apps on two different platforms. I did. I learned a lot, had a lot of fun, and I’m proud of seeing it through to completion. At the end of 2015, we decided we had the luxury to close up shop.
If you use iOS, you can still download Buzz Bees stickers.