

What the hell is an information architect? - minpinterest
http://blog.controlgroup.com/2012/06/25/so-whats-an-information-architect/

======
ahmadss
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>

------
peteysd
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?"

~~~
adjustafresh
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).

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

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

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

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

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

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

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

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

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

