Overview

What? Individual Capstone Project for BrainStation UX Diploma Program

Role: UX/UI Design & Research; Graphic Design

Timeline: 10 weeks (with concurrent projects)

Tools: Figma, Sketch, Invision, Photoshop, Pen & Paper

Project Goals: 

• Choose and research a problem space to address with a digital solution

• Create a Hi-Fi mobile prototype of a user flow

• Create a mockup of a marketing website for the product

End products:

• A concept of a show-hosting/event creation app, where local music communities can organize and host their own intimate shows in their own living/work spaces

• Prototyped user flow of creating an event within the proposed app

Background

As a musician, I wanted to address a problem space within music. I chose to explore live performance. Live music is very powerful for me: it’s a celebration of art and community through the creation of an experience that can never be recreated again. However, live music nowadays is turning into something more of a commodity, a product to be experienced through the lens of your phone as opposed to through your own senses.

Luckily, there is awareness of this loss of community. For instance:

• So Far, an initiative focusing on small privately curated and organized music shows, was created in London in 2009. It now exists in over 400 cities worldwide. I myself am an avid attendee and performer at So Far shows in Vancouver.

• Small but culturally influential venues in Canada’s metropolitan areas are steadily closing. This has been attributed by some to the state of the metropolitan real estate markets, as well as social media becoming a competing channel for socio-cultural institutions such as live music venues.

Bear in mind that, at this point, I had yet to start working on a potential solution. In order to guide my R&D further, I devised a design question:

“How might we facilitate more intimate live music experiences for musicians and music lovers alike?”

Knowns

I came into the project knowing that I wanted to make an app for mobile. I knew the MVP would be a prototype of a particular user flow. Looking around on the Android and iOS app stores, I was unable to find an app for So Far or similar initiatives. This discovery, along with my design question, was the first sign of me converging on an idea for a project: privately organized shows, hosted by private persons or smaller companies. 

Unknowns

I also recognized that I only had a few days to conduct user interviews. Moreover, in order to make a MVP, I had to focus on one particular user group. Would I focus on the musician, or would I focus on the music enthusiast? Instead of converging on the show hosting idea at the very start, I decided to conduct as many general, exploratory interviews as possible, with both music lovers and musicians. This was done in order to ensure that I was still receptive to novel ideas generated from interviews.

Exploratory interviews

I conducted 7 user interviews. These were conducted with both professional musicians as well as serious music enthusiasts (which I operationally defined as going to shows more than 4 times per month). The interviews yielded insights like the following:

• Demand for show audiences to share the same intention for going, because shared intentions help set the mood

• Physical proximity to the artist positively mediates the show experience

• While there is demand for intimate shows, a key motivation and behaviour of attendees is to reciprocate the energy of the performer

• The use of mobile phones contributes to a loss of immersion on the part of the attendee, both through the visual disruption it creates, and as an indicator of disrespect to the artist

Critical Insight

During the debriefing, I told the interviewees about the idea to have a show-hosting mobile app. To my surprise, 3 of the interviewees then brought up an application called Side Door -- a show hosting app very similar to my idea. 

This insight indicated a point of no return in my project: where should I go from here? This turned out to be easy to answer: the reason why I hadn’t stumbled across Side Door in my previous research was because they only existed as a web application. Also, knowing that there did in fact already exist a private show hosting concept validated an assumption I had made that there existed music lovers who would be willing to privately host their own shows. So I decided to move forward with the idea, knowing that I had the unique selling point of making a show hosting app for mobile.

Now, I was able to formalize the direction of my project:

Create a mobile prototype of an app allowing users to host shows in their private living- or working spaces. 

Convergence: Personas

I took the data from interviews and generated a primary and a secondary persona -- music enthusiast and musician respectively. I chose the music enthusiast to be my primary persona because I wanted to focus on prototyping a user flow from the perspective of a show host and not necessarily a performer. 

User Stories

From the perspectives of my personas, I started generating user stories in order to get an idea of what type of functionality a show hosting app that would be most desirable.

Shortlist of Features:

• Setting maximum attendance capacity

• Implementing direct messaging for both performers and attendees

• Setting date, time, description of the event

• Using tags to describe the event ambience

• A POS for selling and buying tickets

• A platform for matching up potential performers with events, based on the events' tags 

• Inviting friends and performers

Triage

Now, having generated ideas for the types of desired functionalities in the app, I had to refer back to my constraints. I can only prototype a user flow of around 8-10 screens. The question then became:

What user flow would allow me to showcase the biggest set of functionalities reflective of the my personas’ attributes, and most responsive to my design question?

Deciding on the Task Flow 

I decided to prototype the flow of a user creating an event page. This would entail prototyping a form similar to that of creating a Facebook event, but with features and affordances derived from the design question and user stories. Such features include:

• ability to include tags for the type of ambience of the concert

• setting a maximum capacity of attendance

I decided to keep the inviting friends and performers functionalities in a separate flow. This was because of concerns about the flow being too long, and that a user may just want to set up an events page then browse potential artists to invite at a later time 

Initial Sketches

I started with pen and paper, in order to get a quick overview of possible UI elements and information architecture.

Because I now had a good idea of the concept, and was mindful of time constraints, I wanted to get started on digitizing the flow as quickly as possible so that I could have a testable prototype. 

At this point, I was most familiar with Sketch. However, I decided to start using Figma because it was more optimized to prototype for Android phones. Being an Android user, I wanted to be able to try my prototype on my phone.

User Testing

Structure: 2 rounds of testing, where the second round was a second iteration of the prototype based on feedback. 5 participants per round of testing.

Main task: from a landing page, create an event for a show and set parameters such as date & time, description, maximum capacity and ambience.

Evaluation: the main task was broken down into each testers' performance on several subtasks (e.g. setting date and time). Performance was evaluated by having the tester think aloud, and I also made note of initial non-verbal behavioural interactions.

Experimental Control: the script, main- and subtasks were the same across both rounds of testing, except for an added subtask (resulting from adding a component). 

Prototype V1: Testing Insights

• Back button was confusing

• Helper text for naming the event (“Who’s performing?”) was confusing; as one tester noted, the user may not know who’s performing prior to inviting artists

• The copy for the header (name of city) was too close to the avatar

Round 2

After having addressed some of the feedback from the first round of testing, I iterated on the prototype by modifying whatever feedback I had deemed as most impactful and least time-consuming, and put other points of feedback in a design backlog to be addressed in later iterations. The testing task stayed the same, but I added a functionality to indicate the type of venue in the form. In the first prototype, this had to be done manually by filling out a tag, e.g. #house or #office, and so it would be possible for a user not to indicate the venue type at all. I deemed the venue type feature to be important enough to not take that risk, so I opted to standardize it by adding it as its own element, as a checklist.

Prototype V2: Testing Insights

• Primary buttons were too small

• Back button still created confusion in the new testing sample

• The solid hearts on the event cards made people assume that they had already saved the show, even though this was not my intention

• There was a demand to not have one’s address publicly available on the card

• There was a demand to have the maximum capacity more apparent on the card, and to see how many people were currently registered guests 

Final Prototype 

Challenge:

My biggest challenge here was to stay consistent with my chosen visual identity, which consisted of many bright colours and still conform to the minimal contrast ratios required by the WCAG. 

Solution:

I eventually decided to focus on creating as much contrast as possible wherever typography was inserted, by darkening the colours, while still trying to maintain the visual aesthetic with accents on other places.

Insights:

Accessibility-oriented colour injection requires much time and deliberation -- and should be a consideration at the very outset of establishing a visual identity.

Creating a Wordmark

Why Aleator?

I wanted to build a brand that conveyed the following value proposition:

Beautiful bonds and experiences will emerge from interacting with a local music community

The name Aleator is derived from the art movement and method called 'aleatoricism,' in which art emerges from the use of randomness and the lack of foresight into how random acts will interact with one another.

In order to convey this metaphor visually, I looked at emergent phenomena as defined by the informational sciences. After some sketching, I ended up deciding that a fractal pattern would sufficiently underscore the value proposition. 

Marketing Website

After having created a wordmark, I created mockups of a marketing website for desktop and mobile.

The process here was similar as for building the prototype:

• Generate a list of content that I would like to have on the site, in order to work out information architecture

• Write copy

• Create wireframes

• Start populating the site

• Iterate on copy, information architecture and wireframes 

I ended up being more satisfied with the colour scheme for the website mockup than for the prototype. This may be due to 2 reasons:

1. I had already gone through an iterative design process with the prototype, and so I could work more efficiently;

2. The larger amount of negative space on a websites afforded me with a sense of greater freedom

Key Insights

Having worked on this project for a total of 10 weeks, I learned and experienced a wide range of things - both general things relating to design as a whole and my identity as a designer; but also more project-specific things. Here's list of the most important things I learned and experienced throughout the project:

• Recognizing my competency as a designer: I entered the project with only a year of experience in Photoshop and no formal background in design. In most areas of my creative life I've been extremely critical of my own work and, by extension, my competency. Going through this project, I was amazed by how much I learned each week, especially in relation to learning new tools like Figma and Sketch, and the quality of output of my work. Looking back: I now feel and think that I am a competent designer with a wide range of skills 

• Systematicity is key: You have to establish systems for how you work. Timelines for design work are hard to estimate, and you have to ensure that you leave to chance as little as possible. This may take the form of establishing a design system, naming conventions, intermittent timelines and scheduling -- and many more. Looking back: whatever you can control, control it.

• Design work is necessarily iterative: It is futile to assume that your design-specific intentions and assumptions are going to stay the same throughout a project. Even if you go through a systematized, sequential methodology, you have to expect -- and accommodate -- change. Looking back: I learned that the best way to accommodate change is to view yourself as a node in a general, modular, informational system -- a system of interactions between you as an executive designer, the demands of the user, and the components you create in order to address these demands. Expect change.

• Accessibility in UI design cannot be an afterthought: I decided on a visual identity before even considering the implications a corresponding UI colour scheme might have on people with visual impairment. Looking back: I realized that a mindfulness of potential accessibility issues should be present at the start of ideating on colour injection

NEXT STEPS

Extending to other platforms

A show hosting app like Aleator should be ubiquitous, and not constrained to just Android or, indeed, just mobile devices regardless of OS. Based on my market research, another key platform for this type of application would be for web and tablet. As a proof of concept, I made a mockup of what Aleator might look like on a tablet.

Iteration

There are many more opportunities for refining the Aleator concept, some of which are already in my design backlog from previous iterations of the prototype. Opportunities include:

• Changing the colour scheme in the UI

• A/B test test usability of having a floating action button, as opposed to the current static button, for creating shows 

• Build a direct messaging feature, allowing for event-specific communication channels between performers, attendees and hosts

• Build a user flow of a host browsing/requesting performers for a show

• Focus on the performer side of the user experience, e.g. prototype a user flow of a performer setting up their profile with tags to better help match them with show opportunities