T Incorporated: Latest blog entries

A New Canvas

Tom Watson — Mon, 18 Jan 2010 16:05:54 -0800

Fever pitch would best describe the current rumor and excitement level going on right now about the new Apple Tablet/Slate/flat-thing-a-ma-bob that’s set to be announced on January 27th. I’m excited about it sure, a touch skeptical that it’ll be a huge game changer, but a big part of me really hopes it is.

I’m sure the hardware is going to be sexy, I’m confident Apple is going to come up with a way to do some sort of text entry, maybe not for your next novel, but it’ll work. If this sucker is wildly successful and sells like hotcakes, what gets me excited is that there’s going to be a new way to design digital content.

This new Apple device, in addition to whatever else they may be planning, could create a new ecosystem that gives people a reason to purchase periodical type content again. To spend a little extra for something exclusive, for the video and the audio additions, but also because it’s designed better.

Why would people want this?

It’s two simple words—premium content. Think HBO or Showtime. The Wall Street Journal has been able to carve out a nice little niche on the web too. The problem is people think of that content as free, and it works well that way.

That said, I miss reading the newspaper and beautifully laid out magazines, something a bit more researched and without that feel that I need to click the next item in my feed reader. I don’t want to deal with the hassle of an actual paper or the environmental impact of all that waste.

I want the best of both worlds. Beautifully laid out content, complete with audio and video, but delivered to me automatically on a device that’s designed to read on. Not something that’s already has too many alerts and notifications to pull me away from reading, watching or listening.

What makes this different then just a fancy website?

First, just go check out this Mag+ concept by Bonnier R&D. Still not convinced?

With a device like this, the content would be designed to be consumed on that specific device size (whatever it is) and not have to worry about fixed vs. fluid layouts and IE6 like designers have to do on the web. It could have full CSS3 support, no cross browser javascript woes and a much larger set of native type to choose from pre-loaded on the device.

Best of all, all the web designers out there would already know how to build for it because the content that will be produced for this new device will use HTML/CSS/Javascript and wouldn’t require them to learn Objective-C. Sure, it’ll probably offer the ability for developers to write apps in that too, but I’m talking about the designers formatting the content to be consumed on the device.

And then, the big one, getting paid for your content directly instead of relying on advertising with some sort of subscription model that’s built right into iTunes where Apple is already storing credit cards.

Why would content producers want this?

Clearly the big newspapers are struggling, hell they whole media industry is struggling to sustain themselves on the internet. If Apple is able to change the game, this might help give them a revenue model they’ve been searching for since they haven’t been able to come up with something better than drowning their sites with ads. Of course, Apple wouldn’t be opposed to taking a cut to provide a new model they haven’t been able to come up with yet.

In the end, I’m less concerned about all the specifications of the new device and more excited about the potential it can offer designers. Better tools and a canvas for richer experiences, a revenue model that gives content producers a better way to create and consumers higher quality, beautiful content.

Unfounded Anger

Tom Watson — Wed, 04 Nov 2009 11:06:03 -0800

In the design community there often seems to be this need, or this want to immediately critique a design. Critique might be too kind of a word, it’s more of a hate on a design. To immediately call something out as terrible, wrong, ridiculous, stupid or just plain dumb. In offices I’ve worked in I often hear people immediately yell out that something is “clowntown” or laugh about how terrible a design is or how horrendous a drop shadow might be.

It’s not just limited to the office, online people are abhorring some new redesign, or how some small design tweak on a site is ruining everything.

This makes me sad.

It’s also not helpful to the community or design in general. I’ve been trying to figure out why web designers as group do this so often. My hypotheses so far:

Immaturity. Our profession is still very, very young and people in it our often very young. Few have had formal design training, and even fewer in a university setting and the ones that have often aren’t the really talented web designers out there. Our profession is so new that the pioneers didn’t have classes to take, and so haven’t had any formal training. Which, in turn, means they haven’t spent much time in any formal critique settings. Critiquing when the end result is positive is fantastic and a critical piece of the design process, but calling something out as stupid just because you’re angry isn’t.
Speed of delivery. Twitter, Facebook and blogging all give us the tools to immediately call someone out and blast it to 100, 1,000 or even 10,000+ people in just a few seconds. The speed at which you can say something is shocking so take a little more time to be clear.
A desire to seem intelligent or thoughtful about design. It’s the thinking that if you talk louder than the person next to you you’re going to come off smarter than the next guy. I don’t think most people do this consciously, but designers want their voices heard and they want to prove that they know what they’re talking about. It’s quicker to hate on a design picking out all the little things that should have been done than to just do something great yourself.

To be clear, it’s not actual design critique that’s a problem, it’s the quick comments and tweets that do more harm than good. I just don’t see how sending out hasty rants and complaints help us as a community create better designs. We’re just coming off as whiny and not solving any problems.

Instead we should be raising the level of debate in our community to produce and talk about designs at a higher level.

How can we do this?

Tweak before you speak. Just a small rephrasing of a remark about some new redesign can make a huge difference. Turn “OMG what the hell were they thinking with this site. Total fucking clowntown!” into something like “Looks like they missed their audience completely site feels bland a bit undersaturated and the type just doesn’t quite fit.”
Know your radius. You’ve got 20,000 followers, know that you’re going to blast a huge amount of people who respect your point of view. Be sure you’re clear and aren’t firing off without considering the impact it’ll have to the community.
Stop loving the sensational. Our community loves to jump on the bandwagon of something sensational. When Jason Fried publicly rails on Get Satisfaction or Merlin Mann’s enraged about Twit Shirt or John Gruber writes about the Apple’s app store people love to pile on. We place too much emphasis on the negative, the sensational, the bad, and not on conversations that help everyone get better. Imagine what great work people would be doing if they weren’t a bit afraid of the community jumping out and hating on them for something. Imagine if all of these “followers” were creators. Instead of getting caught up in the next mob lynching, they were busy creating something they truly love for us all to use.

I’m not looking to be a hall monitor, or suggesting that people shouldn’t be angry from time to time, but right now, at this stage in web design’s evolution, we’ve swung too far away from a positive discussion.

Let’s raise the level of debate and critique across the web, not just to be nice or to feel good about design, but because in the end it’ll produce better design by everyone.

Application Keyboard Shortcuts for Mail.app

Tom Watson — Thu, 01 Oct 2009 09:39:17 -0800

I like to archive mail instead of deleting it. Gmail brought this into vogue a few years back and with their unlimited storage it’s almost silly to delete anything but a few spam messages and the most mundane emails. The problem is I also like to use Mail.app as my email client. So in order for me to archive email I’ve had to drag every message into Gmail’s All Mail folder.

It’s a surprisingly slow process and I don’t even want to think about how much time I’ve wasted doing it. It’s also prone to error. I often find messages accidentally moved to the wrong folder.

So, in an attempt to fix this, I spent a few minutes yesterday trying to figure out how to setup a few quick keyboard shortcuts. I remembered reading that 10.6 made this whole process a lot easier and figured I’d give it a shot. I’ve heard of third party applications, or hacks that could do something like this but those things aren’t for me, if it’s not simple and built into the operating system I’m just likely not going to bother. Luckily it’s dead simple, and I’ve been loving it ever since.

Here’s how to do it:

Open up System Preferences > Keyboard > Keyboard Shortcuts
Select Application Shortcuts in the left hand menu
Click the + button and choose the application you want, which in this case is Mail
Type the exact name of the folder you want to move the selected message to when you invoke the keyboard command. For archiving messages in in your Gmail account you’ll want to type All Mail.
Choose the keyboard combination you like I went with command-return but it’s up to you.

It’s just that simple. You can setup these shortcuts for any other menu items and across as many different applications as you want. I’ve always liked the idea of keyboard shortcuts, but until now they’ve always been too much work to setup or learn. With this new preference pane you can choose whatever key combination want them to be and they’re incredibly simple to create. Kudos to Apple for getting this right.

“Get busy living, or get busy dying”

Tom Watson — Mon, 28 Sep 2009 10:48:54 -0800

When I hear people tell me:

“What camera should I get to take better pictures?”

Or:

“How do people find the time to write?”

Or my personal favorite:

“If I only had the time…”

It drives me crazy. These are all just essentially excuses for the same problem. Just do it already.

It’s not about the camera, it’s about using it. It’s not about finding the time to write, it’s about sitting down and doing it. It’s not about having time, it’s about making time.

Cans & Glass

Time is a finite resource. It’s so damn cliche to say, but as I approach my 29th birthday and am surrounded by 22 and 23 year olds who are incredibly smart, talented and accomplished it’s even more apparent. Just decide what you want to do and work you ass off doing it. Putting something off or waiting until later isn’t going to get it done.

Stop, or at the very least reduce, the re-blogging, re-tweeting, re-sharing, regurgitation and make something. Produce content. Create a great design, dust off that camera and start taking photos or close that browser and start writing.

Because trust me, there are plenty of people out there sharing. Do something different…

Make something.

Outliers

Tom Watson — Sun, 20 Sep 2009 21:12:05 -0800

Last week I attended a day of the UX Week conference and was lucky enough to listen to a talk from Bernhard Seefeld and Elizabeth Windram from the Google Maps team. During their talk they mentioned something that perked my interest. It didn’t sound like the same old, same old when I hear people talk about user experience.

They design for the power user.

Now they backpedaled a bit later when they started talking about how they design for the power user without the expense of the novice or new user, but it got me thinking about one of my favorite topics—outliers.

Mainly because I am one. For those who don’t know: I’m tall—6‘9” tall. The world isn’t built for someone like me.

I spent a whole weekend sitting in 30+ cars just to find one I fit in. It became immediately clear which car companies designed their interiors for an outlier like myself. Ford, Honda and Toyota didn’t even have a car on their lot that I fit in comfortably. I ended up with a Volvo C30 a small two door hatchback. Which, when I tell people usually returns a surprised look, and a quick,

“You fit in that thing?”

C30

Yep. The size of the car has little to do with it. It comes down to basic combination of dash/steering column layout and seat positioning. It’s inherently a design problem. Volvo was thinking of an outlier (myself) without sacrificing quality for everyone else. In fact, it’s a better design because of it. It’s not just that there’s more space for me, but they took the extra time on all the little things in the interior. There’s a floating console and a nearly clutter free dash. To be honest, I have no idea if by Volvo making their dash work for me truly caused these other design details of the interior to be better, but I’ve designed enough to be willing to bet it did. Their focus on making enough leg and head room for those like me spilled over into their design process as a whole.

It’s this focus on these outliers that make a design truly great. Making sure things are accessible for the blind or the deaf, adding in keyboard shortcuts so that it’s easier to browse through photos, or making that navigation highlight look clearer so a user doesn’t get lost.

Now these things on their own are valuable, but the collateral benefits are why you should do them. If you were designing a car, worrying about extra leg room might make you rethink the entire console. Making a design polished isn’t achieved by making it work for your mom or the average user. You end up with something average.

Make a design truly great for the outliers and you make the experience great for everyone.

Go big or go home

Tom Watson — Mon, 14 Sep 2009 17:23:35 -0800

Welcome to a bigger, clearer, and a fresh new design of T Incorporated. My friend Mike Davidson likes to call this T Incorporated bad vision edition. I wouldn’t go quite that far, but with this redesign I pushed myself to really go big and bring the content forward. I wanted to stop hiding behind all of the meta data of my old design and push to have my work front and center. With my first iteration of T Incorporated a few years back, I was so excited to show all of the various information about the data I was pulling in. As a result the content itself started to get lost in the shuffle. I became far to enamored with what I could do instead of what I wanted to be presenting or letting the content stand on its own.

This design is a response to that but in the end I wanted to address a few main things:

Make the site easier to read and hopefully encourage myself to write more
Give myself more flexibility with the posts themselves. I often found I wanted to put a large photo in a post but the previous design didn’t allow it.
Simplify without blindly removing valuable content or meta-data
Highlight the photos even more by putting them on a dark background

This has been a nights and weekends project for a few months now, today was just time to launch it and move on. Designing for myself is such a difficult process, and in the end, just launching it is often the hardest part. There’s plenty of little things that I quite like with the design. The large photos on the dark background, the photo crop in the stream, as well as the stream itself and the large icons that denote the various sections. I also pushed my javascript skills a bit and you can now use the arrow keys (in Safari only for now) to flip through photos, posts, the stream, etc. It’s a hidden feature but one I absolutely love for myself.

The design is still powered by Django, bringing in my content via API’s from Flickr, Twitter, Delicious and others (hopefully Facebook someday here soon).

It’s not a massive shift, but one that pays homage to the old design while prioritizing the content first.

As always, I’d love to hear what people think!

Going, going, back, back to Cali, Cali

Tom Watson — Wed, 29 Apr 2009 08:32:15 -0800

It’s with some sadness and a whole lot of excitement that I’m announcing I’ll be leaving Blue Flavor and going to work at Facebook as a Product Designer. I’m sad to be leaving a great group of friends and co-workers, but excited for the opportunity to work for such an smart, talented group of people working on such a well known and widely distributed product.

Everyone I met both during the interview process had a palpable passion for the product that was both humbling and inspiring. One thing is clear, people love working at Facebook and they truly believe in the product.

I’m also excited to be moving away from client work for a while. Over the past two and a half years, I’ve enjoyed the diversity and challenges that come from working on a constant stream of different client projects, but I’m ready to change it up and really dive into a single product for a while. I’m looking forward to the being part of a team where the focus is the same, making Facebook better.

It’s going to be tough to leave Seattle, but since I’m planning on moving to San Francisco and doing the Caltrain commute I’ve got plenty of friends down there to help make the move easier. I’m not leaving for a few weeks though, so for everyone in Seattle, let’s hang out, grab a few drinks or just have some caramels.

For those of you who know me well, I realize there’s a bit of irony in all this since for years I’ve long resisted even joining the service. In the end though, I’d rather spend my time trying to help improve a site that impacts a mind-boggling 200 million plus users than to spend my time complaining from the sidelines. There are few, if any sites, that have the challenges they do, and I can’t wait to help solve them.

It’s always tough to say goodbye to a job you’ve loved and a group of people you respect and admire, but it was time to move on. I just feel lucky that it’s with this opportunity to help improve both the product and brand of Facebook through something I love to do so much — design.

Level & Tap

Tom Watson — Wed, 22 Apr 2009 07:09:23 -0800

I love photography and I love it printed.

Originally, I started Level & Tap as a fun way to sell a few of my prints online, but shortly after I launched it I realized I couldn’t post enough photos to have people keep coming back to the site. There’s only so many of my photos I felt would look good printed, and I wanted to keep the quality of the site high.

Level & Tap

It was quickly apparent that the best way to solve that problem would be to start bringing in other photographers to help them easily sell their own photos.

So, over the past month I’ve been spending a lot of my free time retooling the site, talking to other fantastic photographers, and working with my good friend Laura Brunow Miner to get the new site launched. She’s been unbelievably helpful in talking with some incredible photographers and is curating the first, of hopefully many series for the site, Transition.

I’m really excited about the site and the potential exposure for all photographers to sell their work. Level & Tap is now a gallery for photography prints currated by some of my friends and me. I’m hopeful that people will see the value in their work, purchase their prints, or subscribe to the feeds and Twitter accounts to check in on the new photos being added.

The site is built with Savoy, Jeff Croft’s yet to be released open source set of Django apps. Using it, I’m able to easily currate photos from various photographers and offer them as prints. Once they are on the site it’s just a simple bit of PayPal integration and the purchase is complete. I still have to process each order manually, but if things start to grow, I’m hoping for some API integration with a printer later. Right now, I’m using Mpix and couldn’t be happier with their quality, but they currently don’t offer a way for me to integrate directly with thier site.

If you’re interested in buying a few prints, just head on over and start browsing. If you’re a photographer and would like to have your photos listed on the site let me know over on the contact form, or request an invitation to the Level & Tap Flickr group. Just be sure to read the submission guidelines to make sure you’re able to list your photos.

Polaroid Breakfast

Tom Watson — Tue, 10 Feb 2009 11:11:32 -0800

For those of you who missed it last year, a few of us are getting together at Katzs Deli for the 2nd annual Polaroid Breakfast. Last year I wasn’t able to make it do to an airport security snafu but this year, unless the weather or security have it out for me again, I plan to be there.

The day's haul

We’ll be talking about all things Polaroid, from the recently announced The Impossible Project to what filters you might be using or where you’ve still been able to find some film. It should be a good times had by all, but mostly it’s just a chance to get together and meet up with other instant film fans.

You don’t need a camera, just an interest and a working alarm clock to get there by 9:00 a.m.

The details:

Where: Katz’s Deli
When: 9:00 a.m. Saturday, March 14th

I don’t have any reservations as it’s meant to just be a small gathering, but there’s been a lot more interest over the past year, so if you could just RSVP in the comments below in case I end up needing to give them a heads up.

More ideas, more problems

Tom Watson — Thu, 15 Jan 2009 10:37:22 -0800

In the past few years I’ve grown increasingly frustrated with the “idea people”. People who are constantly coming up with new ideas, or the concept that the more ideas you have the better off you’ll be. Their view is that the better ideas are the new ones. Three old ideas were alright, but this new, great, special idea is the real ticket. That’s bullshit.

New ideas, truly original, invigorating ones are rare, ones that you can act on are even rarer and the ones that you’re willing to put the time and effort into are even rarer than that. Ones that you’re going to be passionate enough to see through until the end, to do what it takes to make them a success are even rarer than the rarest. I’m tired of ideas. I’m not tired of innovation or new things, but innovation comes with actually doing it. I’m tired of ideas perpetuating new ideas, and throwing out the old ones for the new ones, even though you never even started, let alone finished the old one.

A few months back IBM was running what I thought was a great ad campaign that poked fun at this concept. My favorite, ideating, is a perfect example of this. It’s a whole room of white t-shirt wearing office workers who are all laying there trying to come up with the next big thing, or a better way to handle their process. At the end in bold lettering it just says “stop talking, start doing”. Exactly. What’s the point of all that “ideating” if nothing ever gets done?

Ideas, even modest ones, even projects that happen on the web, take time, hard work, and lots of effort to become a reality. When you’re just sitting at home online, browsing websites, seeing the next project launch, it’s hard not to think that it just happened as quick. You easily forget how difficult it is to launch something, to finish something.

I wish more people talked about actually doing, talked about grinding out the details, building something they’re proud of, getting it done. Finishing. I’m guessing they’re all just too busy doing the work, instead of the people who have plenty of time to talk about all their ideas.

Following through isn’t glamorous. Coming up with an idea is. Being the person with the big brush strokes, the “idea guy”, may seem so, but in the end, it’s just a lot of hot air and hand waving. Idea guys just want to be told how right they are, they don’t want to do the grunt work it takes to get something done.

Seeing a project launch, finish, a client happy, the site up, functioning, results, those things, those things make me smile.

Creating a Polaroid wall

Tom Watson — Mon, 29 Dec 2008 17:11:10 -0800

Last week, with the snow storm in Seattle I was able to slip out to the art supply store down the street and picked up some stuff to fix my polaroid wall I put up back in May. It was quick and easy, just some plastic flashing and some spray adhesive, but after the warm summer and the weight from the Polaroids the flashing started to peel away from the wall. I’d been wanting to replace it with something else but just didn’t have the time, or any ideas on what to put up there in its place. I loved the flexibility to be able to put up and replace whatever photos I wanted or recently taken, but obviously the current setup wasn’t working. I thought about following Mark Bixby’s lead and doing something with scrap steel and magnets, but I didn’t really like the little magnet dots and didn’t have any scrap steel lying around.

Polaroid wall

Luckily, a few months ago my crafty neighbor and architect stopped by and had an idea using some bass wood and some push pins. I loved the idea, but of course work and life got in the way. Fortunately, the snow left me no excuse but to just sit down and do it. I ended up modifying his concept a bit, and am more than happy with the results. I wanted to make sure and document it here just in case someone else is looking for to do something similar. In the end it only took me a few hours it get it all setup, which included about an hour’s worth of scrubbing my walls to get rid of the spray adhesive I’d used on my first failed attempt.

What you’ll need

X 1/16 in. x 1 in. Bass wood
X 1/16 in. x 1/8 in. Bass wood
1 pack of 1/2 in. Wire nails
Glue (I used Sobo craft glue but I’m pretty sure any glue that works on wood would work fine)
Polaroids

Since the bass wood lengths and number of them don’t matter the actual number of strips you’ll need is flexible. The ones I found at the art supply store down the street were 24 in. in length.

Directions

Measure 5/8 in. down from the top of the 1 in. strip and mark each side. This gives makes the visible portion of the polaroid an almost exactly square frame but leaves just a little extra white space to be visually pleasing. It also gives the polaroid enough support so it doesn’t flop forward. Apply the glue to the 1/8 in. strip (I just used my finger) and line up each end to the marks on the 1 in. strip. I just eyeballed keeping this straight but you could mark a line down the back of the piece of wood. Let dry.

Fig. 1 Polaroid wall cross section

When attaching them to the wall just hammer the wire nails through both the 1/8 in. and the 1 in. piece of wood and then the wall. See fig. 1 to see how it all lines up. The first few I did I ended up going a bit to close to the end and they split the 1/8 in. strip a bit as you can see in the photo they still work fine, just but be a bit careful.

They’ve held up great, there’s no messy adhesive on my walls and the photos aren’t bowed out like they were on my previous version.

Design for Now

Tom Watson — Mon, 15 Sep 2008 21:52:07 -0800

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.

This article was originally posted to the Blue Flavor blog, so please direct your comments and discussion over there and we’ll talk.

Information Architecture Deliverables: Page Description Diagrams

Tom Watson — Fri, 29 Aug 2008 15:42:28 -0800

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.

This article was originally posted to the Blue Flavor blog, so please direct your comments and discussion over there and we’ll talk.

Information Architecture Deliverables: Site/Navigation Structure

Tom Watson — Tue, 29 Jul 2008 14:47:14 -0800

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.

This article was originally posted to the Blue Flavor blog, so please direct your comments and discussion over there and we’ll talk.

Categories vs. Tags

Tom Watson — Tue, 15 Jul 2008 09:42:47 -0800

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.

Record crates

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:

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.
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.

This article was originally posted to the Blue Flavor blog, so please direct your comments and discussion over there and we’ll talk.