Building Better Blueprints Pt. 1

Creating a website can be likened to making a custom car or house, but with a few quirks. A website is not only supposed to be an efficiency-enhancing tool for the person or organization that paid for it, but also a reflection of the organization's persona and agenda. Creating a visual and interactable representation of these concepts takes a significant amount of creativity and testing. The job of any web shop should be to work extensively with clients to pull out exactly what the group's goals and needs are for the web and to translate them for the internet.

When we begin the web development process, the first thing that needs to be established is the information architecture, which is basically the translation of an organization's goals and needs into elements and content types. These will form a structured site map that will later inform the wireframing process.

We start our information architecture phase by asking the clients what their short and long-term objectives are for the website, why people will come to the site, and the organization's mission statement. We collect these answers and rework them into short statements that we call goals. After that process, we ask the client to arrange these goals in order of importance.

After we have a goals list we need to create an audience list, so we follow up by asking for a summary of the organization's intended audiences and tasks that they might carry out on the website. We'll add a few potential audiences of our own (e.g. friends and family members) and some additional tasks (e.g. look through pictures of events) and then ask our clients to rank the two separate lists in order of importance. Obviously the task list is dependent on the audience list, but it's helpful to separate these concepts up into different variables which we will put together to create fleshed out user stories.

Let's turn the prioritized list of site audiences into living, breathing, quirky people with goals and objectives and forecast how they might carry out their tasks on the website. This user story exercise helps put us into the mindset of the typical site visitor, their purpose for being there, and the primary task(s) they will be carrying out while spending limited time on the site. Some projects may only have a few user stories while others (e.g. eCommerce sites) may require many more. It's up to the information architect to put together these user stories from the prioritized audience and task lists, present them to the client for feedback, and make necessary alterations.

A user story might look something like this:

A mother is a buyer of real food for her and her family and hears about "Food Freedom Organization" through the news and comes to the site to learn more about attending the next "Food Freedom Organization" event.

• Find a link to a recent event listed on the front page, or through the primary navigation
• Subscribes to the latest updates and alerts from "Food Freedom Organization".

Notice that the site visitor has various pathways to accomplishing their goal. These notes will be helpful later on during the wireframing process where we will compare these pathways with the content inventory (coming up!) to see at what points they will merge together.

We now take the organization's needs and the user stories list and begin sorting out what kinds of content and functionality will be needed. What helps here is to do some scouting of competitor sites to see what unique or ubiquitous design and programmatic ideas we can borrow. Once we have this (big) list we should organize our content inventory by content and any functionality requirements. One simple way to help differentiate the two would be to think of functional requirements as generally anything that an end user needs to use his keyboard for: filling out a form, typing in credit card information, etc. Some items in the content inventory will be nebulous in terms of their sortability, and if that's the case it would be best to include them into functionality requirements, which we will again have our clients rank in terms of importance. The ranking of this functionality will help us determine what's most important to the client and what's possible given the budget. Some pieces of functionality may even need to be consolidated.

Side note: it's important for clients to remember that wanting a particular piece of functionality is different than having their goals and needs fulfilled. For example, we may like the idea of modal pop-ups that ask site visitors for their name and email address, but is this really the most effective way to collect information given the general audience?

Before we go on organizing the site's content into a meaningful site map, let's cheat a little bit and figure out what this website will feel like to the end user. Is this a music company, and should the site have aspects of a boom box or should it be laid out like a pamphlet? Is this brochure-ware and does the client want this to come across as a dynamic business card? Does Batman need a site to show off the number of criminals he's taken down and does it look like Arkham Asylum? While these sorts of questions relate quite a bit to wireframing, the metaphors we gather will help us visualize how we might arrange the content.

Let's take a good look at that content list again and start grouping the elements together. First ask the client or contact to have individuals affiliated with their organization to do the work for you. Really, it's for the best to have non web geeks do this process! They are the ones most likely to use the site, after all! Consolidate all the feedback and start looking at these nameless groups as major candidates for the primary navigation.

Next, come up with names for the primary navigation and have the same group of people who grouped the elements together to take those same elements and to associate them with the names you came up with. The group that includes the staff listings, board of directors, mission statements, etc. will most likely be called "about", but not necessarily so. You'll be surprised how different the groupings look now! Reevaluate your groups and the connotations that the primary navigation names give, and repeat this exercise until you obtain some consistency with the results.

Now that you have the primary navigation sorted out, you will need to think about how the site visitor will go about traversing through the website. Keep in mind local navigation (e.g. menu systems) and how the pieces of content relate to one another. This will be applied to a site map that you produce as a deliverable for the information architecture phase.

Wow!!! That was a lot of (important) text. Did you catch all of that? If not, here's an imperfect summary:

1. Find client goals and needs and rank them
2. Discover who the site audience is and what they'll do
3. Create and rank user stories
4. Eat a sandwich
5. Make a list of content and functionality and rank them
6. Reevaluate content and functionality list
7. Create a site metaphor
8. Group and organize the content
9. Do it again.
10. Create names for the primary navigation
11. Admit your ideas weren't perfect and try again.
12. Create a sitemap.

Alright, now that we're done with the information architecture phase, we'll be moving on to the wireframing process, which will be covered in the next installment of my Building Better Blueprints series. Stay tuned.

UPDATE: PART 2 COVERING WIREFRAMING IS NOW AVAILABLE HERE