Articles on Information Architecture

Fireworks just got better

Or at least my understanding of it did. I found some time this weekend to go through some old bookmarks I’ve been meaning to get back to. One was this video demo by Adobe’s Paul Dorian on using Fireworks not only to create website visual designs, but also to create wireframes. I’ve never used Fireworks for creating wireframes – and almost always use Visio. My process is a bit outdated at this point as I work almost exclusively in Photoshop for Web design. I then take the cut up (I don’t slice… I cut) images directly to Dreamweaver. Works for me. Keeping it “old school” I guess.

Unfortunately I don’t get much time to experiment with new design and IA approaches anymore. Not much time between meetings, status reports, analyzing budgets, client calls, etc. However, this video has peeked my interest in exploring Fireworks for creating wireframes. I’m inspired to revisit my approach on the next site design I get my hands on.

Video tutorial on using Adobe Fireworks for wireframes

Here’s my initial impressions on using Fireworks for website wireframes.

  • Master pages are a big step in the right direction. When I create wireframes in Visio I’ll generally use a series of cascading background files to display common page elements across the wireframes. I’m not sure that Fireworks’ master pages will be quite as robust – but they may.
  • Using the document library will replicate the way I use stencils in Visio. One of my favorite things about Visio is that I have a custom stencil library with common sitemap and wireframe elements that I use on every project.
  • Element scaling is really cool. I often run into issues working in Visio when one of my stencil elements distorts when the size is increased.
  • Paul shows how the wireframes can be easily exported to PDF. This is important to me because I always deliver wireframes to clients as PDFs.  Having a format that everyone can view and print uniformly is a big advantage.
  • The ability to add links on the wireframes that export to PDF is cool, but potentially problematic. “If one link is clickable, why aren’t they all?” “How do I know which links work without hovering over them all?” I can see the client confusion already.  But in reality these links within the PDF are a bonus but certainly not a necessity.
  • What’s lacking for me is a clear method to create notes and page details information. For examples here’s how I structure a wireframe page (pdf). I assume it’s possible to just create another section within the Fireworks page outside of the actual web page.
  • I also wish there was an easy way to tie the wireframes to a site map diagram.

Looking forward to testing out the process in Fireworks and reporting back. Is anyone else using this application for wireframes? What other software solutions are you using?

Originally published February 2007

Web Site Wireframe

(aka Wire Frame, Page Architecture, Low Fidelity Mock-Up, Page Schematic)

What are wireframes?

Web site wireframes are blue prints that define a Web page’s content and functionality. They do not convey design – e.g. colors, graphics, or fonts.

How are wireframes used ?

Wireframes – combined with Site Maps -are the bread and butter tools of information architects. Web site wireframes are useful for conveying the general page structure and content requirements for individual Web pages. Typically wireframes are developed by an information architect, requirements analyst, or designer. In many Web groups these are all the same person.

Using detailed wireframes will frequently flush out new requirements and questions that nobody has thought about yet. They also help to keep a paper trail of functional and design decisions that are made. I sometimes use wireframes to get people thinking and generate requirements. Getting signoff on a set of detailed wireframes can save a lot of time and money. Forcing managers and clients to actually think about the site’s functionality at a page level will avoid changes later on. Otherwise programmers can end up making endless changes and tweaks to their code.

Wireframes can end up evolving into the default requirements document for a system. I sometimes end up adding a sitemap to the beginning of the wireframe document. I then add notations and requirements on specific pages. Sample Wireframe 2 below is an example of this.


How are wireframes created?

Wireframes – like most information architecture diagrams – can be created using a variety of software programs. I generally use Visio because of its powerful stencil feature. Visio stencils allow you to save libraries of commonly used shapes and elements. I have custom stencils created that allow me to easily drag and drop wireframe elements onto the screen. This really speeds up the process of creating wireframes.

I have also seen wireframes created using Excel, Word, and Power Point. So the choice is yours.

Wireframes need to achieve a balance between being too detailed and too general. A wireframe that is too precise may leave little creative room for the designer. A wireframe that is too loosely defined can be misinterpreted by designers and developers. The wireframe format used should be dependent upon the audience.

HTML Wireframes

Information Architects and designers sometimes end up creating the initial HTML layouts that are then turned over to a developer for “real” programming. This often makes sense, because in some cases it’s the IA or designer with the best command of HTML layout and design. HTML may be used to create basic wireframe templates that can be used for usability testing or to get client feedback. In other cases the HTML is created in order to keep tight control on the design, rather than leaving it up to the programmer.

Wireframe Examples

Sample Wireframes (pdf)

Sample Wireframes 2 (pdf)

Sample Wireframes 3 (pdf)

Originally published February 2007

(aka Site Map, Site Hierarchy Map, Site Diagram, Blueprint, Web Map)

Sitemaps – along with Wireframes – are my bread and butter of information architecture diagrams. When setting out to analyze and document an existing Web site one of my first steps is to sketch out a rouhg site map. The sitemap will show the major sections of a Web site, but not necessarily every page. For large sites it’s not always necessary or feasible to include all pages in a site map.

Similarly, when I’m creating an information architecture for a new site, one of my first tasks is laying out a rough site map. This helps to chunk and group content and functionality.

Web sitemaps and Wireframes

Combining a detailed site map and illustrative wireframes creates a valuable document that can guide programming and future requirements. In some cases such a document has become the default requirments document for systems my group is building.

How to Create Web Sitemaps

There is no standard best practice for creating sitemaps. I happen to prefer to use Visio – as do many others. Visio allows you to easily lay out page hierarchys and create connections between them. But wireframes could also be created in Word, Power Point, Excel, by hand, or any other method you find helpful.

Web Sitemap Examples

Site maps can be constructed in a wide variety of formats, but the general structure and principles remain relatively consistent.

  • Sample Web Sitemap (pdf)
    This site hierarchy map was used for a project in which we had to combine 6 separate Web sites into a single, cohesively – yet distinct, branded Web prescence. One of the first steps was to analyze the existing sites and document the main content sections using sitemaps. The sitemaps were used to identify duplicate content and functionality that was no longer relevant.
  • Web Sitemap Diagram 2 (pdf)
    This is a sitemap that was created for an update to a small marketing site. A key is used to distinguish revised and new content.

Originally published February 2006

In part one of Web Information Architecture Deliverables and Diagrams I discussed the various deliverables and diagrams that are commonly used throughout the industry. In part two we take a look at the factors that influence the use of these deliverables and various implementation examples.

Understanding how to create information architecture deliverables is the easy part. Sure, creating documentation for large scale sites with complex functionality can be very challenging and tedious. But it takes additional expertise and a lot of trial and error to develop an understanding of how to best apply these deliverables. There is no magic formula to decide which deliverable or combination of deliverables to use. It takes a lot of experience to know when and how to best utilize the various deliverables available. This document takes a look at some key variables that should influence our decisions.

Access to programmers

Ideally designers, information architects, and programmers would work together closely as a Web site is built and refined. However, this isn’t always possible. I have been involved in projects where I was responsible for the requirements analysis, information architecture (IA), and design. But the actual coding was turned over to a set of programmers in another division or organization. Or perhaps conflicting requirements on other projects prevent you from maintaining regular contact with the programmers. In cases such as these it is important to create detailed documentation to guide the development. There may or may not be an open line of communication between the people that created the deliverables and the developers who are now responsible for developing from it. In the world of Government contracting this transition isn’t uncommon among separate contractors. Basically you can’t assume that the programmers will interpret your deliverables the way you envisioned, and you can’t assume they will be able to get clarification form you in the future. You need to explicitly describe how the system is designed to be implemented.

Programmers with design skills

Obviously the individual skill sets of programmers vary greatly. Some are former engineers or scientists with little or no design skills or artistic eye. Others may have once been designers, graphic artists, or just have been blessed with natural artistic ability. Some programmers may have a good understanding of Web usability, others may not. Senior developers may have enough experience to adhere to general design and usability guidelines that junior developers may not recognize. It’s important for you to recognize these characteristics. You need to understand the skills of the programmers you work with and customize deliverables accordingly.

It seems most Web programmers fall into one of two categories. The first group is part developer and part designer. The other sees things in black and white and will program exactly what is given to them. Once you are familiar with the design skills of the developer(s) you can cater your deliverables to match their needs. In some cases basic wireframes or flow diagrams may be enough for a programmer. It doesn’t take much time working with a programmer to ascertain whether they are capable of taking a rough design or wireframe and creating an effective interface from it. Some developers will program to precisely meet the requirements, but are incapable of injecting their own design elements. The key is to communicate the relationship and roles. If a developer has general design skills, then it may make sense to give them some freedom.

HTML skills

In some cases it may be the designer, and not the programmer, who is best suited to create the initial HTML for a site. It’s important to recognize that a designer’s or IA’s involvement doesn’t necessarily have to end with a site map or Photoshop mockup. Often it makes sense for the designer to be responsible for creating the HTML templates. Again, it comes down to recognizing and capitalizing on the skill sets of your team. In an ideal situation, and when I have enough time, I prefer to turn functional HTML over to a developer and let them do the “real” programming.

Targeted audience

It’s always important to understand who the audience, both the primary and secondary, for the deliverable you are creating is. You may be putting together a story board with detailed wireframes for the programmers, but the document may inevitably end up in the hands of management. Thinking about the documents possible future uses can help. Adding additional documentation about the purpose and/or intended audience for the document can help add context. On a project with frequently changing requirements a good approach would be detailed wireframes with enough documentation for programmers, clients, project mangers or anyone else involved.

Turnaround time

How quickly are these deliverables needed? In some cases there may only be time to sketch out rough designs on paper (paper prototypes) and put together general work flow diagrams. In other cases there may be time to put together detailed wireframes, and in other instances time to create HTML designs for the programmers to use.

Staff workloads

There is usually a tradeoff between the workload of the designer/IA and the programmer. High fidelity designs and documentation require less overall effort for programmers than if they were given basic requirements and design specifications. If the programmer is given HTML they won’t need to spend time on layout and design. So whose time is more valuable? Who currently has the most on their plate? On a tight budget, who has the higher hourly rate? These types of questions should ultimately determine where the handoff lies.

Budget

Perhaps your group or company has been tasked with creating the design and/or information architecture for a Website. The actual development, testing, and implementation will be handled by another group. The fixed budget for your portion of the work has been set. Depending on the budget you will either have to deliver low-fidelity (wireframes, process-flow, etc.) or high fidelity (detailed story-boards, HTML) deliverables. Obviously the latter requires a greater level of effort and expense.

Project/System Use

What type if system is being developed or who is it being designed for? If it’s a non-critical internal system designed to be used by staff, then it may be ok for the programmer to work with basic requirements. Obviously you never want to implement a system that sacrifices usability or accessibility, but it may be ok to deploy these types of systems with a less polished design. Websites that are higher profile (e.g. Corporate Websites, Large-scale systems) should be given additional attention. It’s important to keep tight control of the design and information architecture. Programmers should be working from detailed requirements so they don’t have to make design decisions on their own.

Familiarity with developers

If you regularly work with the same group of programmers over time you will learn their tendencies and individual skill sets. You may have developed a level of comfort with programmer A that allows you to hand them some basic flow diagrams and design specs and have confidence that they will be able to work successfully from them, making appropriate modifications where needed. However, programmer B may need precisely detailed deliverables or HTML design templates, or else the final product will suffer.

Now let’s take a look at some real world scenarios and the information architecture deliverables I would likely use in each.

Example 1

My company has been asked to provide consulting services for a client that needs to design and launch a large new corporate Website. The organization has an IT group that will develop the site, but is looking for some outside expertise in the requirements analysis, design, and information architecture. They will be paying us on a cost (time and material) basis and have a relatively large budget set aside for our services. They want to spend the money up-front to get it done right and avoid costly redesigns in the near future. Fortunately the schedule isn’t overly tight and there will be enough time to do the work the right way. The work that I deliver on this project is a reflection of our company’s capabilities and will potentially lead to future work with the client. Therefore, I am going to spend additional time refining and “prettying up” the deliverables. Since the deliverables will be handed off to another company, they will contain extensive documentation and comments. After working closely with the client to determine requirements and establish target audiences, I decide that we will create the following deliverables.

  1. User Profiles
  2. Content Inventory
  3. Sample Use-Case Scenarios
  4. Web Site Map
  5. Paper prototypes (documentation of testing our IA assumptions)
  6. Detailed website wireframes / story boards
  7. Mockups
  8. Web style guide
  9. HTML designs and .CSS

Example 2

I have been asked to assist another division in my company with the redesign of a website for a client they are currently working with. Let’s assume the budget they can commit to the design and architecture is enough to cover detailed wireframes and site mockups, but not enough to cover HTML designs. Fortunately they have a junior developer with good design skills who can effectively (and affordably) turn the wireframes into a fully functional Web site. I won’t be in close contact with the developer once I have handed off the wireframes, so I will make sure to add a lot of notes and documentation on the wireframes.

Example 3

My group was awarded a new contract to develop a Website for an existing client. The timeline is very aggressive so we need to get moving quickly. The site is pretty basic and doesn’t require a lot of requirements analysis. The developers I will be working with are in my group so we will be working closely together as the project moves forward. I am already familiar with the skill sets of the programmers and their existing commitments on other projects. Therefore I determine that the quickest and most effective use of my time will be to sketch out some rough designs and put together some basic wireframes. I will use these to make sure the programmers don’t have any problems with the proposed functionality, and to get a quick buy-in from the client. Then I am going to build out the HTML for each major page or section. There isn’t a need to build out every page, just the ones that are unique. Once the HTML designs are finished the developers can quickly add their code and database connections, or break the pages up into includes or database elements. This approach gives the programmers a good head start and reduces their required level of effort.

Originally published December 2002

Examples of Wireframes, Site Maps, Story boards, Use Cases, Paper Prototypes

In my work as a web designer and IA I have come across many inconsistencies in the way Information Architects and other Web professionals refer to Web information architecture deliverables and diagrams. In speaking with various Web design groups I have heard multiple terms for the same deliverables. Web information architecture is a relatively new field which has yet to develop a consistent and universal set of deliverables, and terminology to refer to those deliverables. I also haven’t come across a central repository of IA deliverable and diagram documentation. This document is an attempt to fill that void.

What is Information Architecture?

Information architecture is the foundation open which websites are built. You can think of it as the blue prints for a website. It defines a website’s structure, hierarchy, and navigation.

What are deliverables? What are the most effective deliverables? The answer depends on the situation, audience, budget, time constraints, skill set of your team, and various other factors. Learning how to create these deliverables is the easy part. Gaining an understanding of when to use them, and in what format, is the tricky part.


Part 2 – How to use Information Architecture Deliverables

The following are the most widely used IA deliverables. However, there are additional deliverables which some consider to be the responsibility of the IA, while others would assign them to perhaps a PM or designer. The most widely used name for the deliverable is listed with additional synonyms also displayed. Some Web information architecture examples and samples are linked to.

Web Information Architecture Examples

1. Content Inventory (aka Content Survey, Audit)

A content inventory is intended to provide a consolidated snapshot of all the major sections, pages, and content on a Web site. This would include text, graphics, and multimedia. Some even go as far as to break content down into individual pieces or paragraphs of content. Sometimes a content inventory is performed on content that is not yet part of a Web site. This would be helpful for an organization that is collecting content to be placed on a new Web site. Card sorting would be helpful for organizing content in this situation.

Here a a couple examples of Web content invent roy variations.

  • Survey - A high level review of a site’s main sections and pages. It enables you to develop an understanding of the general site scope and major chunks of content.
  • Detailed Audit - this is a comprehensive inventory of every page on a site. This inventory will list every page’s filename, title, URL, and possibly its file type and a description. It’s also helpful to assign a unique page ID that will correspond to the pages location on the Site Map.
  • Content Map – This simply entails laying out the site content in a graphical format. I haven’t seen this used widely, and I’m not sure how much use it would serve. If you’re performing a content inventory on a current site, then an effective site map might nullify the need for a content map.

Sample content inventory (pdf)

Read more about content inventories for the Web

2. User Profile (aka Personas)

A user profile or persona is a realistic (but likely fictional) example of a target audience member. The profile commonly takes the form of a one page piece that lists the user’s name, occupation, education, demographic characteristics, computer/web experience, and site goals or likely tasks. A stock photography picture is usually used to give a face to the profile.

These profiles can be extremely useful in keeping the web team focused on the user’s needs. These may not be necessary for usability experts, designers, or information architects, all of whom should have a firm grasp of user-centric design. But they can be beneficial for project managers, programmers, and clients. When making decisions it’s helpful to be able to say “John B. really would have trouble with this,” or “Adding this link here would really make life easier for Sharon.” User profiles also help to reinforce the importance of an Information Architect. It is a deliverable that documents the establishment of target audiences, a process that might have taken a considerable amount of effort and research.

Read more about user profiles for the Web

3. Use Case (aka User Scenario, Task Analysis, User Flow)

Use cases are narratives that describe how a user might use a system or site. A use case illustrates a sequence of events that an actor (external agent) might go through in order to accomplish their goal. A use case is similar to a process flow.

  • Essential Use Case – Narratives that remain relatively independent of a specific technology or implementation.
  • Real Use Case – Narratives that incorporate the current technology and/or site design. This is basically the same thing as a Process Flow.

Sample use case (pdf)

Read more about use cases for the Web

4. Sitemap (aka Site Map, Site Hierarchy Map, Site Diagram, Blueprint, Web Map)

Site maps are one of the most critical and widely used web information architecture tools (along with wireframes). They show the overall structure and hierarchy of a Web site. They can be used as the first step in laying out the web information architecture of a site, and will provide the framework upon which to base site navigation. When I set out to understand the IA of a current site, or design an IA for a new site, I start by sketching out a ruff site map. Site maps can be constructed in a wide variety of formats, but the general structure and principles remain relatively consistent.

Sample Site Map (pdf)

Read more about Web sitemaps

6. Wireframes (aka Wire Frame, Page Architecture, Low Fidelity Mock-Up, Page Schematic)

Information Architecture Wireframes (combined with Site Maps) are the bread and butter tools of information architects. They are useful for conveying the general page structure and content requirements for individual pages.

Wireframes need to achieve a happy medium between being too precise and too loose. What I mean by this is that a wireframe that is too precise or detailed may leave little creative room for the designer. A wireframe that is too loosely defined can easily be misinterpreted by designers and developers. The format used should be dependent upon the audience.

Using detailed wireframes will frequently flush out new requirements and questions that nobody has thought about yet. They also help to keep a paper trail of functional and design decisions that are made. I sometimes use wireframes to get people thinking and generate requirements. Wireframes will sometimes end up evolving into the default requirements document for a Web site.

Sample Wireframes (pdf)
Sample Wireframes 2 (pdf)
Sample Wireframes 3 (pdf)
Read more about Web wireframes

7. Paper Prototype (aka Low Fidelity Prototype)

Paper prototyping involves using screen shots and/or hand sketched page diagrams to quickly elicit user feedback and identify interface IA problems. Using a paper prototype involves conducting a usability test using a low fidelity prototype. These prototypes can be created electronically using programs such as MS Word, Excel, Visio, or various WYSIWYG editors. However, in many cases paper prototypes are nothing more than loosely hand-sketched designs. The quicker these paper prototypes can be created, the greater the benefit. Paper prototypes shouldn’t incorporate specific design elements such as color, style, fonts, detailed graphics, etc.

You may be hesitant to present something that might resemble a 6th graders art project to a client. However, with a bit of education the client will be appreciative of the time and money you are saving them.

8. Story Board (aka Storyboard)

It’s debatable whether a storyboards are anything different than a set of wireframes, but they can tend to illustrate more of a process than a wireframe does. However in many cases IAs add usage and process notes to wireframes. I have also see storyboards (or something resembling them) referred to as Blueprint, Schematic, Grey Model, Interaction, Interaction Wireframe, IA Requirements Document, Design Document

Story boards typically combine information from process flows, site maps, and other IA deliverables. They can be used to illustrate a single screen or a whole system or site. They usually offer screen shots or some type of graphical representation of the screens, combined with a narrative description. Storyboards help to document the functionality of the site and describe how users will potential use the interface. These deliverables can be used by programmers, project managers, upper management, and clients to ensure that everyone is on the same page. Storyboards often turn into the initial requirements documents that programmers begin coding from. These deliverables provide an excellent chance to get client buy in and sign-off on the proposed function laity and IA of a site. Story boards can be similar to a detailed wireframe, and there is a lot of crossover between the two.

Sample Story Board 1
Sample Story Board 2
Sample Story Board 3 (pdf)
Sample Story Board 4 (pdf)
Sample Story Board 5 (pdf)

9. Style Guide

Style guides are used to document baseline design requirements for a site. They usually define font classes and a wide range of various design conventions to be followed. This deliverable would generally be considered the responsibility of a designer, but in some instances the Information Architect may be covering multiple roles (as is the case with me). HTML Wire frames are a good solution to solve multiple needs; deliverables for clients or management, and functional templates to start programming from.

Sample Style Guide (pdf)

Read more about Web style guides


Using Web Information Architecture Diagrams

In part 2 we take a look at the factors that influence using information architecture deliverables. Which provides more information on using Wireframes, Site Maps, Story boards, Use Cases, Paper Prototypes, User Profiles, and Site Maps and other web information architecture examples.

Originally Published January 2007

Content Inventory: Sometimes referred to as Web Content Inventory or Web Audit.

Many times when an Information Architect begins the process of redesigning or creating a new Web site, their first step will be to complete a detailed content inventory. This involves analyzing and recording what content and pages currently exist on the Web site. Content refers to everything that appears on a Web site, including copy, images, files, multimedia, etc. A content inventory provides everyone involved a detailed listing of all the major sections, pages, and content on a site. More »

Originally published February 2007

Use cases, sometimes called user scenarios, are narratives or flow diagrams that describe how users will interact with a Web site. Some people also refer to them as task analysis or user flows. Regardless of what you call them, the idea is the same. Illustrate to people scenarios or specific tasks which users will perform. So the names of the deliverables are pretty self descriptive. A case (study) of a use or a scenario. Sounds right to me. More »

Originally published January 2007

Before starting any Web project it is imperative to understand the target audiences. The target audience may be existing users or, in the case of a new site, new users. User profiles (also referred to as user personas) are an excellent way to document and illustrate realistic sample users. User profiles are short bios or narratives about a user and their use of a Web site. These personas typically are concise one page documents. More »

Originally published December 2004

Information Architecture (IA)

Information architecture is the foundation open which websites are built. You can think of it as the blue prints for a website. It defines a website’s structure, hierarchy, and navigation. Individuals who specialize in this science are referred to as information architects. Many of the original Web information architects had backgrounds in library sciences. More »