A key step in creating any new product or experience is clearly articulating what it will be. All too often, designers receive a list of competitive features based on a existing product or a request to make something just like Product X. Here are a few ways to provide better design requirements that may lead to a more competitive offering.
The first steps to creating great experience design requirements are to identify the potential customers and the story they are in.
Think about who will be having the experience you are creating. Identify some real people who are likely customers. What makes them unique? What problems do they have that you might be able to solve? It is helpful for everyone working on a design to have the same understanding of the potential customer. The best way to do that is to meet them in person. When it isn’t possible for the whole team to meet each of the representative customers, you need to find a way to represent those customer types. Personas are a frequently used technique for keeping the team focused on the customers. If you use personas, just remember to make them as real as you can. A good resource for learning more is The Essential Persona Lifecycle by Tamara Adlin and John Pruitt.
Next, think about the story you are trying to tell. What is the experience that your potential customers are having? It is often useful to tell the story along the lines of ‘a day in the life of John’ or ‘Julie plans a vacation’. A great story can help everyone on the team identify with the potential customers and think of ways to make their experiences better. Storytelling and storyboarding have been around for a long time. There is a great track record of using these techniques in creating great products and experiences. Walt Disney was a master storyteller. You may want to read up on how he used storytelling to help get the teams ready to create fantastic movies. If you are looking for some ideas on how to use storytelling in creating technology experiences, you may want to check out Storytelling for User Experience by Whitney Quesenbery and Kevin Brooks.
So, you have a story and characters defined. What comes next? How about a long list of product features in a requirements document? Or maybe a list of key competitors. Well, those have their place. But, if you are trying to enable creative and innovative concepts, hold off on those for just a bit longer. There may be some facts that haven’t yet been spelled out by the personas and storyboards. You may want to do a design requirements document. This spells out what the product or experience needs to do. However, it leaves out solutions. To help make that leap, it is time to let the designers take a shot at identifying some design concepts.
The designer or designers will do some creative magic at this point. Don’t really try to explain it. Everyone has their way of working. There are lots of books and resources on getting creative, brainstorming, etc. Having a talented cross-functional team helps for this step. You might want to check out the work of IDEO as an example of how this step works.
It can be very helpful to create many prototypes and mockups. These will probably start out pretty basic and get more detailed as the process moves along. The important thing is to generate many ideas and then start getting feedback as early as possible. For me, paper prototypes have been very helpful. They cost very little to make and can be great for doing early usability testing. One of the masters at paper prototyping is Carolyn Snyder. I learned this technique from Jarod Spool and Carolyn many years ago and have used it often. Carolyn captured the technique in her book Paper Prototyping: The Fast and Easy Way to Design and Refine User Interfaces.
You might be asking, “Now can I create that requirements document with all the features in it?” We are getting close, trust me. Maybe at this point, you should create some technical requirements, like what is the intended platform, are there any storage or memory constraints, etc. Any items that can impact the detailed design should be listed in a technical requirements document.
It is really helpful to be able to clearly communicate the leading design concepts. If you are creating something for a screen, like a web site or mobile device, wireframes are a great way to do that. These lay out a design screen by screen. As you step through the wireframes, you get a good sense of how the system is going to function. Wireframes should be your next deliverable. One of the better resources on creating wireframes is Communicating Design: Developing Web Site Documentation for Design and Planning by Dan Brown.
To wrap it up, you have identified the people who will use your product or experience, told the stories of how it is intended to work, identified key design requirements, prototyped and tested the designs with your potential customers, identified technical requirements, and finally created design specifications in the form of wireframes. You may have uncovered needs that have not yet been met in the marketplace. You probably created solutions that no one else is providing.
So, now, if you really must, you can create that list of features and requirements based on your competitors.
I hope you found this summary of creating requirements useful. Do you have a different approach? Maybe there is a resource you have found useful. Please leave a comment and let everyone know.
Copyright 2010. All Rights Reserved.