Are Design Patterns an Anti-pattern?

by:   |  Posted on

Sewing pattern

Design patterns are generally considered a good thing, but do they actually help run a user experience group? As a user experience group manager and an observer (and sponsor) of design pattern exercises, I’ve come to have serious questions about their actual utility. It’s not that design pattern libraries are bad, but that in a world of limited resources, it is it is not clear that the investment is worth it. Fortunately, there is a better approach: reaching outside the design group to solve the whole problem.

An interaction design pattern is a “general, reusable solution” “to common usability or accessibility problems”. They usually consist of pictures and descriptions of the best way to handle a GUI design element, such as a date picker. Libraries of them are found online (see below) and in many institutions with a user experience practice. Like all tools, they exist to solve a problem; but what is the problem?

They are generally said to help:

  • instruct junior user experience people
  • save time of documenting design details in every project
  • make collaboration with developers easier
  • encourage consistency

The case against design patterns

Pattern libraries have laudable goals, but in practice, design patterns do not support how teams actually work. Practically, the pattern approach assumes that the users:

  • know (and remember 3 months later) that the pattern library exists
  • quickly find the pattern that they need
  • know how to interpret the language
  • know when to apply a particular pattern and how much they can deviate
  • have the time and motivation to continue documenting ideas

Design patterns are not effective training tools.

Patterns, once literally a design on paper that could be copied, in UX are an abstract idea that professionals can reference. You can not copy a UX pattern, like you can copy a sewing pattern. Having someone read a pattern library will not make them a competent user experience designer. It would be akin to teaching writing by reading the dictionary – the “why”s are not answered.

Design patterns don’t replace UX expertise

Design patterns can be a useful reference point for the junior user experience designer. But experienced professionals find ideas and inspiration in the whole world. Should your team invest time in making a pattern library as a training tool, or just change the way they work? Should they spend time on documentation or collaborate on projects? Should junior people learn from the documents or, as is typical in the crafts, apprentice with an experienced designer?

Should your team invest time in making a pattern library as a training tool, or just hire more experienced staff? Should they spend time on documentation or collaborate on projects? Should junior people learn from the documents or, as is typical in the crafts, apprentice with an experienced designer?

Completeness and learn-ability are in conflict.

In order for a pattern to be used, it has to be easily read. But completely describing even the simplest UI pattern (like a two-panel selector) requires such detail as to prevent the person from absorbing it. Additionally, any design pattern I’ve seen inevitable contains “it depends” clauses, which leave the important decisions right back with the reader.

Pattern libraries suffer from a similar problem. Many seem to start by defining the basics, to answer questions like “when should one use radio buttons versus a drop down menu”, but lose steam before they get to the complex pieces. This is ironic, as the complex interactions are the ones that need the most definition, and offer the most creative opportunity. Defining the pattern of a radio button, is necessary for completeness, but not a good use of time or creative energies.

Design Patterns take a lot of investment.

The investment in the library needs to pay off in later efficiency to be successful. But each pattern is essentially a mini design project with extreme documentation and design reviews. Having corresponding template widgets is an additional effort, as is updating the designs when the inevitable rebranding comes along. (I’m already tired just writing this.) If your team uses more than one design tool (InDesign, OmniGraffle, Visio), who is going to update all the versions?

Design Patterns should help non – UX people first

Design patterns reduce work for UX people, but they clearly increase work for developers. Developers operate under time pressures and need a spec to code to. Directing them to look at a pattern library means that they have to find, parse, code, and review the pattern, in addition to the wireframe. The design pattern’s open ended nature requires them to read a general case and code a specific case. Because they are just designs, they can also ignore the ugly complexities in many of the problems, by simply not addressing them.

Design Patterns don’t work with a normal designer’s motivation – indeed, they seek to restrain it. When a person sits down at their drawing program to address a problem, a reference document is several steps away, especially under time pressure. They almost always want to design rather than copy, especially, when it is unclear if a new situation is different “enough” from an existing pattern. On the contribution side, any change will entail a review with peers, which could take weeks to finalize, too slow for a project. Large organizations who most need a pattern library (many practitioners) are least able to build one (complex organizations, conflicting deadlines).

Why do people make design pattern libraries anyway?

I’ve never heard of a business owner or technology lead asking for a design pattern library. They seem to arise from internal concerns rather than external requests. What if the motivation is not really project efficiency, but something more personal?

Pattern libraries seem to be made by a UX person who wants to put a stamp on how things SHOULD be done. To establish, once and for all, the right way to do something. The design pattern library could be more akin to building a model train set: like the real world, but controllable. They are like design projects without clients or time pressure. “Just this once, we’ll do it perfect”. A participant at a recent New York IXDA event said with pride that he personally had created several pattern libraries –it was a personal accomplishment, not a business achievement. No one can argue with how a person spends their free time, but teams have to make sure work time is spent wisely.

The downside to this motivation is that individual authors want to create their own collection, which inevitably duplicates the other libraries. Pattern Libraries also tend to be abandoned when the author loses enthusiasm after the initial burst of activity. Even the major sites like Yahoo and Welie have stalled. The last update on Yahoo was 2 years ago; Welie was 4 years ago.

[Pattern libraries] seem to arise from internal concerns rather than external requests. What if the motivation is not really project efficiency, but something more personal?

What is the solution then?

Let’s apply the user centered design process to this situation. Using the goal of “better designed products and increased productivity”, we can identify the three potential audiences of an enterprise Pattern Library: User Experience, the Business representatives, and Technology.

The UX group is primarily concerned with consistency and best practices. This is culture, not documentations and should be managed as such:

  • Culture is built through personal interaction. Review, Review, Review. Regularly meet to share work, and best practices.
  • Patterns do not mean your design sense can go on auto-pilot.
  • Build a collaborative culture referring each other’s work. (“Joe worked on something like that.”)
  • When a new design challenge appears, get a bunch of people to talk it over, get “good enough” agreement.
  • Document decisions quickly and spread widely, for example on a wiki (so any one can edit it).
  • Focus on content first, make the pretty library template as a reward for reaching 20 patterns.

Business and Technology are primarily concerned with getting work done and reducing costs. The biggest efficiency gain is reducing development time, focus on giving developers the tools and guides they need. The biggest issue is that typically, UX people do not code. The solution is to get out of the design cave and work with people who do.

Create a design ecosystem instead of documentation.

People do not RTFM. Period. It is hard to get people to engage with any documentation on their own. They are happy to read the details about what they want, but are put off by finding it inside a large document or library. The solution is to create an ecosystem where each piece reinforces the others. iPods were well-designed devices, but they succeeded because of the ecosystem (devices +iTunes + stores + accessories). Music was easy to find and buy, and easy to put on the computer. The overall experience of the ecosystem is what determines the success. When you say the answer is a document, rather than a community, it turns people off and limits their contribution.

The ecosystem should be composed of:

  • People: Developers, Designers, and business leads. People who can answer questions, who are motivated by their own job requirements and professional pride
  • Code library and documentation
  • Management demand

A code library beats a pattern library

The code library should be “internal open source”, a shared library enabling developers at a company to share code without worrying about licensing or malware. Instead of the whole org waiting while a centralized team builds the future, let every group contribute.
It should have the most commonly needed components with brief descriptions and links to example implementations, bug tracking and feature requests, supported by an active development and UX mail lists. Make them easily accessible as web pages, not a document. Style guides and pattern libraries get retained even if they are out of date. Social connectivity is much more important than printing them out.

It should have the most commonly needed components with brief descriptions and links to example implementations, bug tracking and feature requests. This is supported by an active development and UX mail lists.

For each presentation layer technologies you support, there should be in Version Control system, with a Main branch, supported by a core team, and an open Contrib branch that anyone can put components in. Good components are promoted to the main branch, which is released in versions, so updates do not break existing apps.

Components should cover three scales:

  • Basic styling of standard components
  • Custom components, like a date picker or type-ahead
  • Page sized components, such as forms,dashboards, or search result pages
Design patterns are not, in themselves, a bad thing, but in the real world, it’s better to focus on the lifecycle of design, rather than the design process alone.

How do you get such a library?

In a world of limited resources, one has to boot-strap the Library.

  • Build off of the current running projects. Nominate widgets or functions in an active project as “library-worthy” and have them coded abstractly and contributed to the library.
  • Publish and reward people who contribute to the library.
  • Make a most wanted list and see who has them.
  • Solve problems that you actually have, don’t worry about completeness.
  • Have the patterns in working code samples accessible by anyone in the firm. Instead of pretty pictures, have the code that actually performs how your want it to. Make the options / parameters editable in the sample, so anyone can play with configuring the sample.
  • Look and feel should be a separate code library, released in parallel, so that the design can be upgraded in the future (as it will be) without affecting functionality.
  • For general guidelines, write high level guidelines a sketch or two, but point the developers to ask a mailgroup of designers and front end engineers. When a question gets asked enough that it is annoying, code the pattern.

Management support is critical -if the project is a “nice to have”, it is doomed. Each project should report what they contributed to the library and what they consumed. A developer’s performance evaluation should list what they contributed to the library and what they re-used -Both save the firm money. At a firm I worked at – a single component, taking 2 weeks of two developers’ time, was re-used over 200 times. This saved 16 person-years of effort -this is real money. Not every component will be so effective; the library team should be focused on the business value of each component and the user experience of the eco system. If done right, the design / code ecosystem has the potential to both improve design and save time, something we can all agree on.

Design patterns are not, in themselves, a bad thing, but in the real world, it’s better to focus on the lifecycle of design, rather than the design process alone. Working together with non designers can make everyone’s life easier, and make the final product as good as the design.

Are your users S.T.U.P.I.D?

by:   |  Posted on

Are your users STUPID?

It is an honest question: how smart are your users? The answer may surprise you: it doesn’t matter. They can be geniuses or morons, but if you don’t engage their intelligence, you can’t depend on their brain power.

Far more important than their IQ (which is a questionable measure in any case) is their Effective Intelligence: the fraction of their intelligence they can (or are motivated to) apply to a task.

Take, for example, a good driver. They are a worse driver when texting or when drunk. (We don’t want to think about the drunk driver who is texting.) An extreme example you say? Perhaps, but only by degree. A person who wins a game of Scrabble one evening may be late for work because they forgot to set their alarm clock. How could the same person make such a dumb mistake? Call it concentration, or focus, we use more of our brain when engaged and need support when we are distracted.

So, what does a S.T.U.P.I.D. user look like?


A subtle reminder like this would have saved me a few weeks ago.“Fear is the mind killer”, Frank Herbert wrote. Our minds are malleable and easily affected by their context. The effect of stress on the brain is well known, if not well understood. People under stress take less time to consider a decision thoroughly, and they choose from the options presented to them rather than consider alternatives. Stress is often due to social pressures. Car salespeople know to not let a customer consider an offer overnight, but pressure them to buy right away.


Tiredness is one of the largest causes of industrial and motor vehicle accidents. Interfaces used by tired people should take into account their lowered sense of self-awareness and number of details that the user is likely to miss. A classic example of an interface used by sleepy people, the iPhone alarm clock is typically set right before bed. Unfortunately, it doesn’t ring if the phone is set to vibrate, the default state for many people. When a user sets the alarm, it would be useful to override the vibrate feature, or at least remind them that it won’t ring.


Training for enterprise applications is more often discussed then enacted. Users are thrown at an application with a manual and a Quick Reference Card. Applications that are not designed around the user’s workflow have to explain their conceptual model while they are being used: “where” things are stored, how to make changes, who to send things to.

Complex systems that are used infrequently are a particular problem. In the design of the automated external defibrillator, it is assumed the user may have no knowledge of the science or training on the device, and will be using it in a chaotic, stressful environment. The frequency of use should drive design. Yearly processes, like doing your taxes, should assume that the users have never done it before. In rarely used interfaces, customization is likely to be less useful, but a comparison to previous year’s entries is very useful as they remind the user what they did before.


Nothing reduces effective intelligence faster than doing a boring task against one’s will.

More important than the user’s mental model of an application is their mental attitude toward the task. Someone sitting in the front passenger seat of a car may have the same field of view as the driver, but unless they are focused on it, they will not remember the path driven. Nothing reduces effective intelligence faster than doing a boring task against one’s will. When a user is passive, complexity becomes insurmountable. Games aimed at casual gamers know to keep the interaction model simple, using a flat navigation and avoiding “modes” (e.g. edit vs view).


User centered design is a powerful approach because it recognizes that there are many reasons people use a system. Airline booking sites are used to buy tickets, but also to see if the family can afford to go on vacation. The designer should recognize that they cannot solve every problem, but should give users the tools to help themselves, to work independently of the application’s intended method. In internal enterprise systems, the top user request is often “export to Excel”. This often reflects that the system does not meet the user’s needs. Excel empowers the user to do ‘out of the box’ actions. It is the API to the real world.

…The top user request is often ‘export to excel’…. Excel empowers the user to do ‘out of the box’ actions. It is the API to the real world.


People are multi-tasking more than ever, whether it is simply listening to music while driving or playing Farmville while watching TV. Effective multi-tasking has been shown to be a myth, but it is a popular one. Paying “partial attention” to multiple activities has significant impact to your perception of an interface. Users are often said to be on “autopilot”, clicking on things by shape, rather than reading the text. An interface cannot rely on the user having a clear and consistent working memory across multiple screens. The task and details must be re-stated at each step to remind the user the step they are on and what they need to do. Frequent, automatic saving of user entered data is essential, especially as connections can time out.

Help S.T.U.P.I.D. users by designing S.M.A.R.T.

Start-ups often experience a shock when they emerge from the hothouse of heads-down development. Their intended customers barely have time to listen to their idea, let alone devote time to explore its features. The contrast between a small group of friends working intensely together on a single project with the varied needs and limited free time of their customers can be a disheartening experience.

Projects often fail not because the idea is bad, but because the value their service will provide is not easily understood. The question I ask my team is “What problem, from the user’s point of view, are you solving?” It has to be a problem the user knows they have. If the problem is not obvious to the user, in terms they understand, the solution doesn’t matter. Focusing on the problem keeps a project from drifting into fantasy requirements: solutions looking for a problem.

Design teams often use themselves as model users, but…. The user knows nothing about the product, doesn’t understand the concept, and doesn’t care.

Design teams often use themselves as model users, but they are almost the perfect storm of differences between themselves and the users.

  • They know the product exists and what it is supposed to do.
  • They understand the internal concept, including its past and future ideas.
  • They care, personally, about the product. Their success depends on it.

The user has none of these things. The user knows nothing about the product, doesn’t understand the concept, and doesn’t care.

What can be done to make S.T.U.P.I.D. users S.M.A.R.T?


Why are simple apps popular these days? It is not that people don’t like features, it’s because instant comprehensibility trumps powerful features. In the old search engine wars, Google may have had a better search algorithm, but they became known for having a simpler design. Yahoo and others tried to become portals, losing sight of the users primary goal. I advise people to “Design the mobile version first” to help them focus on the key user benefits.

The down side is that any successful project expands and adds features to address additional user needs. What starts out as “Writer for iPad” can end up as Microsoft Word. Simple is not always better, but keeping the new user in mind helps find the right balance.

Help the user remember WHY their password is failing


An app is only as good as the user understands it. That starts with the name – is it cute or does it explain what it does? Is it “” or “Automatic Mailbox”? The iPhone / iPad apps’s television ads were effective sales tools, but also trained a generation by simply showing them in use. Each step of a workflow is subject to delays and distractions. Ecommerce sites know to reduce links during the final checkout process. With complex transactions, the risk is greater that the user will have lost their focus. Remind the user what they are doing in big title text. Focus on delivering Clear and Consistent messaging and instructions, for example, adding side notes like’s password guidance.

If the user has but one hard drive, why ask?

Accept Autopilot

Standard design patterns are good, but they also throw the user into autopilot. It makes sense to break them for critical decisions. The hard part is determining what a critical decision point is. Observing user behavior, customer service records, and identifying risks to the user’s data are good clues. If something is simple enough that the users are mostly on autopilot, for example installing software, make the default action a single click.


The dark side of users on “autopilot” is that they will regularly make mistakes by not paying attention. Mistakes are generally not obvious to a system, but it is good practice to highlight destructive actions and enable recovery. Capture data in little steps. Saving form fields instead of form pages, prevents large data loss. It’s a good idea to highlight and ask for confirmation on big, destructive changes, like deleting a database. “Undo”, common on computers, but slow to come to the web, enables the user to recover from errors.

Gmail lets users undo moving a message to the trash.

Gmail lets you recover items from the trash.

Gmail also let you restore your contacts if you accidentally make a large, destructive change.

An excellent example of protecting the user from their own mistakes

Test in realistic situations

There is an essential flaw in the two-way mirror usability test method. In the interest of copying the form of the lab-coated scientist, these rooms create an artificial aura of “science”. But as ethnographic research can tell you, real world usage is so different as to make the test questionable. It selects for a test population that is free in the middle of the day, motivated by $50, and M&Ms, puts them in an unfamiliar environment with a personal guide to focus on a specific task with no distractions. This is about as unrealistic as it gets.

There is an essential flaw in the two-way mirror usability test method…. It selects for a test population that is free in the middle of the day, motivated by $50, and M&Ms.

In reality, the same person may have a child on their lap and only 10 minutes to look up a flight. The fact that an ecommerce session may expire after a few hours is trivial for some, but significant for people who only have a few hours a day to use the computer. “Universal Design” is a great approach, because methods to help specific disabilities tend to be useful to the general public.

Testing should go beyond the user interface and cover the basic business model. The Apple iTunes video download “rental” is for 24 hours. Unfortunately, people tend to watch movies at the same time each day, for example, after the kids go to bed. If your kids wake up, you have to finish it earlier the next day. Would it have killed them to make the rental 27 hours, so parents could actually use it?

Design for the right level of Effective Intelligence

Effective intelligence obviously varies across situations. People are ingenious at figuring out things they really want, but the simplest task is insurmountable to the unmotivated. Both scenarios are solvable, but an application that makes the wrong assumptions about its users will fail. (Interestingly, this study suggests that easier-to-use design can affect the user’s perception of difficulty, and encourage them to complete the task.)

One should adapt their strategy to the user’s desire and the problem’s complexity. Here’s an unscientific matrix for effective intelligence with software interfaces.

This matrix compares the amount a user desires to complete the task versus the complexity of the task to that user type. Different user types will have different measures of complexity, so one might create several matrices.

Effectiveness matrix

Low Desire, Low Complexity – The goal here is to finish these tasks as fast as possible. Follow standard design conventions, seek to eliminate steps.

Low Desire, High Complexity Complex – Tasks that the user doesn’t want to do are a danger zone. Can the problem be reconsidered or eliminated?

High Desire, Low Complexity – The easiest quadrant.

High Desire, High Complexity – This is the most interesting quadrant. A self-training interface, (integrated help, training modules) can get the user started; they will often take it the rest of the way. Video games often have a “training” level to train the user on basic skills like moving around.

Maxwell Smart. It's a pun on... Oh forget it.

Get Smart

Effective Intelligence is a helpful concept in the design toolbox. User research and testing are the best ways to know your users, but knowing what may limit a user in reality helps design ways to make them smarter.

One-sheet thumbnail

Like this article? Want to keep Stephen’s wisdom close at hand? Download the handy, cubicle-friendly, 61kb PDF to hang on a nearby wall and you’ll always remember to design SMART.

Real Wireframes Get Real Results

by:   |  Posted on
“Just because project teams understand the purpose of wireframes, that doesn’t mean everyone will. Similar to listening to someone sing out loud to his iPod: we only hear the singing, while the person hears the whole orchestra.”

How many times have you been asked, “So, is the new website going to be black and white too?” after presenting your wireframes to a client or a usability test subject?

This question is almost a traditional part of being an information architect. Wireframes do not clearly define what they mean to convey, leading to confusion. This is most apparent in wireframe usability tests with users who don’t know anything about the project or process. Fortunately, there are a few simple steps that will make wireframes be understood by anyone. They don’t even have to be much more work. It’s simply a matter of choosing to “get real” from the start.

Real people don’t understand wireframes
Usability tests are done to get early feedback on content and functionality decisions from people outside the project team. These participants, unfortunately, are not sure how to respond to a wireframe. It is not intuitively clear what they should be doing, which site they are looking at (public site, intranet, client site)—it may not even be clear that they are looking at a web page. This lack of information and context adds a bit of cognitive friction to each step in the process. This level of confusion results in less confident answers and fewer opinions.

Wireframe tests usually take place with well-meaning, but unsophisticated users. They generously accede to poking and prodding and answer questions as best they can, despite not exactly understanding what is wanted. This realism gap is due to the lack of definition of what should and should not be looked at. “Look at the field names but not body copy.” “You can look at the forms but not images.” “Comment on the page layout but not design, and, yes, the font size but not font.” It’s no wonder that the layperson is confused.

Visual affordances, such as color and underlining links are key to using a site, and these cues make a significant difference in a usability test. Users cannot confidently predict how they would use a page if they don’t recognize links or can’t read what the page expects them to. Information architects, however, tend to shy away from these cues because they don’t want to step on designers’ toes. Wireframes, after all, are not designs.

Or are they?

Avoiding “design” elements removes visual cues that users rely on:

* Color, which identifies hyperlinks and focuses the user’s attention on an element of the page
* Branding, which confirms that the user knows where they are
* Recognizable web page elements, such as forms and search fields
* “Content,” such as account numbers or product names, which allows experienced users to focus on how they would really use the page, instead of interpreting “lorem ipsum”

The boundaries of the role of the information architect shouldn’t be more important than clarity.

Originally the term “wireframe” referred to a quickly rendered 3D model showing the model’s structure used while the model maker was working. They were much faster to work with than the full rendering. Interestingly, they are not currently used as modern tools and techniques are fast enough.

Why wireframes?
Information architects construct wireframes instead of designing final pages, in part, because:

# Wireframes are faster.
# Information architecture and design phases can happen in parallel.
# Wireframes force viewers to focus on the content, not the visual design.

Notice anything? All these goals are internally focused on the project-team. Wireframes aren’t created for external audiences.


Figures 1,2: Originally the term “wireframe” referred to a quickly rendered 3D model showing the model’s structure used while the model maker was working. They were much faster to work with than the full rendering. Interestingly, they are not currently used as modern tools and techniques are fast enough.

Wireframes are conceptual models of a page that web design teams have become to interpreting. Each wireframe is surrounded by experience in reading them, knowledge about the project scope, knowledge about how the designer will use the document. Liz Danzico writes about this wireframes becoming project memory in the article “The Devil’s in the Wireframes.”

Just because project teams understand the purpose of wireframes, that doesn’t mean everyone will. Similar to listening to someone sing out loud to his iPod: we only hear the singing, while the person hears the whole orchestra. Likewise, the test subject knows only that “the page isn’t going to look like what they see,” but what they see is all they have to react to.

Wireframe makeover
Here is an example of the simple steps to transform a standard wireframe into a realistic wireframe. In this example, let’s say we are designing a registration process for (no special criticism is intended for the site below).

The site we are designing for


Here is a standard wireframe:


And here is the same wireframe, made more real. (An additional 10 minutes was required to use the standard header and a library of realistic form elements in Visio or InDesign.)


And here is a version re-using Verizon’s standard buttons and clip art. (Additional time: two minutes.)


Which do you think would be easier for test subjects to understand?

Tips to get real
These tips are best for intranets or sites with defined styleguides, and less useful for graphical or marketing pages where the design is the content of the page.

# Make a header bar with the company branding. It should look like the site they are used to, showing the company logo.
# Use color. Hyperlink color is a basic requirement.
# Put a web browser frame around the image (or at least the first page).
# Use real form elements, not drawn replicas of them.
# Create a template or library of real form elements (feel free to share yours in the comments below).
# Avoid lorem ipsum. Instead, use: “Descriptive text that will explain this product.” to avoid confusion about greeked text.
# Use accurately sized fonts (this also keeps you honest about what can fit on the page).
# Use real detail such as products names and data. Especially on transactional tools with expert users, users care about what they are reading and recognize and use data like account numbers. It may not be important to us, but they have expectations that need to be met.

Compare the wireframe to the current site, note any changes in functionality that may trip them up.

The page doesn’t have to be perfect, just enough to give the test subject their bearings. A semi-designed page is easier to understand than a non-designed page. This is not wasted work; these decisions need to be figured out at some point. Consider bringing designers into the process earlier, cooperating on file formats and processes. It might even make their jobs easier.

Are traditional roles limiting projects?
Wireframes are in fact the first design iteration, and this overlap with visual design can be uncomfortable for teams. However, denial is not the way to fix this issue. Good collaborative relationships should make this overlap an opportunity to reduce work, not fight over ownership. Concern that wireframe might be mistaken for a visual design, or worse, be criticized for lacking design, may be holding the entire project back. It is much easier to communicate within the project team than the outside audience.

Consider these and other ways to make the transition as smooth as possible, for example, by having the wireframe be designed to import into the designer tool without retyping all the text.

The Lazy IA’s Guide to Making Sitemaps

by:   |  Posted on
“I would suggest that making sure the little boxes line up is a waste of an IA’s mental abilities. … So what is an IA to do?”

This article further develops the excellent Automating Diagrams with Visio by Michael Angeles.

Sitemaps are common deliverables, desired by clients who want a visual representation of a site. Since they are rarely used to make decisions, information architects may not consider them the valuable tools they are. The effort required to make and maintain them requires time that might be better used elsewhere. In fact, I would suggest that making sure the little boxes line up is a waste of an IA’s mental abilities.

Especially when your sitemap looks like this.

So what is an IA to do? Turn to Excel, of course. Storing sitemap data in a structured data format such as Microsoft Excel makes the data easy to edit, easy to share with the team, and easy to elaborate on (e.g., adding example notes and URLs that may not be appropriate for the map itself). Unfortunately, this approach requires maintaining a spreadsheet in addition to maintaining the visual sitemap.

Or does it?

This article includes step-by-step instructions on how to make sitemaps with:
1. Excel and Visio 2000 or Visio 2003 (Windows only)
2. Word and Inspiration (Mac OS and Windows)

Use these lazy techniques and spend your time on better and more interesting problems than lining up little boxes!


I’ve chosen these three options because they use standard applications that store the sitemap data in a format that can be edited by non-IAs. Each option demonstrates how you can store the data in the first format (Excel or Word) and import it into the second program (Visio or Inspiration) to—Voila!—create the sitemap.

You can use this zip file to access all the templates referenced in this article. I suggest doing the exercise once with the sample file to get the hang of it, then editing that file to your needs. The Excel spreadsheet has been written to do some semi-fancy calculations to let you store your data on the import sheet in a nice format and to output Visio-readable data on the output sheet.

1. Only edit data on the Input page.
2. Eliminate blank rows in the middle of your data.
3. The top sitemap box must be in field A2.
4. The template is defined for up to 200 elements

Technique 1: Excel and Visio 2000 / 2003

This approach uses the import data feature of Visio 2000 (Note that this feature has been removed in Visio 2003) and (mis)uses the “Organization Chart Wizard” from Visio 2003. You store and manage the sitemap data (the list of links in a structured organization) in Microsoft Excel, save it as a text file, and import it into Visio for quick visualization.

Step 1: Enter your sitemap data in the “Input” sheet in the file “template_for_visio_2000_and_2003.xls.”


For Visio 2003, proceed to the variation below.

Step 2: Go to the “Output for Visio 2000” sheet (and pay it no mind).

Save as Type “Text (tab delimited).”

You will see two alerts. Click OK and Yes.


Close the file. You may get the alerts again, hit “OK” and “Yes.” Closing the file is actually important!

Step 3: Open Visio 2000. Click “Open.” Choose Files of Type “Text (.txt, .csv).” Choose the file you just saved.

Step 4: When the dialog box pops up, set Field separator to [Tab] Text Delimiter to “Comment Character to ;. Click “OK.”

Step 5: A sitemap! Edit your sitemap to suit your fancy.

Variation for Visio 2003

Step 2: Click on the Sheet tab “Output Visio 2003” (and pay it no mind). Save the Excel file and close it.

Open Visio 2003. Select the “Organization Chart Wizard.”

Step 3: Select “Information that is stored in a file or database.” Click “Next.”

Step 4: Select “A text, Org Plus (*.txt), or Microsoft Excel file. Click “Next.”

Step 5: Find the demo file included with this presentation “example_visio_2003.XLS.” Click “Next.”

Step 6: Leave these defaults. Click “Next.”

Step 7: Remove “Title” as a displayed field. Click “Next.”

Step 8: Ignore the Custom Property fields (though you might be able to think of some use for the other fields in some interesting way). Click “Next.”

Step 9: You can make sitemaps that span multiple pages. Choose “specify.” Click “Next.”

Step 10: This allows you to define the top Sitemap box on the page. If you follow the Excel template, you can leave this alone. Click “Finish.”

Step 11: A sitemap!

Step 12 Right click on the sitemap to edit properities.

“Arrange subordinates” changes the sitemap layout.

“Change Position” changes the look of the boxes

Technique 2: Microsoft Word and Inspiration

This (mis)uses the flowcharting tool Inspiration. To do so, you format the sitemap in Microsoft Word outline format, save it as a RTF document, import it into Inspiration, and modify the diagram to look like a sitemap. The outline format can also be created directly in Inspiration, but storing the data in Word allows you to better collaborate with coworkers and clients.

Step 1: Outline your sitemap using Microsoft Word’s Outline format. Save it as a RTF file. (Step 1 is optional: you can make the outline in Inspiration, but some users may wish a more accessible format, like Microsoft Word.)

Step 2: Open Inspiration. Create a new file. Open the RTF file.

Step 3: Inspiration converts the RTF file to its own format. You may have to do some minor editing to remove blank rows, as shown above. (See image 26)

Step 4: Click the ”diagram” button at the upper left. What a mess! But click the “arrange “ button…

Step 5: Select diagram type “Top down Tree” and Lower level stacking option “Right.”

Better arranged, but visually lacking.

Step 6: Select all then click the rectangle in the menu bar. Now you can do things like take off the drop shadow, change the fill color to white, change the line color, etc.

A sitemap!

Working hard, hardly working
Sitemaps can be useful tools and are a whole lot easier when you separate the data from the visualization. After you have done these steps a few times, you will be able to update a sitemap in under a minute.

All these techniques can be expanded and improved upon. Let me know what you have done and what works for you. Have fun, but don’t work too hard!

This article references the following downloads:

Templates referenced in article (Visio, Inspiration, Excel)

For more information
This article includes step-by-step instructions on how to make sitemaps with:

Excel and Visio 2000 or Visio 2003 (Windows only)

Word and Inspiration (Mac OS and Windows)

Downloadable excel Site Map Thanks to Jon Stuckey and Marcia Stanton.