In May, Forum One's Web Executive Seminar entitled "Putting Online Audiences First, Again and Again" focused on the application of user-centric techniques to capture audiences' perspective throughout the lifecycle of a redesign. One of the speakers, Kira Marchenese, gave an enlighting presentation on various approaches to usability testing.

My colleague, Andrew Cohen, has put together a great recap of her presentation entitled "Five and a Half Approaches to User Testing." It's definitely worth a read. Be sure to watch Kira's presentation for more details.

Here is a short, sweet, and to the point post from Ryan at Signal vs. Noise on thinking about the architecture of your site in terms of paths instead of hierarchies. What he's saying makes sense. Often, it's easy to get caught up in the overall structure of the site: Where do the publications live? Should the blog be part of news? Should contacts be in the about section, or on its own?

A way to enhance the architecture of the site is to think in terms of paths, Ryan says. How are your users going to get from point A to point B? It's more than where the publications live. How are your users finding the publications? Where are they starting - the home page, an internal page found via search? It's beneficial to understand all the potential paths a user might take to get to your content. Prioritizing these paths will help you think about the most important content. So, when you're in the analysis phase, don't throw out those scenarios. They'll come in handy when you want to develop some paths.

One thing to note is that we shouldn't abandon hierarchies, obviously. It'd be a hard sell to convince the client or site owner that you'll only investigate paths and not hierarchy. A reader of the post made the following comment, "I would have to say though that convincing a site owner to only go down the ‘path’ route would simply give them the impression we were looking for shortcuts. So i think combining both elements of site planning/organisation is advisable."

For years, businesses have been using a number of techniques in their stores and online to influence their customers and encourage them to respond to their products and services. I’m sure most of you are familiar with the grocery store example. The bread, milk, and eggs are in the back of the store to force the customer to walk past the Little Debbie cakes on their way to pick up the necessities. That's persuasive design or marketing.

In the field of web design for non-profit organizations, purchasing a tangible object isn't always the goal. However, there are a number of cases where action is required. Examples include: donating to support a cause, subscribing to an organization’s RSS feed, or spreading the word about a specific initiative. How are users persuaded to take action? Placing Donate or Join Now buttons on your site isn't enough. This is where persuasive architecture comes into play.

Persuasive architecture goes a step beyond trying to produce a usable and intuitive information architecture. Information architecture is about effectively structuring a site in order to help users find the information they seek. This is accomplished through a number of strategies: categorization, labeling, designing page layouts, grouping, etc. Good information architecture will make it easy for the users to find what they’re looking for, but the experience shouldn’t stop there. Persuasive architecture will deliver a useful and intuitive interface, while putting an emphasis on informing, enticing, and persuading users into action.

Persuasive architecture in the non-profit arena is not dissimilar from persuasive architecture in the for-profit arena. While you might not be selling your users handbags or new shoes, what you could be selling is an idea. You want people to support your cause. You want people to join your organization so you can create a larger network of people who are collaborating with you. To successfully accomplish this on your site, you must persuade your users. You must persuade them to click again, to discover more, and ultimately to engage.

Enough talk. Let’s look at an example. A site that sports a nice persuasive architecture is the Nothing But Nets campaign.

Nothing But Nets is a grassroots campaign to save lives by preventing malaria, a leading killer of children in Africa. If you peruse through the Nothing But Nets site, you’ll notice that they’ve done a good job of communicating their cause in addition to encouraging action. They’ve done this through persuasive navigation, persuasive content, and persuasive design. What I like the most about this site is that the navigation forms a concise, active, and persuasive statement. They broke out of the "Who We Are ... What We Do" mold with a very compelling site structure: Malaria kills, Nets Save Lives, and It's Easy to Help.

Persuasive Navigation

Malaria Kills

Within this section, information is provided for those who may not even realize that Malaria is killing millions of people. The site provides compelling content that informs the user of Malaria and encourages them to understand that this is an issue that needs support.

Nets Save Lives

Providing the background information is the first step. But now, users might be thinking "This seems out of control. What can be done about this?" The site answers that question with the Nets Save Lives section. The section provides statistics on how bed nets save lives, and provides an overview of the process of getting the nets to Africa.

It's Easy to Help

At this point, you are hoping that the user is convinced. They understand what Malaria is and they realize the importance of supporting the efforts to put a stop to the deaths resulting from it. They also realize that buying bed nets is an easy way to stop Malaria infections. The next logical step is encouraging the user to support your cause by donating. The content supports this - everything from the title of the section to the number of ways to support.

Persuasive Content

Net-O-Meter

Users like to know that other people are invested and have taken action. The Net-o-Meter is a perfect way to say, “Look! Other people are helping too!”

Interactive Net Distribution Map

Users also like to see the results of contributions. This map is a great way to visually see the results of current donations. It will also keep people coming back to the site to check the progress of the campaign.

Compelling Video

I don't think that I have to be the one to tell you that online video is a great way to spruce up your persuasive content. The videos on the site really help bring the issues to the surface. Not only do they make the issues seem more real than they would by simply reading text, they engage the user with a more emotional approach.

It might not make sense for you to structure your site in the way Nothing But Nets did, but when you want your users to do something, take the time to think about how you are encouraging them to act. Think carefully about your content. Is it supporting and encouraging your users? If you want them to donate, are you explaining to them why donating is a good idea? Are you giving them enough information to encourage them to act? The technology to make the site and transactions usable isn't always enough. Just because they can find the information, doesn't mean they will act when you want them to. The architecture, design, and supporting content needs to help your users make the choices you want them to make.

Additional Information

I had the privilege to hear Shannon Raybold, campaign director for Nothing But Nets, talk about the process behind building the site I've talked about in this blog post. You can watch and listen to her presentation from Forum One's Web Executive Seminar on Global Health.

As information architects, we sometimes take wireframes for granted. We work with them every day. We live and breathe boxes and lorem ipsum placeholder text. What we don't often realize is that many people that we work with don't really grasp the concept of wireframing as it relates to web design. Often times, clients would just like to see a page mocked up in Photoshop and sink their teeth into a full-fledged design.

Wireframes are an integral part of the IA process because they reinforce the layout and structure of pages that will be designed. Wireframes are typically an end result of the requirements gathering phase of a site project that fall between analysis and design.

Wireframes show persistent elements of page layouts (e.g. headers, footers, and navigation elements) as well as dynamic elements such as relevant content, tools and services that are specific to each page. Wireframes are typically created using Visio on the Windows platfrom and Omnigraffle on the Mac platform. They consist of a number of different shapes, lines, and links, and text that show you how a page will be organized.

Most wireframes outline the following:

• global navigation
• local or secondary navigation
• content specific to the page being wireframed
• titles, sub-titles, etc
• image placeholders
• footer
• search function

Here is an example of a wireframe from a project with which I'm involved:

You'll notice that there are no design elements applied to this page layout. Wireframes are a useful part of the web development process because they allow you to focus on content and content priorities before the design and development phase starts. Making revisions to wireframes is much less costly than making revisions after the design and development phases have started.

It's generally not necessary to wireframe every page. Aside from the home page, we typically wireframe the most important and/or top-level pages involved in developing the site. Wireframes should not dictate visual design. They should focus simply on the layout of information.

Aside from wireframing for the purposes of determining layout priorities, wireframes are also a vital part of the development process. We use wireframes to communicate functionality requirements to a developer. Adding notations to certain sections of wireframes help the developer understand what he or she might need to do during development in order to produce the desired look on the front end. Notations for functionality include things like:

• how many items should be displayed in a dynamically generated list
• what areas of a page should or should not show, depending on where the user is on a site
• what action should be performed upon click or form submission
• how dynamically generated content should appear
• displaying content based on certain filtering or search criteria

When it's all said and done, wireframes will be your friend. They'll save you time and money by allowing you to think about how the site will be structured before diving into design and development.

The problem we’ve been having with the fold is that clients seem to see referencing of the fold as us saying “Cram every possible piece of content above this line or your users won’t see it.” This has become problematic during the wireframing and design process because we end up spending an inordinate amount of time trying to figure out ways to arrange and rearrange content in order to fit it in a space only 600 pixels high. Frustrating? You bet!

At the same time, we still want to express the fact that the most important content should come first, and this is usually always what the client wants as well. How, then, do we strike a balance between effectively laying out the page without being constrained by that line that we often can't cross?

Here’s what we know:

Users scroll. They’ve been scrolling for a while now. Google search results, product listings on eBay, blogs, news sites, photo galleries – we all scroll through them. Clicktale did an interesting study on user scrolling that has recently been brought to light again by the Boxes and Arrows article.

Screen resolutions are growing. A quick glance at some recent statistics, both globally and for sites that we maintain, shows that about 50% of the population is viewing the web on a resolution of 1024x768. Another 25% (give or take) is viewing the web at resolutions of either 1280x1024 or 1280x800 (Hi laptops!). There is still a good chunk that we can’t forget, though, looking at us on 800x600 resolutions (roughly 15%). The rest of the percentage of resolutions are scattered amongst non-traditional and undetermined resolutions.

I’ll admit, as an information architect I’m having trouble reaching that happy medium between communicating to our clients the pros and cons of both sides. If statistics are showing that screens are getting bigger and people are more willing to scroll, then why do we even need to worry about the fold? On the other hand, clients want their message to be heard with as little effort as possible. I understand the argument that the page should be designed in a way that the content suggests there is more beneath it (e.g., having the fold fall in the middle of pictures and other so they appear to be cut off), but I'm not convinced that's enough. For wireframing and design purposes, we’ve decided to more subtly indicate the estimated area of the fold line and stress to the client that there are many variables that play into this.

I’m very interested to hear other people’s comments on this subject. Do we forget about the fold altogether? Or, do we just communicate the implications more subtly and strategically? Let me know what you think!

I spent the past two weeks on a service trip with Habitat for Humanity in Thailand where I, along with 9 other people, built a house for a family in need. I was quite impressed with the building method that many Habitat affiliates in southeast Asia have adopted. This method uses an interlocking brick that is pressed from materials found naturally, in most cases. I was reminded of Nam-ho's fascination with Lego blocks during the time I spent building there because these bricks are essentially the same idea.

You'll notice the two protuding circles on top. These fit neatly into two recessed circles on the bottom of the brick. This allows for a clean, level method of stacking the bricks without a great deal of need for leveling and repositioning. These bricks also create a much quicker method of building because there is no need to mortar every row, as I'm used to in my past experiences with brick building. Usable bricks! The holes in the bricks allow you to pour cement in a much larger stack (8-10 rows). Then, rebar is typically added to the corners for extra structural support. Additionally, like most other bricks, the surface on the exterior is already "finished" and doesn't require painting. This saves the homeowner a great deal of money.

The bricks have been a life-saver (literally) to many people in this region of the world. Not only have they helped Habitat build and rebuild houses more quickly and efficiently, but they've been able to employ out of work farmers, fishermen, and other laborers who have been out of work due to the recent natural disasters. By employing these folks at the brick making centers, they are able to start retaining some income and, in turn, are producing more bricks for Habitat to use in the home building process.

So, I strayed a bit from the usual topics that are posted here, but I felt compelled to share my experiences with usable design in an arena other than the web.

My last two posts have centered around prototyping methods. Since I talked a bit about techniques, I thought it would be helpful to show an example in practice that we have used for a project I'm currently working on.

A client requested a redesign and reorganization of their existing site. We went through the usual steps up front to pick their brain - content analysis, audience definition, creative discovery sessions, etc. Before we sat down with our trusty friend Visio, we thought it would be beneficial (and fun) to lay out the site with our trusty friends Pen, Paper, and Scissors.

Based on our initial gathering of content ideas and audience definitions, Nam-ho and I organized the initial homepage design using an over-sized piece of paper and smaller pieces of paper that would represent the sections on the homepage (header, global nav, sub nav, blog, featured items, etc). This allowed us to quickly arrange the sections and throw out what we didn't think was a good fit. No coding time wasted!

Here is an example of the paper prototype we designed:

We actually sent this image to our client. Use your own discretion if you consider doing this - depending on your relationship with the client and your understanding of how they will react to a paper prototype. We were comfortable with providing our client this kind of feedback and thought it would be a good way to help them understand the process we went through.

After some initial back and forth regarding positioning and layout issues, we moved into the digital wire framing process. All in all, it has been a very smooth process. The decision to go with a low-tech paper prototype model up front turned out to be a good one. One of the biggest advantages I noticed throughout the process was that it encourages experimentation. Using pen & paper as opposed to a software application gives you a great advantage of increased flexibility when laying out a page.

If nothing else, it gave us an excuse to get away from our computers and play with scissors!

I would be interested to hear if any of you have had similar experiences using this method of prototyping.

A reader of my last post, Prototyping for the Masses, brought to my attention an online tool used to create simulations of web applications called Simunication. I thought it would be good to add these kinds of tools to my list of prototyping resources. Upon further Google supported research, I found that one of the authors over at Boxes and Arrows has already put together a nice summary of some of the other simulation tools for prototyping resources: Visio Replacement? You Be the Judge.

I didn't get a chance to look at every one of the tools listed, but upon inspection of a few of their demos, it seems as though many of these tools are a good fit for building out prototypes of larger data-driven web sites and web applications. A nice feature of many of these tools is that there is built-in use case and scenario support that allows you to build out your processes based on use cases that have been outlined by you and/or your clients. This allows proves to be helpful in demonstrating your prototype to the client, because the use cases are readily available and can be reviewed simultaneously with the functions of your simulation.

Some of the discussion around this article seems to center around finding a nice mid-level tool that is similar to these simulation tools but is designed more for static, content-driven site mockups - something in between a wireframe and a more high-fidelity simulation, but requires less HTML programming to end up with clickable prototype.

I'd be happy to hear from any of you who have had a good experience with these kinds of prototyping applications.

In a previous post, I talked about the notion of "looking before you leap" as it relates to designing a website. Part of this "looking," or exploration stage, can be enhanced by prototyping. Prototyping can take shape in a number of ways, depending on a number of things related to the project in which you're currently involved. A quick survey of some of my colleagues here at Forum One revealed that the preferred method of prototyping really depends on the scope of the project, the phase of the project in which you're currently immersed, and, of course, the size of your budget. However, the most favored method was paper prototyping.

Paper prototyping usually takes place during the initial stages of design exploration and is then translated into something more functional, like a HTML mock-up, allowing more interaction with the site you're conceptualizing.

In my efforts to consolidate some of the knowledge on various prototyping procedures and techniques, here is an overview of some of the best web references on prototyping I've found.

Paper

Paper Prototyping - This a great overview of the process and benefits of paper prototyping, brought to you by A List Apart.

In Defense of Paper Prototyping - The author of this article argues that, in many cases, going beyond paper prototyping during the initial stages of a project can be "overkill." Once the basic design elements are agreed upon and in place, moving to more detailed and functional prototype makes sense, but a pen and paper never fails to get you started.

PaperPrototyping.com - A companion site to the book Paper Prototyping, by Carolyn Snyder. This site contains many great paper prototyping resources and references.

Presenation Tools

Prototyping with PowerPoint - This article presents a great way to create a functional prototype model using a nice little presentation tool of which you may have heard.

Diagramming Tools

Make Your OmniGraffle Mock-Ups Functional - A handy little screencast on turning your OmniGraffle wireframes/mock-ups into clickable prototypes.

Prototyping Using Visio - This article from the Society for Technical Communication provides a great tutorial on how to create functional prototype designs in Visio.

HTML

HTML Wireframes and Prototypes - From Boxes and Arrows, "Using HTML as the basis for your wireframing and prototyping can be a quick and rewarding experience with fabulous benefits, including easier user testing, improved client communication, and faster, more effective use of design time."

Dreamweaver Primer - This is a great companion piece to the above resource. The author lays out the process of prototyping with Dreamweaver quite nicely. Although the article was written during the days of Dreamweaver past, the concepts still hold true.

As I stated, the technique you choose depends greatly on the phase of the project. I wouldn't suggest bringing pen and paper sketches to a client meeting if the client wants to see functionality. It's up to you to decide which technique is best for your project. That being said, this is by no means an all-inclusive resource on prototyping. I suggesting checking in with some of the other experts in user experience design, like Boxes and Arrows and Adaptive Path to see what they have to say.

Prototyping is all about exploring ideas before you invest in them. Use the opportunity to refine and revise, get buy-in, and explore the features of your site before you think about build-out.

We've all fallen victim to leaping before looking -- speaking before thinking, taking a road trip without consulting a map, not calling ahead for reservations, or not devoting enough time to planning for a web development project. As information architects, it's our job to make sure that all the details of the project process are considered before a line of code is written.

In a recent article at A List Apart entitled Avoid Edge Cases by Designing Up Front, Ben Henick serves us a great outline of what to consider during the planning and assessment process of a web development project. For many web projects, design is considered too soon. Henick makes a strong case for adding the following steps to the process - assessment, personas and scenarios, wireframes, and style guides. These are all things that are considered as part of the user experience and design process in order to ensure an optimal experience for the audience of the site.

By adding these steps to the design process, the project can benefit from things like a well-defined scope, early identification of user experience issues (through scenarios, user testing, etc), and a well-established context and purpose.

Consider Henick's advice in his article the next time you embark on a web design project. Remember, look before you leap.