What the hell is an information architect? | Hacker News Reader

What the hell is an information architect?

blog.controlgroup.com

23 pointsminpinterest16 comments

Here's what the information architect component of a recent project at my firm involved for a major non-profit organization that needed to redesign a site that had not been touched since 2007:

1 - Document and structure the current site map in all its depth and unorganized glory. With over 50+ sections, 75 contributors, and 150,000+ pages, this content inventory was vital to communicate to the client what the current site architecture looked liked.

2 - Consolidate the architecture of the site. We began by overlaying analytics data on the site map to figure out the most popular sections and pages. This led to a series of conversations and recommendations on what to cut and why.

3 - We coupled the analytics data with user research and business requirements to come up with a new site map/site architecture [1]. This site map included renaming wholesale sections, adding new sections to the site based on what users want, and in general, making sure we were as logical as the client would allow us when designing the new site map.

4 - Once the initial site map was put together, we validated this by using TreeJack, a great IA and wayfinding testing tool. Read more about TreeJack on their site to learn what and why this tool is useful.[2]

5 - We iterated on the site map based on TreeJack findings

6 - Once the initial site map and labeling were locked down, then we began discussions on page archetypes and templates. At no point did we sketch or draw UI designs. These discussions were all about the purpose of each section, the user goals they'd satisfy, and what type of content may live on each page.

7 - Once we had the archetypes down and some agreement on the number of sections and templates, then we moved to the wireframing and UI sketching phase.

Obviously, this is just 1 example, and is by no means thorough. But, you'll hopefully realize that the role of an "IA" is absolutely vital for complex projects.

When it comes to building web applications, the IA work we do is different, the artifacts we create are different, but the end goal is still the same, and attempt to organize, simplify, and improve usability.

[1] http://viget.com/inspire/ux-101-the-site-map

[2] http://www.optimalworkshop.com/treejack.htm

I'm wondering if this posting is a practical joke of some sort. The post linked to here is so dense with vocabulary, yet somehow lacks any meaningful content.

I kept reading only to see if there was a punchline at the bottom. Something to the effect of: "See? All that crap written above really cries out for some information architecture, doesn't it?"

>> so dense with vocabulary, yet somehow lacks any meaningful content

Sounds to me like you learned a lot about typical information architecture :)

Agreed. "When trying to articulate what it is I do, I find that I default to an older arsenal of terminology to qualify what is actually a fairly simple vocation, built on an assortment of superficial qualifications and reliant on a heavy interaction with a cloud of specialized UX disciplines." Huh?

This person clearly has a difficult time explaining basic concepts (not exactly a trait I'd look for in an IA).

My first thought on reading this: get to the point!

If I were hiring an IA, I think writing an essay with the title of the post might not be a bad starting point.

This post is very difficult to understand, so here's my attempt at a simpler explanation. At some point in a project, somebody has to sit down, read through all the content and organize it. They have to gather all the information from the various groups involved and define how to logically break it down into separate pages. The define how users should navigate between them, what type of navigation is needed, etc. All decisions have to consider the various business, strategic and user goals, technical requirements, etc.

These tasks have to be done at some point, and if there's no information architect, then somebody else has to do it (designer, developer, PM, etc). That's no problem for small projects, but it gets messy for large portals or big corporations where many stakeholders are involved.

In other words it's some kind of bureaucrat or something?

The article "Top 10 Information Architecture Mistakes" by Jakob Nielsen from 2009

http://www.useit.com/alertbox/ia-mistakes.html

has a lot of good tips for website builders to consider to make their sites more appealing to users. Keeping information architecture in mind is especially useful for any website that is trying to sell goods or services to the general public.

Translation:

"I have a lot of varied skills. I studied art and languages. I organize and prioritize information.

"We build web sites. We strive for good user interface. The information architect architects information. Information architects do everything."

What a total BS piece.

In my experience, an information architect is someone who creates wireframes (poorly), creates user interfaces (poorly), uses photoshop and illustrator as their primary tools (poorly), and writes HTML and CSS (poorly).

It's a garbage title for the in-between between designers and engineering and project management that doesn't have the skill of a designer or a programmer or a project manager but tries to give input on the jobs of all three. It's the glue role for the person who was willing to put in insane hours at a service oriented 'startup' that will never exit the startup phase (because that's not what labor intensive service oriented companies do).

I've worked with a couple of good people who would style themselves "information architect". In my experience they do pretty well understanding the whole "lifecycle" of the information and help optimize information flow between various parts of a business. They shine well when there are multiple places data lives, and when there are many uses for shared information. Then they are good at figuring out where data lives, what is important for just an app or subset of apps, and when that information is a global requirement. They aren't DBAs, but they seem like it sometimes. They can figure out where there is bad duplication, where duplication makes everyone's life easeir, an when to use what representation for something. Basically a good IA can help ensure that your data flows well.

Programmers have a tendency to optimize the data architecture towards their specific project, while IAs optimize it between various business units. This does create a tension sometimes, but a good IA goes a long way to smoothing that.

That's the traditional role of information architect, which doesn't seem to be what this blog post is describing.

> and help optimize information flow between various parts of a business.

Yes, they're go-betweens. I don't think this was meant to imply that IAs can't be good at what they do. There are plenty of great HR people.

I think the point was that the job of IA is similarly useless, and just like I don't think anyone has ever said "Oh thank the FSM, we have another HR analyst," I don't think anyone has every said "We finally have an information architect!"

> they aren't DBAs, but they seem like it sometimes.

I think that goes right along with the comment of doing several things poorly and nothing well.

It sounds like you've worked with, at best, mediocre user experience designers. In my experience, a good IA never creates wireframes or comps. They rely on data (or testing when no data exists) to make meaningful associations and groupings of content. They use those learnings to help the uxd rationalize placements and flow through a ui. They work with content strategists and copy writers to maintain that structure as the site or application matures.

A good IA is really tough to find, and it's disappointing to hear engineers undervalue that role. It's typical from clients, but engineers I know that have worked with a good IA turn into advocates going forward.

And no, I'm not in UX.

I met the IA at CSX who is responsible for building their positive train control system mandated after the CSX 8888 incident. We sat next to each other often on our commute from Marine barracks in Okinawa to the planning center for Fukushima. Sounds like trying to design something roughly as complex as designing an automobile, with plenty of prior art in metallurgy, materials, and basic machinery (bearings, screws), but having never seen a vehicle with 4 wheels before.

http://en.wikipedia.org/wiki/Positive_train_control

http://en.wikipedia.org/wiki/CSX_8888_incident

An information architect is very similar to a product manager.

They have expertise in information systems, but are essentially performing a product mgr role in being the expert on what you're building, and who you're building it for. In many internet businesses, information is the product.

Info architects also cop the same criticism and praise as product managers. Jack of all trades, master of none. Not a critical hire because their role can be covered by others. But good ones can make a real difference to the process and the final product.

tl;dr: An information architect is a librarian for the internet.

As with every position in every industry, you'll come across good, mediocre and bad people filling the role of an information architect.

Info-architects should not produce code, specs, interaction design or anything visual beyond a high-level site map. And they should not be asked to do so unless they can write production code, produce visual design or architect the full user experience, something most cannot do.

Their role is to understand what information the system is receiving, analyzing and transmitting, how the information relates to itself and how that information should be best organized and disseminated in order to meet business requirements.

If you meet one who knows their shit, cozy up and learn as much as you can because it's been my experience that many of the root causes of adoption failure lie in the engineer's inability to properly organize, relate and disseminate information to the user. Not scale, not coding skills, not lack of design.

Reply on news.ycombinator.com