One of the challenges we faced with introducing Stringer to the world was whether or not our idea about how you can structure your music would be understood by a larger audience. What makes sense in one’s own mind (or in small discussions with others) and what everyone else will see as making sense are two very different things. The initial idea behind Stringer was to take a basic shuffle experience and add functionality to it. We defined this (shuffle) using these two criteria:
– loads a random queue of your music
– plays one song at a time
Within the Music app on iOS, this is all you get. You go forward and backward, one notch at a time. Stepping outside of that stops the notion of shuffling and allows you to play an album or a few extra songs, but then that’s it. You essentially have to start over. We thought we could make that more flexible. The result is the app you see today. But we had a lot of discussions about what that actually meant to a person outside of our circle of understanding, and what that person might come to expect upon seeing it with fresh eyes.
We’ve received a lot of feedback from very engaged users with some great ideas. Pretty much every bit we’ve received so far is something that has crossed our minds and that we left out for one reason or another. But this single notion–what is the String supposed to be?–fueled a lot of discussion.
This is where we had to give the concept a shape and mold to it. The notion of a shuffle, of a random array of your songs, is one everyone understands. Creating a visual representation of that array automatically leads a user to have certain expectations about what it can and can’t do. We knew we would have to conform to certain technical limitations within iOS (we’ll talk about that in a later post, I’m sure) but we also understood that by allowing someone to take certain actions, it meant we weren’t really "shuffling" anymore, but doing something else–maybe building a playlist. Which muddied the original concept, and added questions and complexity. If we do this one thing, why can’t we do this other thing too? It adds development overhead and it adds time, as anyone can tell you.
You might be reading this and saying "well, so what–maybe it’s a playlist, just build that and don’t worry about it". It’s a reasonable position to take. Of course, we had no idea if anyone would even care about seeing music in this way in the first place. So we made choices about the interaction design, about what we show and how we show it, and about what someone can do at any given point in the app. Some users have mentioned that "the app would be perfect if it just did ______". In some of those cases, they might be right. But every choice we make has a cost: time, money, stability. When you have an idea you need to test, you need to pick a direction and keep going. You can always revisit things, but if you constantly add to it, you’ll never know if the core of it is enough.
In an earlier post, I mentioned that this is a case study for us. We needed to launch something to see if our thinking was even validated a little. This might be anathema to a lot of developers and designers, and making the decision to launch with what we had was a tough one, knowing if we could just spend a little more time on everything, it could all be just a little bit better. But it’s a 1.0. It’s the core of an idea that we can build on. We’re actively gathering feedback from a very receptive user base, and we’re thrilled to know that people like it at all. Now we can continue shaping it with purpose, in a direction that makes sense for the business we want, not merely within the vacuum of our own assumptions.