Design for Now

When I’m reading through business requirement documents, creative briefs, or high level explanations about what a site should do there’s one line this is almost always there:

“We want the design to be flexible for the future.”

It’s by far my least favorite thing to see. My beef is not that I think sites shouldn’t be flexible for the future (they should!), it’s just that the expectations surrounding this one single line vary so greatly.

There’s no doubt that thinking about the future is vitally important to a business. But I’ve seen countless conversations (about navigation structures, page description diagrams, wireframes, and visual design) get derailed because “we need to think about what might happen in the future”. This should never, ever happen. We should base our discussions on what you know, for certain, today.

Similarly, brainstorming about the future should happen before we start doing design. Otherwise, we run into trouble and the design you end up with will be less effective.

When I read the flexibility line, I can’t help but think the client is trying to cut design costs because they don’t want to have to do a large redesign again in just a few years. This makes some sense (you should be able to add features and tweak the site). But if down the road you want big changes, you’ll need to have another designer take a look at each proposed addition on a case-by-case basis, to figure out how they’ll best work with the overall design.

The bottom line is this: Designing with an eye toward flexibility and the future can be done one of two ways. Either you build a house and leave out a few bricks and some roof tiles, or you build a complete, smaller, starter house that is perfect for your needs now (but which you can build upon later.) In the latter case, you’ve thought briefly about the future, but you’re focused on building the best house for today.

That’s the right way to build out flexibility for the future.

Information Architecture Deliverables: Page Description Diagrams

In the second installment of my Information Architecture Deliverables series, I’m going to talk about one of my favorite (and one of the most tricky) deliverables: the page description diagram. In case you’re not familiar, a page description diagram is a text-based list that explains the importance of content that appears on various pages of a website. Here’s a sample of what one looks like.

One of the main reasons why I love pdd’s is that they effectively remove visual design and layout-based discussions (which should be reserved for the visual design phase of the work) from the IA process. Presenting and discussing only content forces a client to focus on choosing what is and isn’t really important on a given page, helping to communicate their core message.

That said, I’ve found that there are two scenarios in which Page Description Diagrams might not be the best choice. The first occurs with clients who really don’t want to get involved with anything unless it’s visual. For instance, I recently worked with an architecture firm who told me up front that their group was very visual, and that text-only deliverables weren’t going to enable them to provide valuable feedback. For this client, I chose a more visual-based deliverable.

The second scenario occurs when we’re working with web applications or more interactive-type sites, where discussing interactions is key. Interactions are more difficult to portray textually, so Page Description Diagrams often leave important questions unanswered and aren’t the most appropriate for these types of projects.

Aside from these two examples, Page Description Diagrams are an ideal deliverable—especially for content-heavy sites. They’re a great way for the information architect to focus in on the content and its overall importance per page, rather than visual design and layout only.

If you’re not architecting a site with heavy interactivity, I’d highly recommend them as a great way of getting everyone involved and on the same page during the site building process.

Information Architecture Deliverables: Site/Navigation Structure

When I talk about Information Architecture, I don’t want to talk about deliverables. I want to talk about getting people on the same page about what is going to be built or designed. The gist of my job is getting “consensus” (and I don’t mean designing functionality by committee; I mean ensuring that that everyone understands what is going to be built before the development and design happens). Yes, there will always be changes, and yes, agile development can be a great thing. But without some sort of initial blueprint to guide you, the project will flounder around in a visual design and feature development tennis match—on a court without lines or a net. In short, you need a solid plan or you’ll end up with a mess.

So, you need a process for getting people on the same page. In a perfect world a napkin sketch, phone call, and thirty minutes on a write board would be sufficient to give everyone on your project a clear understanding of what’s going to be built, and you’d be ready to move on. But this is a fairy tale. Clearly documenting everything, getting all your stakeholders in the room at once, making time for client feedback, and discussing your work with clients so they see how the site is developing take a lot of time. A whole lot.

Unlike visual design and development, information architecture has a whole slew of deliverables to choose from. Every project has different requirements, so you’ll need a slightly different set of IA deliverables for each one. Whether you’re working with a web application or a more traditional content driven website, for instance, makes a huge difference. And of course, you also have to consider budget and the type of client you’re working with. The problem is that it’s not always clear which deliverables are going to best facilitate getting everyone on the same page. As well, it’s easy to forget that deliverables themselves don’t matter much — it’s understanding that you’re looking for.

I’m going to be writing a series of posts about the deliverables I use and explain why I use them. I’ll begin with one of the most common deliverables, and one I almost always start projects with: the Site/Navigation Structure document.

Traditional content-driven sites and Site/Navigation structures

If you’re not familiar with the Site/Navigation structure document, here’s the gist: It’s basically a set of boxes that outline the general categories, sections, or main navigational items for a site (It is traditionally called a site map). The Site/Navigation structure document is not particularly sexy, but it’s a great way to get people to think in terms of general site navigation and site priorities. It also prompts them to consider the content they have, want and need. I usually try to included the secondary levels of navigation as well (boxes underneath the main navigational boxes) to help provide even more context. I avoid getting into too much cross linking of content, as that tends to get a little more detailed than I want early on in the discussion. In the early stages, I like to focus on main navigational elements and try not to get too bogged down with the details.

One, possibly two rounds of revisions are usually all that’s needed with this deliverable. The beauty of this document is that it’s usually fairly easy to create (although a lot of time is spent looking through content, site, or any additional documents your client has provided) and it’s quick to change. I spend a good amount of time writing up my justification for the site structure with this as well. It’s not a very visual document, so I find it really helps to outline out what I’m thinking in a Basecamp post when I send it over. Depending on the client, I then spend some time either on the phone or reading through their feedback. Then I move on. It’s important not to get too bogged down because remember, it’s a process and these are just being used to document design decisions.

Web applications and Site/Navigation structures

Web applications are a bit trickier when it comes to producing a more page-driven site/navigation structure. I usually try to stick with a similar layout, with larger boxes representing the main navigational elements on the page and smaller boxes underneath representing sub pages. Often, I’ll add in a bit more detail to help show some of the process or interaction happening on some of the interior pages. Without more detail up front here, I find it’s just too general for all that needs to be explained. It’s a bit risky to spend so much time creating and revising initial deliverable like this, but I’ve found that without it, the feedback can be a bit lacking and general.

Overall, the Site/Navigation Structure documents (when done correctly) are a great way to get the conversation going, and of putting a quick but nice-looking deliverable in front of the client. This deliverable also helps make sure that everyone is, for the most part, on the same page before you move on to more specific IA deliverables.

Next up: Page Descriptions Diagrams.

Categories vs. Tags

It might as well be paper or plastic. You step up to the cash register and the checker looks up and asks, “Paper or Plastic?”. If you’re like me, you start over-thinking the question. I’d like to avoid using petroleum products so I should go with paper, but those actually take more energy to produce, but I can use them for my recycling later… Meh, I should just buy some reusable bags and get it over with.

The same types of questions pop into my head when people ask if they should use tags or categories. Tags are easy and quick to add, but they lack the structure and navigability that categories provide. But then, it’s tough to decide which category certain content types belong in.

After far too much internal debate, waffling, and discussion, I know there isn’t one solution I can say is best. But there are a few solid rules you can defer to when thinking about tags and categories, and there’s one solution that I like to use for most of the sites I design.

First, the basics:

1. Tags are metadata about a post. They’re added keywords or a way to add a little bit more description to a piece of content.

2. Categories, on the other hand, are more structural and usually used more for navigation. You put a piece of content into a category. You add a tag to a piece of content.

Over the years, I’ve seen these two types of classification systems used interchangeably, often with one masquerading as the other. People want to put a piece of content in multiple categories to help alleviate some of the problems the rigid structure provides, but the biggest issue I notice with these two is not in the set-up phase — it happens in the day-to-day maintenance of content.

For instance, it’s hard to know what category a piece of content should be placed in. You usually have to go and review the list of categories already on the site, decide if it’s worth putting it in one of those, or maybe even decide to add a new category. If the content is being managed by a multitude of people and there isn’t an agreed upon rule set, things can quickly get out of hand—then you’re left with on-the-fly category creation and a serious navigation problem with your site down the road.

Tags have different problems. They’re easy to add, so you’re not stuck with a lot of mental load while writing or trying to add a piece of content, but they’re not very good at providing navigational structure. There’s no thought that goes into all that attached metadata and the typical way of displaying these tags (a tag cloud) is a messy form of navigation.

So what to do?

The easy option is to go with both: You add tags however you see fit and then put the content in pre-set categories and go on your way. In this case, you reap the rewards of both and your bases are covered. It’s not a bad solution, but like I mentioned before it can be pretty taxing on the content management end of things. Not only are you adding metadata via tags; you’re also having to decide on categories.

For most sites I design, I use a combination of the two, but not both separately. While posting and adding content, I do the easier of the two and just add lots of tags. I then create groups of these tags and make categories based on them. I like to call these groups of tags “sections”.

This way, if I want to have a design “section”, I can add tags like grids, color, layout, painting, sketching, etc. And then all the posts that are tagged with one of those items are placed in the appropriate section. If an article that I think should be in a particular category isn’t there, I either add the tag to the article, or add the tag to the section. It’s the best of both worlds.

It’s easy and quick to add tags while writing or posting and flexible when you’re trying to categorize your content.

But why not just use both?

It’s a good question, with a fairly easy answer: maintenance. Adding more content and tags and putting content into categories can make moving things around later a daunting task. Associating the tags with categories lets you move the content items around more easily and gives your sections meta data as well (the tags that are part of that section).

Bottom line

Like I said at the start, there’s no hard and fast rule for these things. Sometimes a site can work well with either both in unison or the way I described here. In the end you have to take a hard look at how you’re hoping to use these two in both your site’s navigation and your internal content management structure.

Problems, not features

Clients have proposals. They come in all sizes and shapes, from formal RFPs to an idea hastily sketched on a back of a napkin. But there is one thing they all have in common: Requirements. And each of those requirements almost always calls for a feature. Like a blog. Tagging. sIFR. Some AJAX. These days, even a site that sells toothpicks seems to need a rotating AJAX-powered image gallery.

Often times, we web pros spring into action when confronted with this dilemma. We draft estimates, outline how all these “necessary” features might fit within a client’s budget, and use our design and development skills to build something that doesn’t look like a cobbled-together mishmash.

I understand why almost every client requests these intricate features. They see a site that does something they really like. They love how you can zoom in on Google maps or drag and drop things into a shopping cart, for example. It’s easy to make that leap from “they do that” to “we should do that, too.” Unfortunately, it’s also a fundamentally a flawed approach.

Designing for Features

When you’re confronted with a list of features, you immediately lose focus on the bigger picture. You try to accommodate all of this functionality without asking the most important question: Is it really necessary? So often we treat a particular feature set as our final goal. Instead, we should focus on problem solving. Focus on the problems first and the right features will follow.

Wasting Development Resources

Another unfortunate side effect of features-driven design is spending development resources in all the wrong places. Drag and drop may be cool, but “cool” doesn’t solve problems. If you haven’t spent the necessary time dealing with UI/IA design challenges you’re going to waste resources backtracking in the development phase. So draft the blueprints first, and then start building. Or inevitably you’ll end up with…

Scope Creep

Without that initial blueprint it’s far too easy to start tossing in a new feature during the project. Without the reference document, one feature becomes two, two become three, and so on—until you’re not focused on the problem at all. Instead, you’re focused entirely on (you guessed it) more features. But the cycle can easily be stopped if you stick to your initial plan and just say no.

Why Is It So Hard?

The web community loves new features and new technology. New is exciting. New is fun. New is challenging. And when clients come to you wanting something new, their enthusiasm can be really contagious. How many times can you remember hearing someone say “Oh, that’ll be fun!” when he or she learns about some new feature that “needs” to be in a site?

You want to keep your clients engaged in the work, but if they’re attached to a specific feature, convincing them they don’t really need it can be extremely difficult. Often, it feels easier to add that feature than to try to change your clients’ minds. But that’s a trap we all need to avoid.

Avoiding the Trap

• Encourage clients to bring you a list of problems, not features. They’ve hired you to create this website or other web “thing”, and they’re looking for your expertise in solving problems. You were not hired as an expert in bells and whistles-building.

• Listen. After all, clients know their business better then you do. But you know the web. Once you truly understand their problems, you can focus on adding features that really work.

• Use the budget to your advantage. Clients always want a lot for as little as possible. Explain that by focusing on solving problems, they can accomplish their bottom-line objectives for less money and in less time. Additional features can always come later.

• Treat features like a toolbox, not a roadmap. Decide what problems you want to solve, then consult your features tool kit to help you succeed.

The Bottom Line

Features aren’t bad, but being feature-centric is. As web professionals, we should tackle web work with a “problems first, features second” perspective. We’ve all learned how to keep the user at the forefront of our minds. Now we need to learn how to find the right features to solve their problems.