Newfangled works with independent agencies to create lead development web platforms for their clients.

Newfangled works with independent agencies to create lead development web platforms for their clients.


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.

Web Personas

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.


Website Prototyping

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.


Adekunle | March 22, 2013 12:59 PM
Wonderful article.! Looks like mood boards breaks down the process into small bites for any design project. Thanks!
Joel Milne | January 28, 2012 7:03 PM
Interesting idea, I like the concept of a more specific way of profiling users instead of just borrowing the traditional marketing plan approach to forming target profiles.
Jann Mirchandani | December 20, 2010 4:39 PM

Great article. I love seeing the process from a large shop; gives some perspective to what we're doing here; ways to improve and validating what we're getting right. Thanks!
Jessie Nunez | March 27, 2010 2:28 AM
Wow! I skimmed over many of your articles and plan to read them in depth. Great writing and content. By the time I'm done, I'll have a UI degree (of sorts).

I primarily focus on visual design for smaller businesses. These businesses generally don't have large budgets. However, I believe that best practices should be the rule and I ask lots of questions to help my clients think beyond "We need a cool web site with such and such bells and whistles".

I would appreciate any advice on how to implement and maintain good UI principles when the budget is under 10K (way under 10K).

Great work and much continued success to your firm.
Chris Butler | February 5, 2010 2:40 PM
Chuck, That's a good article you linked to- thanks. Our process always includes mood boards. We don't break out the price and allow clients to choose a path. The only time we wouldn't do mood boards is if we decided to not include them in the process for some reason- perhaps to keep the scope narrow and work within a lower budget. But in that case, we would have very specific contractual language to keep the scope of the design phase as limited as necessary.
Chuck | February 4, 2010 5:43 PM
I read something good in another article about website mood boards from WebDesignerDepot - "Words fail miserably when trying to translate design concepts... Visuals communicate things words cannot." It's true. Why try to pitch a visual concept in a written form to get your client to buy into the design you haven't created yet? So mood boards are great at getting to the point faster. But I like how you emphasize that the strategy happens with mood boards and the production happens with the layout iterations after. Most desigers try to do both in layouts and end up redoing their work over and over again. In the WebDesignerDepot article they talk about when clients don't want to pay for mood boards. How do you handle that? Do you breakout the costs and let them choose?
Dave Mello | February 4, 2010 9:30 AM
Robert: Thanks for the feedback! In rebuilding the new site, we drastically reduced our use of images *and* tables. The result is a must faster load and rendering time. In the case of the main navigation though, I chose to stick with a simple table/image structure for a couple of reasons.

Since the menu system is dynamic, I wanted to utilize a little bit more control of how the columns appeared if the ordering or placement changed at all, particularly in older browsers. As for using graphics, since the menu actually serves as one of the main visual elements, I wanted it to be as consistent and attractive as possible, particularly in cases where no browser/os induced anti-aliasing was taking place. You are correct in that the same structure could have been built using only CSS, but I made the call to take the minor trade-off in performance to ensure consistent design. We are also using ALT tags in the image itself to avoid any SEO issues.
Chris Butler | February 3, 2010 9:27 AM
Robert: We went live with our redesign on January 12. You can read all about the process in a blog post I published that morning called How We Redesigned As for your question about why the navigation is programmed the way it is, I'm going to let the developer who built it, Dave Mello, answer. From my point of view, the new site is significantly faster than the old one, which makes me happy!

Jason: You raise a good point. I neglected to mention developer code reviews in the QA part of the article. I can only fit so much in, but it is definitely a critical piece of the QA process. Right now, our developers have a code review prior to the site going live with our Lead Software Engineer, who evaluates their work from the perspectives you listed out. We were actually discussing this just the other day, and are going to move to a new model of having developer code reviews every two weeks- on a schedule independent of specific projects- to make it more of a developer department culture thing, rather than just a step in the project process.
Jason | February 2, 2010 7:11 PM
I see the value of having the project managers create and implement test plans. Being the most familiar with the spec makes them the most qualified to assess whether the project measures up. But what about the code itself? Who does a QA review of the code for security issues, leanness, web standards, etc.? I'm not a big shop like you all, so the biggest problem I've had has been with working with freelancers in the past and not having a way to ensure code quality, so even if a site looks great when it's first launched, it degrades fast. I've learned a ton as a result about how little I really know about code ;-) So now I depend upon other programmers to check the work in addition my own review.
Robert | February 2, 2010 5:27 PM
Nice post, and when did you guys do the redesign? Looks great! Just curious though on the choice for navigation, use of images and a table? Seems odd, surely that could have been achieved with plain text and css. Just curious if there was a good reason for it.
Chris Butler | February 2, 2010 3:09 PM
Joanne: Definitely. In fact, I was speaking with one of our project managers just this morning about planning for persona development for a client that has been using their site actively for almost two years now. Specifically, this client does a lot of television advertising but has not yet focused their website on a particular segment. As a result, they don't really have any content strategy at all and are assuming that the same people that respond to a television ad are their web audience too. Our hunch is that assumptions is incorrect. The value of identifying personas is there, really no matter when you do it. It's always going to provide some insight that wasn't available beforehand.

Jeri: That's a good point, which is why the persona stuff is so critical. If you don't identify who you are speaking to with a site, you won't have any significant or accurate model for content. I'll be covering content strategy in the second part, not because it's secondary, but just because I wanted to deal with the fundamental/mechanical stuff first.
Jeri A Hastava | February 2, 2010 3:02 PM
Great post, and I would love to see the same post with the addition of content strategy - gathering, analyzing, and planning for content today and into the future - at the very beginning during the planning phase. Planning, designing and developing in the absence or "real" content can result in content that simply doesn't "fit" the site, or fails to convey the message - not to mention frustrated customers. :-)
Joanne Cirillo | February 2, 2010 2:08 PM
I watched your webinar on Personas and found it very instructive. Is there an application for this process if you're already way down the road on your web site development?
Chris Butler | February 2, 2010 12:59 PM
Justin, Shhh! Don't let that secret get out. Otherwise, what would I write about every month? ;-)
Justin | February 2, 2010 11:04 AM
Chris, Great post! Nice to see our process so well articulated. Perhaps this will help dispel the myth that we have an extra button on our keyboards that simply says, "Make Website."

↑ top