What IS an Information Architect, anyway?

Everyone’s been at a party (or the dentist, or the in-laws) and been asked “What do you do?”. Most people have a nice clean answer: accountant, fireman, lawyer, etc. If you answer that immortal question with “Information Architect” you can expect a quizzical expression rapidly followed by a polite smile. “Ohhhh,” they say, pausing for a moment. “So what IS that?”.

I think the best answer I have ever come up with is: “I’m like a regular architect, except for websites”. An information architect, at least in the context of digital user experience, is quite analogous to the real-world, residential or commercial architect. Except for the math. An information architect or user experience designer (IA/UX) is primarily responsible for creating the specifications for web sites. Sounds simple, right? Well, not really…

Like a “real” architect, the IA/UX consultant is primarily engaged with the client or business group to divine and document what the client really wants and needs, long before the actual wireframes (the web equivalent of an architect’s blueprints) are drafted. The process of creating a truly usable and functional site (or module, or even a single page) that also fulfills the business/client objectives begins with discussion.

Typically, I will meet with client groups at least several times and gather as much documentation on what client’s have envisioned, and what they have allowed for in terms of budget and time.  This process can take hours, or weeks, depending on the scope of the proposed project, as well as the amount of work that has already been done. Typically clients will come to me with some drafted requirements (these can be as simple as the proverbial bar napkin sketch or as complex as a multiple page requirements document that captures the complete requirements picture). From this point, we discuss the objectives and put together some basic elements of IA, such as site maps, user flows, possibly even user personas and expected user behaviours. Out of these basic building blocks, and agreed principles, we begin to build wireframes.

Working from a sitemap that typically evolves throughout the IA process, the UX designer will begin to build out the individual pages that make up the sitemap and will eventually be transformed into web pages for real users. Wireframes are intentionally simplified (though often highly detailed) representations of the user interfaces that will eventually be created. Like architectural blueprints, wireframes detail all of the elements of page, from the basic alignment of elements to the complex presentation of data and content in ways that appear simple and easy-to-use for the end user. In the case of more complex web applications, wireframes are often complemented by process flowcharts that detail how users will progress through complex functionality and what options will be available to them, etc.

While we are working through the wireframes, the client will be able to get a very concrete idea of what is being proposed, and what they can expect to see in the final product. They will also have the opportunity to amend their plans, and perfect their solutions to design problems, during this process. In many ways, that is the purpose of the process – it’s much easier to change the design on paper (whether it is digital “paper” in the case of wireframes or actual architectural blueprints) than it is to change the final product. This is obviously true in terms of bricks and mortar, but it is equally important (if a bit more obscure) in the digital space. To rework an existing site is often as complex as trying to redesign a car after it comes off the factory line. Much better (and cheaper, and more effective) to rework the designs and prototypes than the car itself (if you will pardon the slightly mixed metaphor).

So, in a sense, this is what the IA/UX consultant does – creates that space for discussion and documentation, specification and revision, that will hopefully lead to a better, more functional and usable final product. The end result of all of this discussion is a highly detailed set of visual and verbal plans and specifications that can then be passed on complete to interface designers and developers, programmers and QA testers. It’s a fun and immensely rewarding process for all involved (if done properly), and in my experience it always leads to better results.

2 Comments

  1. Looks like you are an expert in this field, you got some great points there, but you’ll want to add a facebook button to your blog. I just bookmarked this article, although I had to complete it manually. Simply my $.02 🙂

    – Daniel

    1. Thanks Daniel – great suggestion. I am not quite ready to publicize this blog just yet, but I will definitely take your advice when it is ready for prime time. Thanks for reading!

      AjW

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s