In last month's article, I reviewed ten questions that you should ask if you are planning ahead for a web development project--the kind of questions that are necessary to at least consider, if not answer, before you engage an interactive firm officially. That kind of planning is a bit different from the initial planning phase of a web development project, the type of planning I'll be discussing in this article.
The planning phase of an active web development project primarily involves two endeavors: creating personas upon which to base the structure and purpose of the website, and planning the site's information architecture and functionality with an interactive prototype.
Steve Mulder, author of The User is Always Right, defines a web persona as a "realistic personality profile that represents a significant group of your website's users." Though creating consumer personas has been a common marketing practice for decades, applying the same principles to web planning has been often overlooked. Without going through the process of web persona development, we're much more prone to making guesses (at best) or assumptions (at worst) about who our prospects are. In most cases, our guessed or assumed prospects will really look more like us than anyone else. Creating web personas prevents us from mistakenly building websites for ourselves rather than those we want to serve.
We recommend creating 3-5 web personas, focusing on a qualitative assessment--akin to creating a story about your persona--rather than a quantitative one which results in a large and often unnecessarily peripheral data set. From start to finish, a qualitative approach will probably take you 2-4 weeks, whereas a quantitative approach could easily take twice that amount of time without representing a significant value gain to you in this planning process.
Creating web personas involves a four-step process of research, segmentation, creation and testing. To properly research personas, you'll want to conduct one-on-one phone interviews with a group of active and valued clients as well as prospects familiar with you or your firm. Have another person on the call with you to listen and take notes so you can focus on having a natural conversation that covers the goals, attitudes and behaviors of your interviewee. Once you've completed your interviews, you'll want to translate your interviewees into 3-5 segments. Segmenting personas is an intuitive, rather than scientific, process that generalizes your personas and qualifies them for uniqueness, realism, describability, user-base coverage, and influence upon the decisions you will make about your website during prototyping.
The persona documents you create (like the one shown above) should include basic identifiers, like a name, description, and photo of a representative user. Rather than referring to your personas by actual names from your interviewee pool, refer to them based upon their description (i.e. the "analytical influencer"). Your persona profiles should also include a longer description that focuses on what that person values and the way they make decisions as well as some personal information. Precision here is more important than accuracy. In other words, a realistic description is more important to your decision making than whether the description actually applies to the person upon whom you've based your persona. Finally, to test your personas, use and act out decision-making scenarios. A basic testing scenario might start with a search engine query for a description of your service or product (no specific names, though--we're acting as people who don't yet know about your firm) and follow the path from landing on your site's homepage to finding a low level detail page and responding to a call to action. If you construct your site to allow for this kind of procedure, you'll make better choices as to the types of content and calls to action that would be available based upon your personas.
For a more in-depth look at web persona development, download our webinar on Using Personas to Build Better Websites. You'll learn the details of how to research, segment, test and implement your web personas.
In the early days of the web, the standard way of planning website information architecture and page layouts was to create wireframes--symbol-based static illustrations of how a website will look. The problem with this approach is that wireframes attempted to communicate a complex system that responds to user feedback using paper! Everything changes once you actually start interacting with a website, which meant that most of the decisions that were thought to have been resolved during wireframing had to be revisited with the actual site.
Our solution to this, which we put in to practice ten years ago, was to build interactive wireframes. Actually, calling them wireframes at all is a misnomer; we call them Grayscreen Prototypes.
Interactive prototypes are a full representation of how the website will work, from the big picture structure represented in the various navigation systems to the granular business logic of individual pages. Every screen or function on the final site should be represented in the prototype. While an interactive prototype would not be built on an actual database, as the final site obviously would, complex functionality such as advanced search tools, data filtration, forms, galleries and the like would be represented. The prototype itself, along with the many on-page annotations added throughout the process, becomes a functional spec for our design and development teams moving forward and a comprehensive documentation of the scope of work agreed upon by the entire team.
An efficient prototyping process should take roughly one month. Our model establishes a fast-paced routine of several meetings per week with the client, first addressing the larger structural decisions and working toward approval after the resolution of issues of finer detail. This "narrowing-funnel" of decision making is an effective model to follow for the visual design phase, as well. Incidentally, we intentionally keep our prototypes unstyled so that we don't confuse decisions involving information and functionality with those that involve design. Design, which we'll explore next, is very much its own process.