In my last post, I discussed issues with wireframe documents becoming too bogged down in visual details. There has been some great conversation since then, and some great reference materials to dig into. Definitely head back there and look through the links in the comments and trackbacks. I’m really excited about this conversation, so keep the ideas coming!

As promised, I’ll show you the system I’ve come up with for documenting the elements of a site and how they function. There are a few things I did that might inspire you. Take one idea, take it all, let me know if you find a new use for any of these methods.

The Site Schema Document

I’m calling this a Site Schema Document — it’s a series of elements that work together to describe the plan of a site. My SSD is a multiple page document that starts with a table of contents, then a site map, then these special wireframes, along with any flow diagrams, use cases, or any other UX deliverables that might be needed. It’s very flexible, and should only include as much information as needed, no more.

There is a separate copy document that maps back to elements in the wireframes through a system of labels and note markers. The development team also might create a separate functional spec sheet that I will use to make sure I’ve captured everything I need to in my document.

The documents in the SSD are created as needed and with input from the rest of the team. It’s functional for everyone on the team throughout the design and development process. There are elements for the design team, with input for placement and content that still allows for plenty of flexibility for visual design. All functionality is described in detail to make this a valuable document for the development team. There are elements in here to work with copywriters, so they know what copy needs to be written, where it goes, and what it needs to say. The idea is to meet all these needs without providing any extraneous information.

Not only what, but where

In part 1 I mentioned that I was inspired by the Page Description Diagram. This documentation method provides the bare minimum amount of information — what elements go on the page, what each element does, in what priority. For some projects and teams, this is all you really need before you can move into design. For the project I was working on, I found we needed a bit more.

We had to be pretty thorough in our documentation, both for the client to be able to give valuable input as the project progressed, and because we were working with an offsite development team. I felt that a PDD wouldn’t be thorough enough, and we’d take the risk of going through design revisions that could be taken care of more quickly with a more detailed document before the design phase starts.

On the other hand, I knew a traditional wireframe would leave too much of the visual design decisions up to me, which wouldn’t fit into our schedule. I needed to stick to more basic functional and usability decisions, knowing any visual design decisions I made at this point would likely be reworked by the design team when they started creating look and feel concepts. There were some decisions we had already made about the visual layout, but they were very broad, and I wanted to leave the details out of the documents until we got to the concepting stages.

I ended up combining the traditional wireframe format with a PDD format, which allowed me to communicate some of the layout decisions that had already been determined without dictating too much about the visual design. It also allowed me to list out the elements quickly, with minimal fussing about the details.

Step 1: Work with the design team to determine basic layout

This document started out as a traditional wireframe. A box to represent the screen, with a wide margin on the side for annotations. I then divided the screen up into areas like “header,” “footer,” “content,” and “sidebar.”

The exact placement and size of these boxes isn’t really important. It quickly becomes clear that this is not intended to match any sort of visual design. Boxes can be somewhat related to the proportions of the final screen design, but there’s no need to get into too much detail.

Even something as simple as that might be considered too much visual layout for some teams. For this project, we had already done some paper prototypes (with more traditional high-fidelity wireframes) in user testing sessions and had determined some basic things about the design — the sidebar was the most usable when it appeared on the right, The IA made the most sense with horizontal navigation, etc.

I don’t like to work in a vacuum. Design decisions based out of usability, IA considerations, and functional requirements should definitely be worked out with input from the UX team, the dev team, and the design team, as early as possible. Document the decisions in the Site Schema, along with reasoning, and nobody will dispute them.

Any decisions that are purely aesthetic or made arbitrarily shouldn’t be included at this stage. The main idea here is to document things based in fact, as I like to think of it. These are things that aren’t going to bend to anyone’s whims. You should have a solid reason for being able to place these content boxes where you’ve placed them, and then put your reasons in the annotations.

Step 2: List site contents in each layout section

This is where I took inspiration from the PDD. Instead of illustrating each element, I realized all I needed to do was list each element. This is extremely quick and easy to update. I don’t change font size or weight. I don’t fuss with placement. I keep plenty of space around elements for note markers. (More on note markers in a minute.)

Because things are placed relatively where they’ll end up in the screen design, visual people (like me) can understand how everything relates to other elements on the screen. But because elements lack any sort of formatting or illustration, they communicate only the functional information, avoiding the confusion that may occur when wireframes get too detailed.

Only list things once

The example I’m illustrating here is an imaginary content-heavy site, with a few page templates and articles pulled in from a database to populate the content.

If there are, for example, a list of articles on a page, I’m not going to put in any “Lorem ipsum” or an individual placeholder for each article in this document. Instead, I say “for each article:” and then I’ll list the elements involved in listing each article:

• Article Title
• Article Author
• Article abstract (24 words)
• Publish date
• [tags:] top five tags

I put the words for each article: in italics to differentiate this explanation from site content. I put the label [tags:] in brackets because this represents actual text that will be printed on the page, as opposed to pulled in from the database. The copywriter may want this to read “related tags” or “top tags” or even “related topics” — I want to leave that up to him and keep it separate from my document. I could also use something descriptive, like [tag label] to further avoid stepping into copywriter territory. When an element is clickable, I underline it. In the next step I’ll add link details.

Specific formatting conventions are up to you. Just be consistent so the team can understand the conventions you’ve decided to use.

Step 3: Add note markers to reference link information and copy

In order to properly label my pages and links, I need to have a site map. A sample site map for this imaginary site might look something like this:

• 0.0 Home
  • 0.1 About us
  • 0.2 Feedback
  • 0.3 RSS feeds
  • 0.4 Privacy Policy
  • 0.5 Search Results
  • 0.6 User Profiles
• 1.0 Section 1
  • 1.1 Articles
• 2.0 Section 2
  • 2.1 Articles
• 3.0 Section 3
• 4.0 Section 4
• 5.0 Section 5

Now that I have a site map, I can label references to other pages within the site with their corresponding number. I’m using a little orange arrow icon to represent a link, and then a reference to the number of the page the link will link to.

I’m also going to label items I want to hand off to the copywriter. I’ll use blue (You could use any colors, like your company’s brand colors, for example.) and I’ll give each copy element a letter.

The copywriter on this project used a spreadsheet to create his copy document. The document was set up a little something like this:

This allows the copy document to go through its own rounds of revisions and approval, separate from the planning and design stages, while still allowing me to give input towards what kinds of copy elements are required from a user experience standpoint.

The client can use the wireframes as a map to see where the pieces of content will go, but can focus on the copy itself separate from the functions or look of the site. The design team can use lorem ipsum text, or, if the copy is approved early in the design process, can start designing with actual copy. Either way, once the copy document is approved, the development team has a system for plugging the copy into the site during build.

Step 4: Templatize, modularize, widgetize

For a simple site, the above techniques may be all you need to quickly create documents that your entire team can use. The idea is to quickly record the decisions you’ve made in a way that is easy to understand, communicate, and update.

The example site I’m working with here is pretty simple, but I think you can see how it might translate to something with a lot more going on.

For more complex sites, we can go into a lot more detail. If you look at the examples I’ve included, you might notice where I’m going with the Login Element, for example. For elements with a lot of interaction, multiple states, and other complex details, I break them out into their own pages of the document.

Also, in the spirit of only listing things once, I take most global elements out into their own pages as well. This way, only unique items get listed on any individual page, which is easy to update and can also help the developers easily see which items are part of the global template when they go into build.

If there is interest, I’ll publish further details on how I work with a more complex site and break things into little modules in a Part 3 follow up to this post.

For now, I’d love to hear what you think of the system I’ve come up with. It’s been a work in progress. but it really made a lot of sense during this recent project. I was able to document the minute details of a very complex site in a small amount of time, and quickly make updates as changes were inevitably made during the process. Though the end result looked different than the wireframe documents everyone on the team had been used to seeing, it was still easy to understand. I felt like I wasn’t doing redundant work that was better left to the design team, and they appreciated the creative freedom to do more than just apply a skin to a detailed sketch.

This document can supplement other deliverables throughout the project. There is still a place for high-fidelity sketches, mockups, and prototypes, especially for user testing. You might start out with a PDD before moving into something more detailed like this. It really depends on the project and the team. I hope this gives you another option when you need it, or inspires you to create something of your own. Let me know!