From the subtitle of this book—“Turning Ideas into iPad and iPhone Apps Customers Really Want”—you might have an inkling that staying customer-focused is the key part of successfully bringing your app to the App Store. Yes, I’ve asked you to do some research, quantify your idea, and think strategically up to this point, but that was all done for the purpose of interacting better with your customers. The voice of the customer is what will mitigate the risk of you launching an app that no one wants to download.

Interacting with customers this early in the development of your app will provide several benefits. First, customers will be instrumental in validating the initial assumptions you have about your idea. Although you’ve done a pretty intensive analysis of the market and now have a set of assumptions about the features you’ll need to focus or not focus on, it’s still possible that you have missed the mark. Customers are people, and people are highly opinionated. If you’ve over- or underestimated the importance of a problem your app is trying to solve, you will hear about it.

In addition to validating assumptions, you will learn what customers consider the primary reasons your app will be worth downloading or buying. If you do your job right, they will become your chief advocates in the App Store and on the Web. They will continue to promote and support you, and provide ideas and feedback well after your app becomes available on the App Store. Thus, the second motivation for you to begin engaging them now is that these interactions will be the first investment in a long, mutually beneficial relationship. Besides the fact that you will be trying to build an app these customers find useful or fun, you will be surprised by how excited they get about testing apps (and later, features) before they are available on the App Store. So, don’t think that their involvement in the process is a chore or task for them. In fact, if you get a sense that it is, you probably aren’t dealing with the right kind of customer.

The last major benefit of interacting with customers even before you have an app built is that this will officially begin the marketing of your app. You didn’t misread that. Your marketing will begin the moment you start talking with your first customer.

Don’t be concerned if you aren’t a “marketer.” By focusing on building a compelling app, you will find that marketing the app will come more easily and naturally to you. This approach is proven inside and outside the App Store. If you embrace this philosophy, your marketing efforts will progress as the development of your app progresses. In this sense, you should think about the marketing of your app as a crescendo. Anticipation and demand for your app should continue to build, until a sort of climax occurs when your app launches on the App Store.

Although I discuss marketing in Chapter 8, I wrote that chapter so that it parallels the development of your app, so you should begin referring to it now. Turn to Chapter 8 and read up to the section Your Marketing Crescendo, and then come back here. I know this approach can result in a somewhat disjointed reading experience, but the benefits are worth it. Please don’t ignore this advice and arrive at Chapter 8 sequentially, or you will miss out on key opportunities for generating interest and buzz for your app.

Before you can search for customers, you need to have a basic sense of who they are. Your app may appeal to a particular demographic (e.g., 30-something females) or interest group (e.g., gamers). If you consider these factors to be particularly important, you’ll want to avoid those who fall considerably outside these spheres.

If you think your app has a more expansive appeal, you can use your knowledge about the existing app landscape and the solutions or alternatives that are available to help develop your understanding of who your customers are. To give a better structure to your observations, you might create a description of who your customers are, or more simply, write down the distinguishing factors you’ve identified.

Although it is more extensive than you really need at this point in the process, the approach taken by Bryan Eisenberg and Jeffrey Eisenberg more fully describes how to generalize information and behaviors about customers by creating “personas.” In their book Waiting for Your Cat to Bark? Persuading Customers When They Ignore Marketing (Thomas Nelson), the authors describe the use of personas in marketing—but the philosophy behind creating them is most relevant: to segment or group customers based on shared qualities and attributes.

To reiterate, at this point you only need a basic sense of who your customers are. You should consider this exercise anecdotal and not scientific.

Now that you have a basic understanding of who your customers are and you have a sense of the traits they should exhibit, it will be easier for you to find them. You don’t need to talk with hundreds of customers. In fact, for independent developers who are creating consumer-oriented apps, engaging with as few as 7 to 10 customers may be sufficient. Depending on the scope of and budget for your app, you may want to talk with up to 30 or 40. The general guideline for when to stop talking to customers is when you start hearing the same feedback over and over again.

Along with knowing traits about your customers, you may have some instincts regarding where best to find them. In general, using your contacts to make referrals and leveraging the Web will be the best methods for doing this, considering the more tech-savvy audience you’ll want to engage.

I’ll get to how you introduce yourself to customers and what you will be discussing with them momentarily, but for now, I’ll outline some ways to find them.

Getting the names of customers to contact is half the battle. I’d argue that it’s also the more boring half because it’s logistical in nature. Once you actually have a list of those you want to talk with, you’ll get back to focusing on how to improve or validate your app idea.

I’m ashamed to admit that way back in middle school I stayed after school for extra help...in art class. I was a bit of an overachiever, but generally speaking, where the rest of my family seemed gifted in painting and drawing, those skills just never came naturally to me. In spite of that right-brain deficiency, I went on to oversee multimillion-dollar websites, build highly visible startups, launch successful apps, and more generally make a livelihood being creative.

The reason I share that embarrassing anecdote is that if you don’t have artistic abilities, this doesn’t mean you won’t be able to help architect your concept app. Although I’ve come a long way since making my poor art teacher stay after school, I owe part of my success to realizing how best to focus my energies. Where I add the biggest benefit, and where you can too, is not in making things look pretty; there are extremely talented people who will help you do that. You will make better use of your time and progress your app further overall by being disciplined in attending to the larger vision and not the design details.

Depending on your exposure to design, and in particular, to web design, the term “wireframe” may or may not be familiar to you. In the web world, wireframes (see Figure 3-2) are visual guides that highlight key elements, structures, and relationships among the web pages of a website. Wireframes are typically created in black and white, with little or no use of font styling (beyond font sizes) or images, instead keeping the focus on the architecture and layout of the site.

Figure 3-2. Example of a web wireframe

Of course, the larger idea behind wireframes was not birthed with the Web, nor does it stop with it. Ultimately, the advantage of including wireframes in any development process is to focus on getting the structure and functionality right, before spending significant time making it visually appealing. When mixing structure and design, it’s possible to bias customers with something that looks good but is not necessarily easy to use. Similarly, it is significantly harder to revise a concept that includes design elements. Consider, for example, how much easier it is to move a room in a house when you’re working with a blueprint than it is after you’ve started building the structure. Since you’ll be using wireframes to develop the first draft of your concept app, keeping the wireframes focused on the structure and flow will allow you to quickly iterate and revise the design when you get additional feedback from customers.

The secondary benefit to wireframing your app goes back to my point in the preceding section. You won’t get wrapped up in ensuring that the app looks right and instead will focus on the two or three key screens and functions of your app.

Creating wireframes

Creating wireframes is considerably easier today than in the past, thanks to the graciousness of the larger development community and some significant advances in software tools developed specifically for wireframing and rapid prototyping. For this reason, I do not advocate wireframing on paper, although some people may be more comfortable with that. Just remember that you’ll want to continually edit and share your wireframes, so having a digital copy will make this process smoother.

Note

It’s much harder to wireframe if you are designing a game versus most other apps, because significantly more artwork is required when dealing with games. You still should spend some time thinking about the game mechanics, rules, and flow, which can be captured in a wireframe. It also might be useful to either sketch character ideas (if needed) on paper, or hire someone who has a relevant background, such as a graphic artist, to do that for you.

In creating your wireframes, start with one or two screens that focus on what you discussed with your customers. These should be the defining screens of your app, representing the core of your offering. As questions arise about how the user should interact with elements on the screen, add those thoughts to the wireframe as an annotation or note. Don’t get caught up in trying to answer all those questions now; at this point, it’s more important to identify questions and problems than it is to answer them. It is also sometimes helpful to include screenshots from competing apps or apps you admire as a page within your wireframes. These can be used to remind you of what other apps are doing and also serve to inspire your own user experience (UX).

In the following list, I’ll highlight a sampling of some of the wireframing tools I’ve used or recommend. Each tool relies on stencil libraries—a collection of shapes you can use in the wireframe—which include the core UI components for the iPhone and iPad. I list them in order of simplicity and usefulness, although your experience may dictate differently. Having been a PC user for many years, I am sympathetic to those using that platform. Thankfully, a more popular choice—Balsamiq’s Mockups for Desktop—is also available for those using a PC. The others require a Mac, iPhone, or iPad.

Wireframe Example

Figure 3-3. Tweeb Summary tab

To give you a frame of reference for what an app wireframe looks like, here is a screen (see Figure 3-3) from a final round of wireframes for my app Tweeb. I’ve been wireframing for some time now and this definitely represents a more polished and sophisticated wireframe using a more advanced tool (OmniGraffle for Mac).

Based on feedback I received from customers, this wireframe went through about five to seven rounds of revisions. At this stage or even at the end of wireframing your concept app, you won’t need to get to this level of detail. I’m including it to show you how much can be communicated in a wireframe without really focusing on the design. In Chapter 5, I’ll show you how this wireframe was translated into an actual design.

Balsamiq Mockups for Desktop

Balsamiq’s Mockups for Desktop (a.k.a. Mockups) is probably the best tool for those just getting started with wireframing. I’ve seen people who have never created wireframes produce very well-thought-out concepts using Mockups. This is because Balsamiq has distilled the key iPhone and iPad components into its tool, including only what’s necessary to create a concept app. It also makes its wireframes appear like hand-drawn sketches, even though they are digital. This helps those creating the wireframes and those looking at the concepts to focus on ideas and not on design.

Mockups also offers a nice way to link wireframes together, which is useful once your concept has matured. Putting Mockups into presentation mode for a customer allows the customer to navigate the app through these links by clicking elements on the screen. Balsamiq’s CEO, Peldi Guilizzoni, discusses this feature, and more generally, the purpose of wireframing, in an interview at the end of this chapter.

For more information, see http://www.balsamiq.com/products/mockups/desktop.

iMockups for iPad

iMockups for iPad, by Endloop (http://endloop.ca/; shown in Figure 3-4), is similar to Mockups. It initially launched with the opening of the iPad App Store and only exists on the iPad (at the time of this writing).

Creating a wireframe on the iPad (whether it’s for the iPad or the iPhone) is a unique experience because everything is controlled by touch. I find that paradigm allows me to much more quickly draft a wireframe at the expense of it being less detailed. Because of that, it is a good place for you to draft your wireframe, since it won’t allow you to obsess over details. iMockups can also export files for use in Balsamiq’s Mockup tool.

For more information, see http://itunes.apple.com/app/imockups/id364885913.

Figure 3-4. An iMockups wireframe I created in less than a minute on my iPad

OmniGraffle

OmniGraffle is a full-featured Mac and iPad app used by many information architecture and user experience professionals. It can do much more than wireframing, which results in it requiring a little more patience to learn. This also results in it being the most expensive option to use on your Mac or iPad.

The stencils you’ll need to wireframe for the iPhone or iPad aren’t bundled with OmniGraffle. Because of its popularity, however, they are easily downloaded for the Mac from sites such as Graffletopia (http://graffletopia.com/stencils/tags/iphone).

It’s not fair to say that you should “graduate” to OmniGraffle, because the other tools are extremely capable of helping you get your job done. My recommendation, however, is to start with the other tools and then expand your horizons based on needs. For example, I use all of these tools together, and sometimes will start a wireframe in Balsamiq’s Mockups and then revisit it in OmniGraffle. If you are creating wireframes for a client, you may also consider using OmniGraffle to create a more polished wireframe.

For more information, see http://www.omnigroup.com/products/OmniGraffle/.

Other tools to watch in this space include Interface, Stencils, Review Sync, Live View, and Screenport. Interface (http://lesscode.co.nz/interface) and Stencils (http://www.stencilsapp.com) are iOS apps that allow you to link together the mockups you create, showing how they progress from one screen to another (similar to Balsamiq Mockups, but on the device itself). There’s also a growing trend to wireframe in Apple’s Keynote, which most Mac users have installed on their computers (e.g., http://keynotekungfu.com/ and http://keynotopia.com/).

Review Sync (http://getreviewapp.com/), LiveView (http://www.zambetti.com/projects/liveview/), and Screenport (http://tapmates.com/screenport/) aren’t wireframing tools, but instead allow you to easily display your wireframes or design assets on your devices.

I don’t want to make this process seem as sequential as I wrote it in this chapter. You may, for example, need to have subsequent discussions with customers to receive confirmation of your assumptions. That is, you should not necessarily begin drafting a wireframe until your ideas have been validated and you have identified and understand your customers’ problems.

With wireframes, you need to be careful about which customers to show them to and at what point. Don’t use your first attempt at wireframes to get reactions from customers. You’ll want to revise your ideas, and possibly get some immediate comments from friends, family, or colleagues. You should solicit feedback from customers once you have two or three screens that have gone through some amount of revision and feel complete to you. Make sure they communicate the direction in which you are trying to take the app.

When you do present wireframes to customers, ensure that they understand why you used wireframes. Be selective with the number of customers who see your wireframes, because even with the context you provide, they might not understand their purpose and be turned off by how basic they look. Although the wireframes will allow you to get additional customer insight, in many ways they will be more important to you and others that help you build your app.

Company: KISSmetrics

Position: Product manager

Background: Cindy Alvarez is the product manager at KISSmetrics, where she is currently building two products (KISSmetrics and KISSinsights) using customer development and lean startup techniques.

Links: http://www.cindyalvarez.com/; http://kissmetrics.com/

Ken: You are a leading voice in using “customer development” to build products. What is that and how does it help people build better products? More specifically, why was customer development conceived and what problems does it try to solve?

Cindy: Customer development is a set of techniques to identify your market, understand their pain points and priorities, and validate that they’re willing and able to solve those pain points—before you start building a solution.

It’s the opposite of “if we build it, they will come” thinking—who can afford to take that kind of risk? By working closely with early customers, you are not only learning about the market, but also building your leads list. The people you interview will become your beta testers, the first people to give you their credit cards, and hopefully, the people who recommend you to their peers.

Customer development also forces you into ruthless prioritization. In a traditional product development roadmap, developers want the first release to be perfect and include all of their pet features. When you have engaged early customers, you know what the most critical features are and you feel the pressure to release them as quickly as possible. You can often omit features that you internally thought were critical but your customers just don’t need.

Ken: A big part of customer development is about validation. When you talk with customers, what specifically are you learning from these interviews and how do you ensure that you are learning the right things?

Cindy: For one thing—and this should encourage anyone looking to start customer development—people are incredibly willing to talk and share details about their behaviors. The trick is to focus on that person, on his or her experiences. Your customers should never feel like they have to “study” in advance of your interview.

Some of the questions to explore in interviews include:

Fundamentally, your product needs to maximize rewards and minimize barriers to adoption for your target market. What does this customer find motivating and exciting? What does this customer find off-putting or intimidating? You need to understand those levers and align your product with them.

Ken: How early is too early to begin the customer interaction and interview process? That is, what should be a baseline before interacting with potential customers? Is some sort of visual required?

Cindy: The biggest mistake most people make is waiting too long for customer interaction. The more mature your idea is, the harder it is to collect raw customer feedback. It affects the way you frame your questions as well as the way you filter their responses—tending to magnify comments that agree with your idea and minimize those that don’t.

It’s certainly not impossible to do customer development with a well-developed idea or prototype, but it can be a challenge. If you have a visual to show customers, wait until the end of the interview to do so. Get as much raw input as possible first, because once customers see something they will subconsciously tailor their answers based on what they’ve seen.

Ken: What do you do with customer feedback and how quickly do you go back to them once you’ve digested and potentially implemented anything they suggested? How do you ensure that you aren’t fatiguing customers and are properly respecting their time?

Cindy: I send out “what we’ve learned” updates about once every six weeks to all beta customers. If certain people helped bring an issue to light, I’ll usually follow up twice—once to confirm that this is a priority for us, and again when it’s implemented.

I think people worry too much about overcommunication—when you take customers’ input seriously, they feel a sense of ownership. They want to hear back from you! Just remember to do more updating/thanking than asking. I try to maintain a 2:1 gratification to “ask” ratio.

Ken: Who are the other voices that help influence the evolution of a product besides customers? How do you balance or include the perspectives of advisors, bosses, analysts, and other stakeholders?

Cindy: Customers are the experts in what their problems and priorities are, not how to solve them. They don’t care about you building long-term sustainable competitive advantage or developing new technologies, and they don’t know where social or technology trends are heading.

Ken: Are there any tools you use regularly to help coordinate or facilitate customer development? What do you use to keep track of everything you are learning and for interacting individually or corporately with customers?

Cindy: I use surveys to identify the best candidates to contact—it’s actually an internal tool that I use, but Wufoo is a great service for that. I track notes on our internal wiki and send out summaries via email to my team. With customers, almost all of my communications are via manually composed emails. It takes longer to write, but my response rate is close to 50%. You never get that kind of response rate to mass emails or surveys. It’s not very scalable, but that’s kind of the point—this is a hands-on, intense activity.

Company: Balsamiq Studios

Position: CEO

Background: Launched in June 2008, Balsamiq Mockups helps people build great software by letting them easily sketch out their ideas, then quickly collaborate and iterate over them.

Link: http://www.balsamiq.com/products/mockups

Ken: What is Balsamiq Mockups and why did you create it? Where does it fit in the process of building a product or application?

Peldi: Balsamiq Mockups is a simple little wireframing tool. It tries to replicate the experience of sketching in a notebook or on a whiteboard, but on the computer. It’s digital but still looks like a hand-drawn sketch, to encourage honest feedback and to help everyone focus on the structure of the application instead of graphic details, which can be dealt with at a later stage.

Our sweet spot is the early stage of the application design process, when you want to jot down your rough ideas and refine them with input from other stakeholders. It’s designed to be easy enough for nontechnical people to use, and powerful enough to be embraced by developers and designers.

Ken: For someone with no creative or software development experience, what are some of the biggest challenges to building a wireframe or mockup? What pitfalls should these types of people look to avoid?

Peldi: When I first started designing software, I remember having the tendency to want to add lots of buttons, options, and bells and whistles to my interface. With experience—reading a lot of user experience books and conducting a number of usability tests—I have learned that designing truly enjoyable software is about figuring out ways to solve problems in a way that’s as close to invisible as you can [make it]. It’s all about resisting the urge to add anything at all to the user interface.

Ken: Some might say your iPhone controls are too limited. Do you have a certain philosophy in what is or is not there for the iPhone specifically?

Peldi: We chose the main controls, which together with the rest of the UI controls included in Mockups should allow you to prototype about 80% of your applications. Once again, it’s about doing the 20% that covers 80% of the use cases.

We only provide the core to help you focus, but our users have been sharing other, more complex controls if you need them: http://mockupstogo.net/tag/apple.

Ken: What are some of the ways your customers are using Balsamiq Mockups to test out iPhone and iPad app concepts? Are there any best practices for putting a mockup in front of a potential user to get feedback?

Peldi: I have seen people create a row of iPhone interfaces, one screen after the other. Then to run through them you just scroll horizontally from left to right. If all of your screens don’t fit on one row, make another!

If instead you are using Mockups for usability testing, we suggest having one screen per file, linking them together, and showing them in presentation mode with the linking hints disabled. This way, your testers will click around and explore the prototype while you watch and learn in painful yet enlightening silence.

Most of all, don’t fall in love with your first or second wireframe. Sleep on it and come back to it. I bet you’ll be able to simplify it more and more.

Ken: Can you point to the best or most extensive examples of mockups you’ve seen created through Balsamiq? What is the easiest way for people to get started creating their first wireframe or mockup?

Peldi: There are people who create prototypes with hundreds of screens. We actually don’t encourage that with Mockups. In fact, if you’re creating hundreds of screens, maybe you should rethink your application design to simplify it!

To get started, I would just download the demo from http://www.balsamiq.com/products/mockups/download and start dragging things around. Maybe try to reproduce an application you already know out of memory—I usually do iTunes. Or start from one of the many examples posted on our community-powered website, http://www.mockupstogo.net. There’s lots of good stuff there.