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

In light of some recent project work, and an article from the folks over at Boxes and Arrows, the subject of the fold (as it relates to web design) has become a hot topic here at Forum One. The fold, which is sometimes referred to as the scroll-line, is the point at which a user must scroll to see more content on a web page. The term comes from newspaper design and the notion that the big stories are at the top of the front page, above the fold in the newspaper.

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!