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.
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.
A set of magnets with UI widgets on them that you can use to prototype various apps on either a metal whiteboard or, you know, your fridge. An absolutely fantastic idea.
“Personally I feel I no longer have anything to share with the so-called graphic design of today: not the concept, not the typefaces, not the layout—nothing. Therefore, I conclude that I am no longer a graphic designer, but an information architect, and from now on that is how I will describe the meaning of my work and the scope of my activity. For me, to be an information architect means to organize information in a way that is essentially retrievable, understandable, visually captivating, emotionally involving, and easily identifiable. Information should be semantically rooted, syntactically correct, pragmatically efficient. It doesn’t work otherwise.” - Massimo Vignelli Again, I’m not interested in the semantic debate about this but I like the sentiment.
“More interesting, you can architect a business model or a pricing structure to make it far more effective at generating the behavior you’re looking for. Most broken websites aren’t broken because they violate common laws of good design. They’re broken because their architecture is all wrong. There’s no strategy in place.” The semantics of Information Architect, Designer, Visual Designer, Interaction Designer, etc. don’t really interest me anymore, but I do agree with Jeff’s commentary about educating the public more about what’s happening behind the scenes “design” and in particular web design. It’d be fantastic if clients knew even just a little more about what goes into creating a great website. It would sure make my job a lot easier.
I got to be heavily involved with Blue Flavor in the site/navigation structure for the new SXSW.com, and I’m really stoked with how it came out. Well done Shawn and Hugh with getting it all implemented so quickly. Looking forward to seeing more of our suggestions implemented.
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.
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.
A great stencil resource from the Yahoo! Design Pattern Library. I plan on field testing these on my next project.
“Occasionally someone would notice his value to a project, but instead of giving him the care he deserved, they’d just fork over copious amounts of cash to ship him off to his sketchy uncle SEO, who tied him up and fed him keywords all day long.”
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.
A great resource. I really like the trend toward more “speaking” block navigation. It’s not perfect for all situations but it’s incredibly effective how it gives users even more information about what’s behind the link.
Videos of presentations from Interaction 08. Now I just need to find the time to watch a few of them…
These look like they could be really useful.
“This guide offers researched and tested best practices for developing successful member station joint-licensee and TV-only Web sites.”
Part of the iSchool at University of Washington.
UX Week Presentation by Marc Rettig, Aradhana Goel
Session notes