Summary: 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 with a variety of research and design methods. It was a deep, hands-on dive into interaction design methodology, from which I learned a lot.

Methods: Observations, interviews, affinity diagramming, paper prototyping, formative evaluations.

My role: I observed and interviewed participants in the field; researched related projects and literature; analyzed data from observations + interviews + literature using affinity diagramming, brainstorming possible solutions. Created sketches, paper prototypes, user scenarios, personas. Designed and implemented the final interactive prototype, using Keynote and InVision.

When and where: I worked on the project with Vera Fuest at KTH, in 2014, over 2 months.

 · · ·

The challenge

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.

How can we help street musicians to appropriate public space and find other people to play with, in order to create a community?

Methodology

“Thoughtful Interaction Design” by Jonas Löwgren and Erik Stolterman guided our design process.

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 breaking it down into different sections: exploration where we define the domain and identify user needs; ideation where turn insights from data into design ideas;  prototyping and evaluation where we build our design and evaluate with people. This might give the impression that it was a linear process, 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.

Exploration

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.

Observations & interviews

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.

Ideation

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.

Affinity diagramming

We decided to analyze the data we collected from interviews, observations and the literature using affinity diagramming. Affinity diagramming is not as complex or systematic as other data analysis methods (for example, thematic analysis.) But it is quick and practical. We chose it because we wanted to move quickly from collecting data to building the first deliverables. In the affinity diagram, we identified five main behavioral variables to consider in our design:

Personas and scenarios

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 in “A Closer Look At Personas: A Guide To Developing The Right Ones (Part 2)” for Smashing Magazine. 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.  2More specifically, the chapter “Modeling Users: Personas and Goals” has lots of details about the advantages of personas and the different goals they might have. After finalizing our map, we made a list of goals and characteristics for each persona and then checked them again for redundancy.

The four personas that we created were Sharon, Boris, Chris, and Paul:

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. 3Here we referred to “Scenario-based design” by John Carroll, an old but still relevant book. 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.

Sketches

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.

Paper prototypes

Evaluating the paper prototype

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.

Interactive prototypes

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. 4I 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.

Evaluating 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.

Final prototype

Our final interactive prototype showcases three main functions:

  1. Connecting musicians: users can create a profile and search for other musicians in their city.
  2. 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.
  3. 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 realised 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.

A step I enjoyed was creating negative scenarios. Too often designers present a product as the ultimate solution to a problem, glossing over the negative consequences of their design. I think It’s important to know when your design works but also when it doesn’t and what are some negative things that can happen when using it, whether anticipated or not.

In retrospect, I would probably do a few things differently: I would definitely run this project in a better season, so that it wouldn’t be so hard finding more than a few street musicians. I would also try to make Street Sounds a more subtle part of street culture, maybe by using some physical devices. Visually, the interface for sure screams “Google-inspired!” in many parts. What can I say, card interfaces were all the rage back then. But overall, I am happy with what we did and I am glad for this exhaustive (and exhausting) immersion in design methodology.