Yes, I do still call it Information Architecture, Part 2, a brief history

I had a chat recently with a long-time colleague and content strategist, Margot Bloomstein. She was doing some writing on IA and wanted to pick my brain about how I use that term and why. I referred her to my blog post and we had a humorous chat that seemed worth expanding on here.

First, a confession: my business card says “Director of User Experience.” Even though I use the term information architect in casual conversion, I do prefer to the term user experience (UX) for formalities. I think user experience as a skill set (and buzz phrase) is gaining traction amongst the people who are in the know. It also helps me separate the hands-on work that I do—the on-the-ground, in-the-trenches wireframing, sitemapping, and usability testing—from the consulting and strategy services I offer my clients. It’s a bit aspirational on my part. I don’t want to draw wireframes forever. (I am still looking for someone to do that work for me, so if you know anybody…) “Director of User Experience” is also a title more often used in a bigger studio or agency, and I like to keep on par with my peers. Mostly it just makes me sound important. And let’s face it, that’s the most important thing when it comes to running a business and selling a project.

There are distinctions among the differing skill sets that a typical user experience designer can offer. The first thing to know is that there is no such thing as a typical UX designer. Not all of us are good at everything, even though we try to be. The technologies change and so does the demand for specialized skills. Before mobile phones and iPads caught on, we were generalists. During the bubble, when demand was high and there was a shortage of skilled people, we wore many hats, playing Web strategist and information architect, consulting and building site maps and wireframes. Sometimes we were also asked to do some light design or, in my case, HTML.

It worked for us and our clients because the skills themselves were closely interrelated when we were creating basic marketing Web sites (aka “brochureware”) that needed clean navigation structures and thoughtful layouts to move our client’s printed brochures onto the Web. When ecommerce caught on, we added interaction design to our tool kit, although at the time it was not interaction design the way we talk about it now. It was more like transactional design. We had to design process flows that were predictable and useable for consumers. But those interactions mostly revolved around user goals like, “I want to buy a book.” Customers wanted to get from point A to point B. There was not a ton of complexity involved. Once the standards were established (add to cart > check out > enter shipping information, yada, yada, yada) and technology packages were created, ecommerce sites popped up overnight, seemingly out of nowhere, without the aid of an information architect. And that worked too.

Next came the portal wave. Content reigned, and our clients needed help reining it in. Their sites exploded with hundreds, sometimes thousands of pages that no one claimed responsibility for. It was like our clients believed the shoemaker’s elves were adding content to their Web sites while they were sleeping. When they woke up and realized they had more content than they knew what to do with, we became serious taxonomists. Our site maps spread across pages and pages and we had to come up with rules around how many levels of content a site could have, mostly determined by how much space we had to display navigation links in an 800 x 600 screen resolution. Design became more sophisticated and so did our wireframe layouts.

At some point, the expectation that we could also be interactive strategists lessened as that role was split out and placed in the hands of strategists, creative directors, and account managers. And then Web technologies evolved. Users started demanding the ability to buy more than books online. They wanted to pay their electric bill and manage their bank accounts. Those demands evolved into a complex Web of software that, when done right, became transparent to users. (Whether you know it or not, you are using software in a Web browser. That’s what us technology people call Web applications. All those sites and pages you use to move money around in your eTrade account or to read and send Gmail is software served to you through a Web browser.) And this is where today’s version of interaction design comes in to play. New technologies made is possible for us to keep you on the same page while we popped up, slid open, and overlaid features to flag messages for follow up, move them into folders, add tags, reply, reply all. All of these functions require thoughtful interaction design. An interaction (IX) designer or a team of IAs, IX designers, graphic designers, and UX designers, got together and figured out if that thing should be a button or a link and what happens when you hover over it and when you click on it. Someone made a decision about every feature and function on the page. Every button. Every link. Everything you see (and lots of things you can’t see).

Today’s version of interaction design more closely resembles traditional human-computer interaction (HCI), a skill set that has been around since the invention of computers, than the information architecture work Web teams did before the introduction of Web application technologies. Some of the IAs on those Web teams had HCI training, which often came with usability testing skills (oh, right…usability…I left that out on purpose. Usability has always been that other thing we do. But usability has always been usability. Neither the skills required for conducting testing nor the methods have evolved a ton over the years. Either you can do it or you can’t.) Some of us were self taught (with the advantage of a background in some science or another like psychology that helped us understand cognition, personality types, and basic research methods). Others came from library sciences backgrounds, and they rocked at building taxonomies and organizing content and interfaces.

Where was I?  Oh yes, interaction design. IAs had to learn Web application design or get left behind. And then the technology changed again. Handheld devices and tablets took off.

Another quick digression first: if any of you have an inkling of the history I’m attempting to relate, you may wonder where the Flash movement fell in all of this. The answer is in the brief history of Web graphic design, which I am not up for tackling. Believe it or not, Flash design was done by Flash designers. Even though Flash was all about the interactions, us interaction design folks were left completely out of these projects. This was great for IAs and designers who had a penchant for Flash. They were allowed, encouraged even, to specialize and the rest of us were left behind. However, if Apple successfully wins the mobile battle against Adobe in the next year or two, Flash designers will be forced to learn HTML 5 or die.

Okay, back to cell phones and tablets: these new technologies, all of which include interfaces (UIs) and Web browsers created two new specialties or sub-specialties. Mobile UI design became its own thing. And in the last two or so years now “app” design has become a whole new thing. The designers who work on these teams need to understand the capabilities and restrictions of each of the devices that serve their interfaces or apps. And the interactions themselves have changed with the creation of touch screen devices. Clicking and dragging no longer means reaching for the mouse. It involves the tactile expression of a finger meeting glass.

It would be tough to find one person who could do all of these things for you well. I’m sure there are a handful of people out there. But for the most part, we are better at some of these things than other things.

To review, here’s a list of all the things I’ve been referring to.

  • Interactive strategy
  • Usability
  • Taxonomies and nomenclature (which is a task sometimes split with a content strategist)
  • Traditional information architecture (site hierarchies and wireframing)
  • Interaction design / Web application design
  • Mobile and handheld user interface design
  • App designers

Here’s the point. All of these skills, jobs, tasks, people, can fall under the umbrella term User Experience Design. I don’t have a problem with that. As I’ve mentioned, I use the phrase myself. But I do think it’s important to call a spade a spade. I mean, duh. I wouldn’t be good at my job if I didn’t consider labels important, right? And so I believe it’s important for anyone who calls herself a user experience designer to specify which of these skills are part of her toolkit.

It’s been roughly 12 years since the Internet Bubble. That’s enough time that the kids who are the heaviest consumers of these technologies don’t know what the Internet Bubble was all about; they were 6. Those of us designing for them can remember life before the internet. (Heck, some of us can remember the world of black and white TV. Gasp.) Nowadays, college students can major in interaction design. But if you ask them about site maps and content hierarchies they’ll look at you like you’ve got two heads. “Content?” They’ll say. “What’s that?” They can’t be bothered to read. They barely use email. And they think you’re a dinosaur if you still use your phone to make phone calls.

So when interviewing a self-proclaimed user experience designer, I want to know what you’re good at. All of the stuff I listed above, you say? Great, but tell me what you’re really good at so I know if you’re a decent IA and a great IX designer or vice versa.

And finally, my conversation with Margot. It’s about calling a spade a spade, or in this case, calling a duck a duck.

Margot: so… here’s my question: i’m writing about IA and want to make sure i’m using it appropriately. i recently saw on your site–you relaunched!–that you hew closely to “IA”–not “UX” or any other newer term. why, and what does it mean?

Sarah: funny you should ask
i wrote a blog post about that recently
http://www.sepmorton.com/?p=49
there are a lot of words and phrases people use

Margot: OOOH! I’ll read it. part 2  is that i’m exploring the issues an IA must wrangle; many are similar to to those encountered by a good PM, like “how long will this take,” “how much should we budget,” “how many pages/screen/modules” … at least in my opinion. are those issues/questions accurate? any you’d add?

[We didn’t really get to part 2 of her questions, but answers to part 1 appear below.]

Sarah: interaction design feels more like web app design or mobile design to me
ia sometimes just feels like taxonomy

Sarah: user experience design covers all that

Margot: hmmm.
so ixd [interaction design] is a connotation difference?

Sarah: i think it depends on the person
but mostly i don’t think clients know the diff
so i still call it IA because i can use my real estate analogy to explain

Margot: hmmm…. in the post, you reference the Bentley program. but where did IAs come from circa 2000? were they just designers who’d gone a less graphic, more organizational route?

Sarah: totally or human-computer interaction people
either self taught or HCI people

Margot: ahhh
ewww… “content architecture”?
i haven’t heard that.
wtf is that.

Sarah: i think it’s some blend of IA taxonomy and site map stuff plus what you do
for people who can’t decide between IA and content strategy as a label

Margot: that’s stupid. we have words for what we do, and people should use them. and what i do is pretty big and complete in and of itself, and what you do is pretty complex and giant too. who has the time or expertise to combine them?

Sarah: good question

Margot: i like turkey, i like duck, but turducken is never going to be as good as both separate foods prepared to accentuate their distinct properties.

Sarah: haha
it could also be for interaction designers who don’t actually know what it means to draw a site map. i think there are a lot of youngsters whose skills may be too specialized
so they expect the content person to draw the site map and voila, you get content architecture

Margot: yeah. i blame turducken.

Sarah: i hear ya :)

Margot: we should just let duck be duck.

Sarah: so long as we can use the duck fat for frying the eggs, i’m in!

And on that note, it’s time for second breakfast. Maybe after lunch we can chat about guided navigation, faceted search, content management systems, and blogs.