Chapter 5. Creating a Personal Manifesto
“A goal is not always meant to be reached; it often serves simply as something to aim at.”
In the previous section, we talked about the importance of having a team mission statement. Having a clear vision, regardless if you’re working on a team or developing software by yourself, is vital to being successful. After all, how can you possibly move in the right direction if you haven’t decided what you ultimately want to achieve?
Robby Ingebretsen, a developer and co-creator of Pixel Lab, a user-experience design and software development studio, believes everyone should have a personal manifesto:
I don’t have a dictionary definition of manifesto at hand. I’ve avoided looking it up because I’m willing to hijack it (take that, word meanings!). I think of it this way: a manifesto is a declaration of why the thing you do makes the world better.
Ingebretsen believes developers should have a singular, overarching focus. It should be a summarized reason for why we’re building software products.
In the previous chapter I discussed how our team builds applications to help our organization achieve “the highest standards of patient care and service.” That’s our team’s singular focus. If we’re not achieving that, then we’re not delivering on our mission.
But here’s another thing: not only should you have an overall mission statement, but you should also have a manifesto for each project you’re working on.
For example, instead of saying, “I’m building a travel application,” a manifesto would say, “I’m building an application that creates the experience and value of having a personal travel assistant.”
Ingebretsen suggests that software development shop FiftyThree is a prime example of how great products come from having a clear manifesto.
FiftyThree, based in New York and Seattle, is responsible for the wildly successful iPad application Paper. Just two weeks after its release in the Apple App Store, Paper received over 1.5 million downloads, skyrocketing it to the top of the charts. The application, which allows you to paint, draw, and sketch, garnered critical praise, and in 2012 it won an Apple Design Award.
In a March 2012 interview with The Verge, Georg Petschnigg, co-founder of FiftyThree, talks about the mission of Paper:
So Paper is—where ideas begin. Right? It’s the place where you go to—like—sketch and write, draw, color, outline. It’s—when you want to spend time with your ideas, Paper is the home for your ideas.
“Paper is the home for your ideas” sounds like a great manifesto to me. That’s a singular vision. FiftyThree didn’t set out to make another design tool or paint program. They built an application, displayed in Figure 5-1, which felt like the perfect home for your ideas. That’s a specific manifesto with a clear vision in mind.
When you approach your applications with a manifesto like FiftyThree did with Paper, it begins to shape your path and direction. It helps you know what features you want to include, and more importantly, what features you’ll leave out. By constantly comparing your progress against your vision statement, you ensure that you’re headed in the right direction. This leads me to my next point.
Exercising Restraint
A mistake that I see developers make time and again, myself included, is many of us allow our applications to become bloated with features. To me, when I see an application with too many features, many of which I don’t want or need, it’s clear to me that the developers lacked a manifesto or vision. They put technology first and became hyper-focused on what they could do and not what they should do.
I think the reason we do this is because, by our very nature, we love technology. We want to showcase it. To us, the value of our applications comes from what it can do.
When developers show off their work, what do they often focus on? They talk about the features, which showcase the elements they’re most proud of and the technological hurdles they were able to surpass.
I don’t think there’s anything wrong with being proud of our programming skills; however, we need to remember that they are of little value to users if we’re not giving them what they need.
For example, if we were making an instant messaging application, we might be excited that we’ve implemented GPS location technology, allowing users to see where their messages are coming from. However, if it’s a chore to send messages to a fellow user, how valuable is our application overall? Users may be impressed by the GPS location feature, but because the application fails at meeting their core needs, they’ll decide not to use it.
The phrase, “less is more” may come to mind.
In my experience, many developers struggle with this concept. It’s not that they don’t want their applications to be easy to use—it’s just difficult to decide what features are paramount to the experience. Developers often struggle with layout, organization, and prioritization of features. They make the mistake of hiding valuable features their users want in order to promote functionality they’re proud of.
Bill Buxton, principal researcher at Microsoft Research, has a primary axiom:
Everything is best for something and worst for something else. The trick is knowing what is what, for what, when, for whom, where, and most importantly, why.
This is why we must have a manifesto or some form of vision statement for our applications. As developers, we need a singular vision to return to when our development gets mired in features and technical roadblocks. We need to be reminded of what we’re ultimately trying to achieve.
One way to create a manifesto is by having a story to tell and knowing that narrative well.
Building a Narrative
FiftyThree wanted Paper to be an application that allowed users to capture their ideas. They wanted it to have broad appeal and not be limited to just professional artists. They believed that when people used Paper their ideas should flourish, not be encumbered by limitations or complex tool sets.
To achieve this, FiftyThree needed a story that aligned with their manifesto. They needed to clearly understand how Paper could accomplish what it was designed to achieve. The developers and designers had to evaluate features and functionality to make sure they made sense within the context of Paper’s story.
An application’s narrative is an ongoing story of how the application shapes the lives of its users. Manifestos are a specific and declarative statement, whereas narratives can be rich with detailed scenarios of how the application will be used.
Julian Walker, the lead engineer behind Paper, says that FiftyThree didn’t implement a specific product development technique. Instead, they relied on their story for Paper:
At Fifty Three, we don’t have any hifalutin ideas on product development—we’re not out there professing any techniques, but what we started calling our process was “narrative-based design.”
Developers always tend to want to give the user more power, especially if they can—easily. They’re like: “The feature’s almost built. All we have to do is add the button!” And that may not always fit into the story.
When you use Paper, you can see that FiftyThree’s story did not include having a lot of features. Julian is a brilliant engineer, and I have no doubt that he could’ve built a complex design tool. But complex features didn’t align with FiftyThree’s vision. They felt out of place within Paper’s narrative and manifesto.
Paper has only six tools and a limited set of default color choices, which is completely intentional. By exploring the act of generating ideas with drawing and painting, FiftyThree realized that other applications reduced creativity by overloading users with features. Paper has since been updated to include a color mixer, but it’s still clear that FiftyThree approaches each additional feature with restraint.
Paper’s narrative encourages simplicity by enforcing reduction. When using Paper, you become focused on what you want to draw, not how you want to draw it. This reduction in complexity allows users to focus on their creativity, and this is the key to Paper’s success.
For example, let’s say I’m working on a line of t-shirts for a promotional giveaway. As I begin to sketch, Paper’s design—or narrative—keeps me focused on the overall concept of my idea. For instance, if I’m making one of the shirts red, Paper provides only one shade of red to choose from. I pick that color and I move on.
Other design tools would present me with a color picker and virtually limitless color options. When I’m given that many choices, I begin to focus on picking the perfect color of red. That’s not to say having options is a bad thing (eventually FiftyThree did add the ability to mix colors); however, it works against FiftyThree’s manifesto. They want me to stay focused on my idea for the t-shirt design, not picking the perfect color.
As it turns out, FiftyThree’s narrative-based design works very well and, as a result, I’m much more creative when using Paper. By reducing color choices and providing limited but highly stylized tools, Paper is unlike any other application I use for my creative needs. Therefore, it’s become my default tool for exploring ideas and early concepts.
Just as Petschnigg described, Paper has become the home for my ideas.
Consider the story of your application: What elements should it include? What elements should be left out? Are the features you’ve provided following the story you were trying to tell?
Creating Personas
One way you can augment your narrative is by creating a persona.
A persona is a character-driven element that helps you remember who you’re building the application for. It’s a fictional character that is a personification of your real users. To create a persona, you should be asking your users questions like:
Name one of your favorite products. Why is it better than other similar products?
What product frustrates you the most? Why? What would you do to improve it?
If you could create the perfect application to help you with this task, what would it look like? What would it do?
By asking questions like these, you’ll gain a better understanding of what motivates your users and what experiences they enjoy. For example, listening to a user describe features they love about their music player may provide insight into a sports application you’re building. At first, it may appear that these two products are unrelated. However, if you’re willing to listen, it’s possible that you’ll learn new ways to improve the user experience in your own applications.
With the information you collect from your users, you’ll craft a persona. It should include details like:
Name
Age
Marital and family status
Location
Occupation
Hobbies and favorite items
Needs and frustrations
It can also include pictures of what you imagine the person looks like and any other information that brings the persona to life. In Appendix A you’ll find an example persona for a user of Paper for the iPad.
The persona can prove vitally important in situations where you have distance between you and the user. An example might be if you’re creating something for the mass market, like a smartphone application. If you’re not working directly with users, the persona will describe the type of people using your application. If necessary, talk with prospective users and create a persona from your findings. You might even use them to create your persona directly (removing their personal information, of course).
A persona is a highly reflective instrument that helps you consider all aspects of a user. With it you can dive deep into their psyche and imagine what motivates them. You spend time articulating their frustrations and what makes them happy.
When the persona is rooted in the information you’ve collected from users, it can have a very tangible effect.
Creating Scenarios
Once you have personas to reflect the users of your application, you can begin the process of creating scenarios. Scenarios are mini stories that reflect situations your personas may find themselves in. In a scenario, you pay particular attention to how your application will enhance the experience of the user.
The more detail you have in your personas, the easier it is for you to imagine how they will react to a given scenario. As its name implies, scenarios are like scenes in a movie. The persona is the character, and your application can be seen as the plot device, or a way to advance the story.
Ideally you’ll create many scenarios and situations that your persona will encounter with your application. If you’re honest about your application’s limitations, exploring different scenarios can help you understand just how much of an issue a particular limitation is.
For instance, let’s say we’re building a smartphone application that helps Susan, our persona, find low-fat recipes. Here would be some appropriate scenarios we might encounter:
Susan is at home. She’s looking through her cupboards and trying to locate items for a chosen recipe. How might our application help with that?
Susan is at the park with her children. She wants to find a lasagna recipe to cook for dinner. What features of the application would she use to accomplish this?
Susan is talking on her smartphone with a friend about a recipe for a low-fat casserole. How might she send this recipe to her friend? Could she accomplish this without hanging up the phone?
Susan is out shopping and wants to locate a particular spice that’s used in a recipe she’s found. How would the application assist her in finding it?
Scenarios can be as detailed as needed in order to envision how your application will respond. Additionally, when you combine these scenarios with the rich personalities of your personas, you can evaluate your design decisions and decide if they meet your users’ needs.
As a part of the user-centered design process, you should take time to consider your narrative, personas, and scenarios: each of these will help you create a clear path to your goal. It can also help you realize when you’ve strayed from your vision and added unnecessary features. If possible, let users review your personas and scenarios and allow them to give you feedback.
The combination of a manifesto and a detailed narrative with personas and scenarios can shape the path and direction of your software development.