Position: CEO and co-founder
Background: Smule is a leading application developer focused on interactive audio media, producing such mega hits as the apps Sonic Lighter, Ocarina, I Am T-Pain, Glee, and Magic Piano.
Link: http://smule.com/
Ken: When did you first come up with the vision for Smule? Did you know right from the start that you wanted to focus on a particular genre of apps and consumers or did that evolve over time?
Jeff: The company’s cofounder, Ge Wang, and I believed it was time to redefine what music meant, and that a commercial platform could substantially amplify some of the research in computer music at Stanford and Princeton. Music is inherently a social experience. There are opportunities now afforded by amazing new platforms such as the iPhone to explore the creative and expressive side of people, in the process forging new social experiences. Having said as much, our initial focus was to not focus and instead to experiment. We lacked conviction on whether our vision would be appealing to the masses. We also had several theories we wanted to test in the process. Yet the heart and soul of the company from inception is the exploration of a new social medium through expressive audio.
Ken: Discuss the first app Smule ever created. What were the biggest challenges and lessons learned from that experience? What are you doing differently now after having launched seven apps?
Jeff: Our first application was Sonic Lighter, the 19th virtual cigarette lighter in the App Store and one of the few paid lighters. Miraculously, Sonic Lighter catapulted to the #1 position in nearly every major App Store geographic market. I think people were fascinated with the ability of one iPhone to ignite another iPhone, in our case sending network instructions over sound via the built-in speaker and microphone. I also think people loved the globe view, now famous in our apps, where you could track actual ignitions of others across the world. It seemed there was some solace offered to people to see others igniting their flames. For a while, Paris dominated in kilojoules burned per day, but alas, Tokyo unseated Paris a few weeks later.
Ken: Looking across Smule’s suite of apps, including I Am T-Pain, Leaf Trombone, and Ocarina, you seem to have a recipe for success. Without revealing any Smule secrets, how have you built so many successful apps? Is there something in your process that helps you ensure there’s demand or interest for an idea you have?
Jeff: We found that our belief in the creativity of our users has been a winning formula. If we set the conditions right and give them a little nudge, it’s amazing what our users can do with our products. I think people are exploring music and exploring how they might express themselves, be it singing “I’m In Luv (Wit a Stripper)” along with T-Pain, or simply igniting their flame in the Quartier Latin. If people actually want to use our products and share that experience with others, then we have a winner.
Ken: When it comes to incorporating external perspectives (e.g., users or advisers) into developing an iPhone app, what is your advice to new iPhone app developers that don’t have something like the Smule brand behind them? That is, where did Smule start with finding these groups before there was a “Smule,” and how can new developers do the same?
Jeff: Well, we think a lot about how users are going to find us, and how they are going to find each other. If you are considering these issues after you’ve built your product, you are too late. If, instead, you are thinking about this before you write a line of code, then I think you have a good shot at truly empathizing with your users and exploring what experiences they might develop with the products. We also test this with actual users. In fact, this past winter, we were three months into a project we terminated after the feedback of the first user test. We probably ate $500,000 of development and art costs. [That was] not an easy decision, and thank goodness we had an understanding from our board of directors. But unless we believe we have a compelling experience, we don’t want to put our name on it.
Ken: Describe how Smule determines when an app has enough features to be ready to launch into (or be updated in) the App Store. How do you ensure that you don’t spend time building features that won’t help you sell more apps?
Jeff: We try to identify the most compelling use cases out of the gate, and...as soon as we can test these, we do. We then study our analytics data for all applications in a postmortem of sorts, constructing what we call a usage waterfall. This table of graphs helps us compare our hypothesis at launch to actual usage data. From this, we can take some of the learning and apply it to future products. For example, we were astonished to learn that our users of the Leaf Trombone cared little for the achievements, [and] instead simply wanted to go judge others on the world stage. We could have saved about a month of development time if we knew this in advance!
Company: Sophiestication Software
Position: Founder
Background: Sophiestication Software is a small software design and development company, which is run by Sophia Teutschler, who describes herself as one of those “rare female developers.”
Link: http://www.sophiestication.com/
Ken: Your app, Articles, entered a category that already had other solidified Wikipedia companion apps. Despite that, not only did you proceed with launching Articles, but you were able to do so with incredible success. How did you identify the opportunity that there was space for another Wikipedia app?
Sophia: When I’m brainstorming new app ideas I always start with the question “What do I miss on my iPhone?”
The idea for a dedicated Wikipedia reader dates way back to early 2008, when I collected the first ideas for iPhone apps I wanted to make. A shopping list, a package tracker, a tip calculator, a Twitter client, a wiki app...nothing really groundbreaking was on my “want list.” Yet these were all apps that everyone would want to use.
I successfully implemented the ideas for the shopping list and the tip calculator. Over time, I lost the desire to implement some of the other app ideas, like the Twitter client and package tracker. I use great apps by other fellow developers now.
However, I never found a good solution for Wikipedia on the iPhone. Everything that was available was mediocre at best. I make apps, so the decision to fix the situation was crystal-clear to me.
Ken: What were some of the shortcomings you saw with other Wikipedia app options? What aspects did you want to improve or focus on less with Articles?
Sophia: Without any exception, it’s always the UI that bugs me with other apps. I’m not talking about the looks, but about the app’s behavior and interaction with the user.
There are many examples of how to improve a UI for use on the iPhone. One particular case for Articles is how it presents images. On Wikipedia, you usually tap on an image to open its dedicated page. There you are presented with an enormous amount of metadata you don’t really care about. The image itself, however, is still displayed in a rather small resolution. So, you have to tap on a thumbnail again to finally see it in full size. Yet it’s still presented with a bright white background and the blue Safari toolbars...sigh.
On Articles, tapping on an image simply zooms into the photo in full-screen mode. That’s the kind of simplified user experience I’m targeting.
Ken: Articles has a great app icon, a very polished design, and an intuitive user experience. Was this part of what you thought would make your app better? In general, what is your perspective and philosophy about designing iPhone apps?
Sophia: Making apps is my job, and my only job. This is what I’m doing all day long. I don’t want to waste my life doing something mediocre. I want to be proud of what I make and feel the joy when hard work finally pays out.
Some people paint pictures, others form sculptures. I make apps.
Ken: Articles exists on the iPhone and iPad. Discuss your considerations and concerns in developing the iPad versus the iPhone version. In your case, was creating the iPad app more of a design or development task?
Sophia: The iPad was not even announced when I started developing Articles. I hoped for a device like this, but it was far too early to tell how it could turn out.
Creating the iPad app was definitely a design and a development task. Finding a great design and coding up the necessary changes was a considerable job, but mainly due to the time constraints I had in order to hit the submission deadline to be in the iPad App Store on day one. Being there on day one is a chance you only get once in your life!
Articles is sold as two separate versions for the iPhone and iPad. Releasing the app as a Universal binary was, sadly, not possible in this case since I had to make use of iOS 3.2-specific features. So, I had to test it on an iPhone running OS 3.2, which was only available for the iPad at that time. Apple basically made the decision [of whether] I should go Universal or not with Articles for me.
Ken: How early do you include your customers in getting validation of and feedback for your apps? Do you show them nonfunctional concepts or only present them with a working app when it’s ready? How long before Articles went into the App Store had people been using the app?
Sophia: I usually start off by showing several early mockups to family and friends. I try to explain what I want to do, how this and that should work, and why it would be better compared to a solution that might already be available.
During development, I widen the audience with other fellow developers and app experts. I usually end up with about 50 people testing the app toward the end of the final development cycles. Developing Articles took rather long. A handful of people already had pre-release versions of the app back in July 2009. This feedback helped a lot for me to understand how people, besides me, use Wikipedia on their iPhones, and therefore helped to shape the UI to its final shape.
The first beta versions went out to testers about a month before the app finally hit the App Store. The app was pretty much usable at that stage.
Ken: Putting bugs aside, what is the key feedback you receive from those who look at or test your app? How does that impact what goes into the initial version you submit into the App Store?
Sophia: The key feedback is definitely about how each person uses the app and the iPhone in general. Some people love typing with the keypad in landscape mode; others solely keep it in their hand and navigate with their thumb. It might not sound important at first, but things like these help me to find the ideal UI for the majority of customers. Though it might be worthwhile to mention that I never intend to please every single one. That’s simply impossible.
Get App Savvy now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
