Street musicians bring value to public space but often struggle in feeling part of a broader community. Street Sounds is an interactive platform that can enhance their sense of community and belonging. We created it by following an iterative design process, from observations to prototyping and user testing.
- Observed and interviewed participants in the field.
- Researched related projects and literature.
- Analyzed data from observations + interviews + literature.
- Brainstormed possible solutions.
- Created sketches, paper prototypes, user scenarios, and personas.
- Designed and implemented the final interactive prototype, using Keynote and InVision.
Team: I worked on the project over 2 months with my colleague Vera Fuest during my Master.
Street musicians face multiple challenges: they need to engage people, they need to know where and how to play, they need to know the legal rules of the city they are playing in. Different motivations push them to play. Some do it for a living; for others, it’s a passion. We wanted to address this diversity and create a product that makes a city feel inclusive.
We followed an iterative and reflexive design process guided by Jonas Löwgren and Erik Stolterman’s book ”Thoughtful Interaction Design.“ I will describe the process linearly, but in reality, we went back and forth between different methods. Sometimes things would not work as expected, forcing us to go back and retry. In other cases, it just made sense to move back and forth to avoid getting stuck.
Observations & interviews
In the first phase, we explored users’ needs and motivations using both first-hand field data and secondary sources. The methods we used were observations and interviews, complemented by a literature review.
We started by going out in the city to conduct ethnographic observations (4) and user interviews (3). When observing, we wanted to understand where and how street musicians play: what location did they choose, how did they interact with people around them, how did they position themselves, for how long did they play. In short, what is the micro-environment a street musician creates with their presence? In the interviews, we asked about their background and experience, their attitudes, daily episodes and experiences of being a street musician.
One of the sessions focused on two twin brothers playing drummers and percussions near T-Centralen, a central commercial district in Stockholm. It was a busy evening at the end of November, with people shopping and walking around. We observed the behavior of the people passing by and stopping around the twin brothers for a long time, interviewing some of the observers to understand why they decided to give money to the duo. Their motivations varied. Often they thought the two musicians were good. Or, they wanted to support them, given the effort of playing out in the cold for so long.
The two musicians were open and friendly when we approached for an interview in-between sets. We would discuss their experience with music and being street musicians. Then they would get back to music, playing another set, with more people gathering.
Personas & scenarios
In the second phase, we focused on making our data actionable. We used affinity diagramming to quickly analyze the multiple data sources and then proceeded to build personas and scenarios.
We decided to analyze the data we collected from interviews, observations and the literature using affinity diagramming. In the analysis, we identified five main behavioral variables to consider in our design:
- Sense of community
- Motivation for playing
- Frequency of playing
Once we identified the five design dimensions, we mapped our subjects (both from first and second-hand sources) on a diagram, using a discrete spectrum. 1Shlomo Goltz describes the approach with lots of details: A Closer Look At Personas: A Guide To Developing The Right Ones (Part 2) We used the diagram to identify patterns of behaviors. Those patterns became the basis to create personas. Our go-to resource throughout the process of creating personas was “About Face 3” by Cooper & Reiman. After finalizing our map, we made a list of goals and characteristics for each persona and then checked them again for redundancy.
Using the personas, we created multiples scenarios and storyboards to show the role our product plays in the life of the users and how it can help them achieve their goals. We also challenged our assumptions by creating a negative scenario where our product doesn’t function as expected. It was unusual to think of our system as a failure but it pushed us to think of additional functions and potential shortcomings.
Prototyping and evaluation
After understanding user needs and modeling personas and scenarios, we moved on to prototyping. Once again, the process was highly iterative. We used sketches, lo-fi paper prototypes, and hi-fi interactive prototypes, all evaluated with users.
At first, we made some early sketches, to explore possible solutions. We played with the idea of matching musicians, focusing on cities and continents, or giving priority to audio as an interactive component. We discussed the sketches with people who play music and had either an interest in playing on the streets or had done so in the past. Some of our initial ideas did not pan out and from talking to people we understood that getting an idea about other musicians is something that our sketches did not provide. With this in mind, we moved on to paper prototypes, converging to two main functions: providing an overview of musicians in a city and showing where they play.
In the first paper prototype, we focused on several key interactions: how to find musicians in a city, filtering them, getting more details on them. We evaluated it with two participants and based on their feedback we built a second prototype. One of the participants, for example, brought up the issue of knowing the rules for playing music in the street in a given city. We hadn’t thought of this and decided to incorporate it in the second iteration of the paper prototype.
After another set of evaluations with the second paper prototype, we moved to the first iteration of an interactive, hi-fi prototype. I was in charge of building the prototype and decided to use Keynote and InVision. 2I know, Keynote is not a common choice for prototyping, but I have always been a fan of how versatile and fast it can be. That being said, it has plenty of limitations and these days I have switched to Sketch for more complex tasks. Similar to what we did with the paper prototype, we conducted two formative evaluations and then made a second iteration of the interactive prototype.
One of the biggest changes was in the profile page for each musician. In the first iteration, the prototype this screen was relatively busy: it showed places and songs that you and a musician have in common, a list of songs played by the musician, a list of places where they recently played, information for multiple social media profiles, videos of performances. Both participants in the evaluation felt it was too much and that a video or an image would be enough to get a sense of someone’s playing style.
In the second iteration, we simplified the screen and focused on videos of performances and a list of favorite album covers as a quick way to communicate their music style and preferences.
Our final interactive prototype showcases three main functions:
- Connecting musicians: users can create a profile and search for other musicians in their city.
- Finding where to play: users can see places where to play on a map. If they have played there, they can add information on acoustics, safety, number of people, etc.
- Getting legal information: users can read and edit a series of rules and tips for playing in the streets, based on municipal regulations.
You can view the interactive prototype on InVision.
Reflections and learnings
Street Sounds was one of the first projects where I completed a full design cycle, from ideation and interviews to a final interactive product. In just a short amount of time, I tried many design methods. I had already some experience with some of them, but integrating them in several close iterations broadened my understanding of each method’s pros and cons.
For example, I realized how useful but tricky personas are. They guided the functions we decided to focus on, but at the same time, I felt it was too easy to distort them, forget them, or treat them as nothing more than static deliverables. I had to remind myself that they were there and that it would be helpful to summon them when something hit a stop.
In retrospect, I would do a few things differently in the project. But overall, I am happy with the result and the lessons learned in using different methods.