This chapter is from the book
This chapter is from the book
This chapter is from the book
More Inputs to Outlining
Beyond that mental sweep, there are plenty of sources of input for outlines. When you have a meeting to hammer out details about a feature, an outline is a great way to keep track of all the topics, subtopics, questions, and decisions as you go.
If you have direct access to existing users (because you’re working on an existing product) or to members of your target audience, you can gain mountains of invaluable insight from them. After all, you can’t be sure to think of everything yourself, and the communication you get from users (support email, reviews, etc.) tends to focus on concrete shortcomings and not on presenting a complete and balanced representation of their needs.
There are a variety of ways to collect insight from the people who’ll be using your app. Here are some of the most commonly used ones.
- Interviews—This could be a formal process, in which you invite members of your target audience to participate in a structured session that you transcribe and then analyze for data; or it could be as informal as having a few key questions ready when you bump into a user in person at, say, a conference or trade show. If you’re good at getting honest answers out of people (something that’s easier when they see you as a human being), fifteen minutes of real conversation with a passionate user can be worth more than a whole week of meetings within your organization.
- Contextual inquiry—If you’re looking to help people do a specific kind of job, this is a fantastic way to get insight into the problems you’ll need to deal with. In a contextual inquiry, you visit users as they work, watch them do the work, and get them to explain it to you as thoroughly as possible. If you’re interested in this practice, pick up the book Contextual Design by Hugh Beyer and Karen Holtzblatt, its pioneers.
- Competitive analysis—If you’re planning to make something that fits into an existing product space, you definitely have some work to do to see what else is out there. What other apps do the same sort of thing as yours? Why do you think those developers chose the feature sets and made the design decisions they did? What might they know that you don’t? And most important, what’s so great about your app that someone would want to buy it instead of the other ones out there? Thinking through these questions in a systematic way can give you a much deeper sense of how to differentiate your product and make something truly valuable.
The Ideo Method Cards (described in the Preface) have quite a few more practices you can use to get to the bottom of what your users want and need.
Once you have a product out there in the world being used, outlines and bug databases are good ways to write up user feedback and the results of user research. Even if you read all the emails and tweets about your app and do occasional user testing, you should be fastidious about keeping track of what people tell you that they like and dislike about your app.
When you keep records, you can actually look up whether people tend to complain about how a certain feature works, or whether test participants have trouble with a certain interaction, rather than rely on notoriously selective human memory. But! Always remember that the user feedback you get does not accurately represent the whole of what users think about your app. It represents the subset of experience that could be articulated by the minority of users who had the inclination to write in. You can find much more about the developer-user relationship in Chapter 10, The Whole Experience.
If you’ve done software development, you’re probably familiar with version control systems (like Subversion or Git), which keep a central repository of all the changes the team has made to the source code over time. Version control isn’t useful only for code; you can and should keep all your design resources in it, too. Having access to the history of your design thinking is invaluable, and it keeps you from having to track down a lost sketch or design yet another gear icon because you can’t find the last one you made.
Version control doesn’t have to be intimidating; if you’re not the command-line type, you can use a graphical client like the superb Versions, by Black Pixel. (And its visual comparison tool, Kaleidoscope, is great for seeing the differences between versions of a design document.) Another excellent tool is Layer Vault, a web-based versioning system specifically created for designers.