Bubble
A unique live streaming service catered to the arts.
About this project
This project was created for my dissertation in MSc software engineering. The project was a group project with a duration of 12 weeks, in which we were supplied with a client and a brief. The goal of this project was to create, design and develop a working application while adhering to an agile development methodology.
My role on the project
As one of four, my role for the project was UX designer and front-end developer. The first 5 weeks of this project were focused on designing, prototyping and testing the applications features and user flows. The latter 7 weeks were focused on developing and deploying the application.
This case study focuses on the first 5 weeks of this project.
Framing the problem
The goal of this project was to create a live-streaming service that is dedicated to streaming arts and culture content. The client requested that the service had two core features. The first is a discoverability feature to allow users to find new or specific types of content. The second feature was that the service had the ability to connect streams of the same content, allowing viewers to switch between the connected streams.
Ethical and legal considerations
Before starting to design the application, I first researched the ethical issues and the legality of streaming the type of content the client wants to build the service around (music concerts, sports events). This allowed me to understand the constraints and limitations this type of application could face and therefore create solutions to how we could negate any of these issues. One issue was the legality of streaming music concerts and sports events, as uploading video to a third party is not deemed fair use and is considered a copyright violation.
Researching competitor products
I examined several of the most popular live streaming services to understand their features and how they differentiate from other live streaming services. I also took note of these services’ overall user experience: how easy it was to navigate, watch streams and start streaming. This helped to create knowledge of current working practices for live streaming services, essential information on what works, what doesn’t and how the product we were developing could offer unique features to the live streaming landscape.
Initial user research
While also researching the competitor products and services, a questionnaire was sent out to gather additional information on the services and features that are most popular and the type of users who interact with live streaming. The questionnaire also allowed us to gather essential data on the types of personalities that frequently view live-streamed content and the types of content users enjoy streaming and watching.
Brainstorming features
To start designing the application, we held a brainstorming session to collect ideas for the product’s features. We gathered all our individual ideas and started organising and discussing each idea. This process allowed every team member to add their input to the product’s feature set and design. Throughout this process we also discussed the technical stack we would use to develop the product and architecture of the database.
Generating user flows
Once the product’s features had been discussed and decided upon, user flows were created to map out the user’s journey and any potential pain points that may occur. This helped to understand how a user could interact with the features and what information would be required. These diagrams also allowed me to visualise the different steps within a given user flow and help to develop ways to negate pain points that may occur throughout the process.
Sketching and wireframing user flow
Quick sketches were created from the user flow diagrams to help visualise how each user flow might function in the final product. These sketches were beneficial when it came to adapting any processes and requirements within the user flows, as each sketch helped to visually communicate ideas and features to my team members, allowing them to provide essential feedback and iterate ideas rapidly.
Each user flow was then wireframed to help map UI placement and develop micro-interactions from the user’s input to communicate the user’s placement and provide essential feedback. Each wireframe was also used to understand and test how much information would be presented to the user on each page and whether or not the user understood the purpose of each UI element.
Building the product’s design system
Before creating any high-fidelity prototypes, I made a design system that would contain all the ingredients and building blocks used to develop the product’s UI elements. This design system aimed to create a visual design for the product that would help communicate the purpose of each UI element, provide essential feedback to the user and give the product a unique identity to help differentiate it from other services.
The design system was valuable for creating rapid iterations of the prototype’s UI design and as documentation for the development team to be used as a guideline for the product’s visual style, user experience and iterations of components. For development, we used React for our front-end framework and the design system was an essential guide on how each component should be created and the different variations of said component.
Site map and MVP
Once all the potential features of the application had been developed and discussed, I created a site map to communicate to the other team members the application's structure. The site map was also used to understand how the user can navigate the site and where each user flow is placed within the application. This was important for development as it allowed us to understand which features were required to be built first. Each feature within the site map was colour coded to communicate what is required from the user, for example, if the feature requires the user to be logged in or not.
The site map also helped us understand the product's scale and therefore allowed us to discuss which features we would have to cut from the initial development stage due to the short time frame of the project. Ultimately we decided on which features were essential to our MVP, and another site map was created to reflect the product with only those features and pages.
Switching between stream
One of the client’s main requests was a feature that would allow viewers to switch between streams of the same event quickly. This would enable the viewer to control which point-of-view they want to watch. We investigated how these streams could be linked together using geo-location and having user-created instances that would allow other streams to join and stream from. I opted for naming these instances as “bubbles” to help communicate that all the streams within one bubble (such as a Glastonbury bubble) are linked together.
Taking inspiration from this idea of streaming bubbles as well as the visual design of Pitchfork’s review explorer and GNOP’s Music-Map, I designed and prototyped a micro-interaction that would allow viewers to quickly view all the connected streams and select which stream they wish to watch. The goal of this interaction was to effectively show all the linked streams while also creating a unique experience for the user that would help communicate how the product differs from other streaming platforms. The size of each circle reflects the number of current viewers watching that particular stream. Other ideas also included using the streamer’s geo-location to map each stream onto a map, allowing the user to select which stream they wish to watch from the streamer’s location.
Verified bubbles / hosted events
Because of the legality of streaming and uploading videos of the type of content the client wants the service to cater to, a solution was required that enabled users to safely stream content without breaking any copyright agreements. My answer to this problem was to allow event organisers to create official bubbles. These event organisers will have the rights to the content, such as a festival organiser having the rights to stream the shows at said festival. Streamers can then safely stream within these verified bubbles when they are at the event. These verified bubbles can represent significant events which would be promoted on the application's main page. Users can add these events to a schedule ahead of time, and other ideas from this solution include a pay-per-view model or links to buy tickets to the physical event.
Account registration and onboarding
One pain point I found when testing the prototypes was that if a user was watching a stream and wished to log in or sign up for the application, their viewing experience was interrupted when they were linked to a new page with the login or sign-up forms. This was a pain point I believed was vital to address, as interrupting the user’s current flow could result in the user not finishing the login or sign-up process. To fix this issue, I designed these registration forms to be placed via modals which would be activated from the navbar and footer, which is always present on any given page. For mobile devices, these forms would be displayed on overlays that slide in from the side of the screen. Now, if a user is watching a stream or searching for a specific event, they can quickly sign into the application and continue with their current flow.
A feature we did not include in our MVP was the ability to recommend content the user has shown interest in by watching and engaging with streams of a similar type. While most recommendations would be governed by analytics from the user’s previously watched content, I also wanted the user to have the option to select some interests when they first sign-up for the application through an onboarding process. Visually, this idea was designed to fit with the bubble motif, and functionally the user would be able to select the type of content they wish to be recommended, such as the genre of music and types of sports.
Explore and search features
I designed two features to allow users to find the content they wish to watch and discover new content. These features were the explore page and a search feature. For the explore page, content is divided into three types: Categories that organise events and streams into specific music genres or individual sports. Bubbles represent an event such as a music concert. And streams which contain each particular stream. I designed the explore page to allow users to navigate through these sections and filter the content displayed by the type of content they wish to watch (music, sport, theatre and art). Users can also sort the content alphabetically or by the number of viewers. The premise for this feature was to improve the discoverability of new content and encourages users to explore different categories and events to find new streams.
Unlike the explore page, the search feature focuses on a user typing in the specific event, stream or category that wished to watch and allows them to find that content quickly. Upon typing in the search field, results are auto-completed. These results show the type of content that the result represents. For example, Jazz is a category that links to a selection of bubbles and streams of events with the Jazz tag. James Blunt Live is a bubble representing a specific concert with multiple streams. Jack Johnson Live is a stream; upon clicking, the user can watch the said stream.
Creating bubbles
Users can create bubbles that represent events. Other users can then stream from these bubbles, linking the streams together. Bubbles are created by users and can be public or private. The former allows other users to join and stream, while the latter requires a link from the bubble’s creator to join. This option enables friends to connect their streams without other users being able to join. Each bubble is given a title and a category representing the type of content being streamed. After, users can add up to three tags, allowing other users to find the stream via the search or explore features. I decided only to allow a maximum of three tags to negate any complexity regarding the information stored on the database for each bubble. When testing, one tag felt too limiting to explain what type of content is being streamed. For example, distilling a music concert into one genre, three tags, on the other hand, was easy to compensate for between the backend and database while also giving the user the ability to categorise the content being streamed accurately.
Design handoff
The development process followed an Agile management methodology. We established user stories and assigned them to different sprints based on a weight system and features required for the MVP. Because I created prototypes for each user flow, these could easily be linked to each user story, allowing me to add the prototypes and correct documentation to each user story’s documentation. This allowed other team members to utilise the prototype and design system while developing the product, providing them with a guide for how features should be visually represented and function.
The final product
The product was developed using a technology stack consisting of Springboot for the backend and Next.js for the frontend framework. Below are two comparisons between the final high-fidelity prototype and the final MVP to help demonstrate how the prototype’s design effected the final product and improved the features needed for the product.
Prototype of the sign-up process
The final product’s sign-up process
Prototype of the explore page
The final product’s explore page
What I learnt from this project
The project allowed me to create a complete product with a brand identity and feature set that aimed to communicate the product’s unique aspects while also delivering on the client’s main requests. This was my first time being able to create a whole design system, which challenged me to develop elements of the product that visually represented the product’s functionality while also obeying core UX laws and principles. I enjoyed the whole design process for this project, as we ran into various problems regarding the ethical and legal issues of the product we were developing as well as the technical aspect of the product. This allowed me to problem solve not only to find ways to create and deliver on the promised features but also to work around the copyright issues attached to this type of product.
If I were to change any of this process, I would have liked to have tested the prototypes against a wide selection of users. Because this project was for a university dissertation, there were numerous ethical considerations regarding testing on members of the general public. This meant that all our testing was on other students, which meant that our data from our user research was ultimately biased.