It turns out that I have done information architecture for some time now, but I never knew it.

A young acquaintance is learning HTML, CSS and such.  I gave him Steve Krug’s classic handbook, Don’t Make Me Think.  My young friend banged through the book in a day, and his cup running over, started going on about this, that, and the other, including at one point, ‘tabbed pages‘.  After some confusion, I realized he was referring to a web page whose content was organized with tabs,

 

rather than the tabs that most modern browsers offer.

Unaccountably, the ‘tabbed pages’ triggered a thought that had not occurred to me before – the ‘tabbed page’ represents at least three different kinds of knowledge.

The users’ needs

Tabs in a web page exist for a reason.  They serve a purpose.   Someone devised them to solve a problem.  What is that problem?

Shoe store

A user is at shopping site.  Say, a shoe store.

The store sells stuff that you can classify in categories that are familiar to, and expected by the user – Men, Women, Children, Casual, Formal, Outdoor, etc.   Each category of shoes has more items than you can fit in the real estate available on a single web page.

The shopper must be able to peruse any category that she is interested in.   Further, regardless of where she is in the site, the shopper must be able to switch to any other category of shoes.

Farm insurance policy

You own a large farm.  You have an insurance policy for the farm, which includes many individual coverages.  You have had the policy at the same insurer for several years.   You want to log in to your insurance company’s web site, and see all available information on your farm policy.

An insurance policy is characterized by many different kinds of information.

• Demographic information about the policy’s owner – name, address, age, marital and employment status, etc.
• The various coverages included in the policy – Livestock, limits of the coverage, deductible associated with the coverage; outdoor buildings, limits of the coverage, deductible associated with this coverage; coverage on machinery; coverage against crop failure; and it can go on and on.
• Historical data – the policy as it existed in past years (the industry refers to that as ‘terms’)
• Billing history
• Documents associated with the policy – signed agreements, photos, letters that went between customer and insurer, etc.

You cannot fit all of this information into a single screen.   You must clearly indicate what types of information are available for a policy.  Finally you must allow the user to pull up and view any type of information, at any point in her interaction with the web site.

Someone must know

Someone must know the data you are presenting.   What is this data’s place, and purpose in the world as we know it?  Can we break the data down into coherent parts?  How might the parts be related to each other?  How do you refer to the various slices, and components of the data?

Someone must know the needs of the user vis-a-vis that data.   How does the user understand the data?  What is her mental map of the data?  How does she categorize the data?  What names and labels does she use to refer to the data?  How does she think the various pieces of the data are related to each to other?  What exactly is the user interested in viewing?   What processing might she want to trigger on the data?

What do you call this knowledge?

I always thought of this knowledge as ‘business analysis‘. I suspect that most folks I have worked with, none of them trained in the magic arts of user interface design, would also think of this as ‘business analysis‘.

However, I am learning lately that this particular sliver of the business might be known as ‘information architecture‘.  I am not sure. Does it matter what it is called?

 

Presentation solutions

Now you understand the data that you have to present.   You also understand the user’s expectations regarding the data.   Can you devise ways of presenting the data such that the user’s needs are served?

You do not know how to write computer programs.  You know color, shape, image, typography, and layout.  You know how people react to these visual elements.   You can communicate with people using just those tools.   You know how to convey information, suggest actions, and create a virtual environment on the computer screen, which makes a user feel safe, competent, and perhaps even happy.

You are able to use the expertise I described above and design many different ways to satisfy the needs documented by the ‘information architecture‘.  Of these various alternatives, ‘tabbed pages‘ are just one.  Here are some others.

 

 

 

 

 

You also probably know how to present these alternatives to users, and test their use of them to determine what works best.

Once one of these alternatives, perhaps even tabbed pages, is chosen, you ask computer programmers to construct the interface.

What do you call this knowledge?

So what do people call this expertise?   I hear several terms, all of which seem related.

• Graphic design
• Visual design
• Interaction design
• Human computer interaction
• Anything else?

Do they all refer to the same questions, and answers?  Is there an overlap?   Does it matter?

Is it possible to be good at one, and not the other?  Can you be a good graphic designer, but a poor visual designer?  Could you be an an expert on human computer interaction without being a good visual designer?  Or could you be good visual designer but know little about interaction design?  The last does seem plausible.  Mostly, all of this seems a little bit nuts; another case of words getting in the way of meaning.

In layman’s (that would be me) terms, this expertise simply seems to be what falls in between knowledge of the business – data, processes, and users, on the one hand, and the ability to construct the interface, on the other.   These folks design an interface in response to the business knowledge that the ‘business analysts’, or ‘information architects’ provide, and the ‘programmers’ (the construction workers of the digital world) tell the designers what they are able to slap together.

Constructing a solution

Finally, we have the field of knowledge that I am able to grasp effortlessly.   Given a blueprint of the interface, someone has to make it flesh.

You use languages and technologies like HTML, CSS, Javascript.   You can also choose some server-side poison like ASP, JSP, XUL, and so on.   The more you are cognizant of the other two kinds of knowledge, the more effective your construction will be.  However, you often know little other than the construction tools.

What is this knowledge called?

I think this is what many people call ‘web development‘.  Often, a web developer is almost always someone with only knowledge of  ‘construction‘.

 

Why does any of this matter?

If you are starting out, and getting a kick out of creating web-sites, are you able to figure out which of the three types of work is giving you the high?

Just as important, are you able to tell which of the three areas you have a facility for?

1. Do you like the rigorous analysis, and the emphasis on precision in language, which seems the central characteristic of ‘information architecture‘?
2. Do you have a gift for communicating visually, without which you can’t do well at the ‘presentation design‘ part of the work?
3. Or do you have a gift for nuts and bolts detail, and are able to methodically, and relentlessly concentrate on a job till it is done?  This is what construction requires – stamina.

The question is just as relevant for someone like me, who has been programming for a while, and has lately developed an interest in something that I know is not exactly programming, but I don’t know what to call it.  The best thing I can think of is – you know, that thing that Apple does so well.   Design?  User experience design?  Usability?  What?  I have never thought of myself as a creative person.  What?

For the record, I think my strengths might be (1), and (3).   I enjoy, and obsess over (2), but I don’t have a gift for it.  I think.   As the man said, “it is a puzzlement”.