As some of you may know, I’ve been lucky to be a small part of the team behind Swell, a new kind of radio experience built initially for iPhone. After spending many months in stealth mode leading up to our public release at the end of June 2013, I finally gained some perspective with which to reflect on all the little product and strategic decisions the team made to deliver what is, in my (biased) view, a great version one product in a crowded, competitive, and noisy consumer app marketplace.
About two months into the wild, we are fortunate to have received some nice feedback and organic mentions on Twitter, where much of our core audience resides. Undoubtedly, completing version one only means that we have a long way to go, things to add and mistakes to learn from, but with that said, there could be some useful lessons hidden in the tiny decisions Swell made that may help the next mobile developer down the road.
This post is an attempt to collect those decisions and analyze them with the benefit of hindsight, as well as to share them with you all. The list may start with obvious elements, but please bear with me as the decisions get more precise.
1) Platform – Mobile vs. Web: The team wanted to leverage its expertise in bringing complex technologies to mobile. Given their experience with SnapTell, that meant focusing on the latest iPhones and iOS. It may be en vogue to comment now that it’s time for Android-first, but from a technology development perspective, going that route is either too risky or too difficult for an early-stage startup that has limited resources and time. (The web is a great place to test ideas and build an audience, as well as being a tool to help hack mobile distribution, but the team didn’t feel a web player for Swell radio would deliver a “wow” experience.)
2) Searching For A Daily Active Use Case: One lesson the SnapTell team learned is that using a mobile image app for shopping wasn’t something people did every day. On mobile, the trick is to find a daily use case. The team began to focus on commuters, specifically those commuting by car and train. The idea is that if we could provide value to them during this activity, it could be a daily habit, though any solution would still compete with music, audiobooks, phone calls, terrestrial and satellite radio, and other talk-radio apps for consumers’ time.
3) Foreground vs. Background: The battle for consumer attention is fierce, and no place more fierce than the iPhone. Everyone is building apps that require our eyesight and attention. Some of us are stuck in Twitter, and others are stuck in Facebook, and it’s hard to use these apps when we are not focused and working inside them (outside of push notifications, which can be distracting). Therefore, building on the trend of more “background-related services” in applications, the team decided to focus on a consumer solution that could provide value in the background while the consumer focuses their attention in the foreground on apps like Twitter or Waze, for instance. We didn’t want to compete with these big attention-grabbing apps — we wanted to complement them.
4) Category Specification: The “News” category in the Apple App Store is densely populated. News is, indeed, a competitive category. But, people want news every day. So, instead of trying to build another news reader, the team investigated the audio news category, which still has competition but is not as crowded, relative to the readers. In this process, the team discovered that a treasure trove of quality audio content was either freely accessible through public APIs and/or buried in the world of online podcasts. This presented an opportunity to find the best content, to classify it in a new database according to a new ontology, to rank it based on a human expert’s understanding of audio content, and to remix that content to deliver to consumers a new, personalized radio experience.
5) Mobile-Specific Optimizations: The timing of this company coincided with some important opportunities presented by the advancements in cellular network technologies and mobile hardware. In order to deliver a streaming audio experience, mobile consumers would need to dip into their cellular data plans to enjoy the product. Luckily, the streaming costs for audio are quite low relative to video, and they are decreasing. The company went steps further to optimize this for users by building a smart buffering system to pull content to the client when the device is on a Wi-Fi network. A step more, the team built functionality inside the app for the consumer to allocate more client-side storage for content to listen to the audio in an offline mode style of consumption. Finally, these improvements also minimize drain on the handset battery.
6) Quality Content & Personalized Content: The company started out with a desire to build an application that would have the chance to become a mainstream consumer hit. To fulfill that promise, the team recruited an experienced audio producer from the world of radio and media to organize, classify, rate, and license the best content. The result is a valuable repository and ranking system that contains a library of audio content. On the personalization side, the team built an algorithm based on collaborative filtering (i.e. listening and learning from the amount of people who actually listened to a piece of content) to continuously learn about the consumer’s preferences and tastes and, theoretically, become smarter over time. Inspired by what Pandora has unlocked for our musical tastes, the goal was to build a similar system for audio news and information.
7) Interface Design: It’s cliche to point out how important interaction and visual design are for consumer-level apps, but it bears repeating here, because, as more and more people transition to apps over the web, the experience becomes more like a game and, conversely, raises the stakes for providing a simple experience that doesn’t turn off or frustrate a user. The team recruited a founding designer from the gaming world to design an interface that would both be simple, novel, and fit the needs of people who are driving. That means it involves thinking about everything from Bluetooth integration to locked home-screen controls for iPhones. One of my favorite interactions is the ability to “Skip” through content by swiping cards. In regular terrestrial radio and satellite radio — and even most mobile radio apps — the user has to either turn a dial to tune their experience or search for what they may like. In our app, the “skip” is the dial.
8) Passive Over Active: Many apps get thrown into the market with a ton of features slapped on and “social” awkwardly baked in. We made a conscious decision not to do this. Instead, the company designed the application to be of high use to just one person, to offer a high-quality “single-player mode.” Furthermore, the company elected to focus on delivering content to consumers in a “lean-back” mode, like Pandora, where the user has some basic controls but essentially doesn’t have to do any work to enjoy the experience. In addition to being complex on many dimensions, many apps these days ask the user to do more work than many people have an appetite for. As a result, the radio app was designed for a user to simply hit “play” and then have relevant content delivered to them.
I’d like to underline again that all of this, in no way, implies or assumes success. And mistakes were made, indeed. It is a continual learning process, and there is a long, long way to go to keep threading the needle. Additionally, there are many decisions that couldn’t be included in this post but are no less important to the company. Here, I wanted to focus on the steps we took to conceptualize and build a mobile-first product. Today, with the benefit of hindsight, these decisions may look good, but as things were unfolding and in the moment, it just happened to be a series of seemingly small decisions that, over time, thankfully combined to form the foundation for what the Swell product experience is today.
Photo Credit: fdecomite / Creative Commons Flickr