Lost in the Matrix

Posted on March 13, 2001

in IA/Usability

by peter van dijck (pedrito)

Rated 3.5 (Ratings: 18) (Add your rating)

Want more?

More articles in IA/Usability
More articles by pedrito

peter van dijck

Member info | Full bio

User since: October 22, 1999

Last login: August 30, 2005

Articles written: 23

Yes, IA is cool, but beware or you may get lost in the Matrix! Every IA will recognise this problem, here I will describe it and offer some solutions.

Hierarchies.

Hierarchies are an IA's best friend. They really make it a lot easier to design a navigation.

Let's say you're designing a site that sells T-shirts. And shoes. From two brands: Adidas and Nike. (It's that kind of site.) So you have a think about it, and decide you can come up with two possible hierarchies:

Obviously, we have a small problem: which one to choose? First, you can think about which one of the two dimensions of the company-product matrix (you're dealing with a two dimensional matrix, which is not too bad) has the least elements in it.

So you go to the client and ask if they plan to sell products from other companies in the future. You also ask them if they plan to sell more products. Turns out they do both, but there will definitely be more products than companies.

Two dimensions? We laugh at two dimensions!

So this all looks like you could organise it with companies on top, since there'll be a limited amount of companies. Maybe you can put the companies in tabs or something, you think.

But wait a minute: could there be more dimensions involved? Sure: women and men products. Someone could be looking for women shoes, or male Nike products. So now we have a three dimensional matrix to deal with, which gives us 9 possible organisations for the hierarchy we're trying to build. Feeling lost yet?

Users? Abusers!

This is were we have to start thinking about our users. There are lots of ways to organise this hierarchy, which one would be most beneficial to the user? An IA with unlimited resources would of course have a detailed task analysis to her disposal, but you don't. Oh well.

Let's see:
would a user be looking for an Adidas shoe? Or for a male sporting shoe? There's no way for you to know, so how do you find out? You ask the client, who hopefully knows his business. Maybe you try asking their salespeople, they should have experience with this.

The salespeople you talk to all tell you women always look by color, and men tend to look by brand. Cool.

You go home and cry on your significant other's shoulder, because your research has just introduced another dimension. Color.

A Four Dimensional Matrix

And there you are, stuck with a four dimensional matrix. What's a poor IA to do?

But when the going get's tough, the tough get rough. They give you a four dimensional matrix, you just pull out your users again. (By the way, more dimensions are imaginable: price, size, ... you name it. But we'll stick with these three for now. Yes, thank me later.)

You learned that women always shop by color, and men shop by brand (this is just an example, by the way). So you're going to assume for a minute that this is true for web shopping behaviour as well. Maybe you can divide the hierarchy into male and female shopping behaviour at the top? A "task driven" top level, as an IA would say when she wants to impress clients.

Or maybe you could make a funky navigation scheme that let's users choose from a few dropdowns and directs them to the correct node in our multidimensional matrix? The dropdowns could be actively adjusting to each other, so they would always only show appropriate choices, depending on the choices you already made. You asked your programmers, some funky DHTML can do that.

But wait a minute, what's that nagging voice in the back of your head? Is it trying to tell you something? It's waving its arms, flipping its legs and it's saying something, speaking some strange language...

... eh ...

... Swedish? Then you realise: of course, it's Jakob Nielsen telling you to Keep It Simple Stupid. Darn!

Back to the Drawing Board

Ok, you sit down again, and see where you stand. You've looked at the subject from a multidimensional angle, and you've learned how your users think. Now how can you present that in a simple navigation that will make sense for them?

Maybe on the homepage you can divide surfers in the male-female split, and design a different hierarchy for both? You'd have to test it though, to make sure it isn't too confusing. You usually want hierarchies to be exclusive (e.g. an item only shows up in one place in the hierarchy), so when using two hierarchies do they need to be exclusive as well? Could you come up with one hierarchy that fits that top level task oriented division?

Many questions, and I'm going to leave you to it. I've got work of my own to do. Remember, it takes work to build decent hierarchies and navigation schemes. And once you've come up with something, test early and often, with real users. Good luck.

Article History

I had this one in my head for a long time. Written and first published (at my experimental manila site: March 13, 2001. I was happy with it so submitted it to Evolt on March 14.

Peter Van Dijck is an Information Architect with an interest in localization, accessibility, content management systems and metadata.

poorbuthappy.com/ease Weblog

petervandijck.net Portfolio

Easytopicmaps.com

liga1.com Accessibility and localization

28 comments on this article. Log in to add your comment | Rate this article:

Why is it complicated?

Submitted by andlang on March 14, 2001 - 20:24.

Why does it have to be complicated? Let the user get his product information with a SIMPLE form. For every "dimension" you introduce, add a form element......keep it simple with drop down boxes and check boxes so they don't HAVE to key anything....and keep the form elements to a minimum so they're not daunted by a huge form to fill in (a HUGE turn off). But, if the form is simple and clear, the user makes his selection, he clicks on the Submit button, the information is grabbed from the DATABASE (we are obviously talking about databases here), and hey presto, the user has his page without navigating around some christmas tree of options. You are thinking about it too logically - every dimension adds so many more combinations of choices (oh no!). No, that is NOT true from the point of view of building the website. It IS true if you don't use a database, and have every product on seperate static pages. But, err.....this is a database solution. You fetch the information from the database via a form, it's really simple....even Jakob Neilson might aprove (if you kept the links in blue). An example of what I'm talking about is when you check for flights on a web-site. You think every flight detail is kept on seperate pages? Of course not. You select your destination, time, preferred cost, airline etc etc via a form - the info is looked up in the database and matches are returned. Throw those Visio boxes away!

forms are all very well....

Submitted by pell_mel on March 14, 2001 - 23:51.

to get you to what you want, (providing your form's kick ass, and the more variables/dimensions there are, the more complicated that form's gonna get) but what about the navigation on the site? what if i get to my shoes and i want some for my partner of the other sex, shoe brand preference, whatever? do i just keep hitting my back button to get to the front page (or click on the site's logo, or whatever) and search again? searching and browsing are very different tasks, and in my experience ppl use a site in all sorts of different combinations of these 2 things. it doesn't make sense to me to not to at least try to cater to that. btw: how can one {quote}think about it too logically{/quote}? ;-)

keep it simple - here's how

Submitted by andlang on March 15, 2001 - 00:28.

"the more variables/dimensions there are, the more complicated that form's gonna get" - (quoting pell mell). There are elegant solutions to building what is essentially an SQL statement for a database. In laymen terms, the "SQL statement" is the search criteria for the product the user is after. We can be clumsy and offer a long list of drop downs, check boxes, radio buttons, text fields and turn people off using it....or you can be elegant....enough generalisations, let me be specific to the example of this topic:- I would break it down to TYPE of product first, before going for a search form. Why? Because "Shoes" has different sub-criteria to "T-shirts" so a search form cannot be a "one-size fits all for all products" - so I'd offer a conventional menu from the front page:- T-shirts, Shoes, Trousers, Swimming Caps, Whatever....all as standard navigation style, not a form. THEN once the user selects the TYPE of product they are after, they;ll get to a new page with a search facility to cater for each product's individual criteria. In effect, this system would only have three pages:- 1. The home page where you can select the type of product 2. The search page to locate EXACTLY the criteria you are after 3. The results page listing the matched product (with options to buy) On each page, the user can get back to the home page by clicking on some logo or simply text saying "Find another product". I've built many sites like this, not exactly e-commerce, but where a user wants to find something on the site, and find it quickly without having to learn anything. The above flow diagrams ARE too logical in terms of navigation. Why must a user make a selection, then click, make another selection, click again, until they arrive at a certain page? It just felt like he had a static page solution in mind, rather that a database solution. The data is held in a tree-structure, but navigation needn't be (with a search facility it's kind of random access).

user behaviour

Submitted by pedrito on March 15, 2001 - 05:57.

The main point of the article was to remember user behaviour. People do not always know what they're looking for. They may want to compare. They may want hints. You need to support their browsing behaviour, not force them into your solutions (won't work). The 'build an efficient form' idea is a programmers' solution. It's no good for real users in most cases (unless your users are programmers, and even then.)

Remember, the goal here is not to provide easy access to all nodes in the matrix (that's where you get lost), it's to sell these things, which can only be done by supporting online shopping behaviour.

Andlang: I agree ofcourse, the above diagrams are indeed too simple. I was trying to clarify a thought process.

Pell mell: I agree as well. You need to cater to different behaviours. (browsing and searching, and combinations).

An example

Submitted by andlang on March 15, 2001 - 21:08.

Maybe my ramblings are that of a programmer's opinion - point taken. I can show you an on-line example of what I mean, to clarify. Try:-
http://www.ebookers.com/
It's a site where you can book flights. It assumes that the user has SOME IDEA of what flight they're after......I guess somebody who is shopping on-line and is looking for a new pair of shoes, they surely have an idea of what they want to buy, even if it is a present. If they have no idea of what they want, they can always check the full range of shoes on a site (searching under ALL - maybe they select ALL BLUE, or ALL ADIDAS, but they have any option available under a form). Maybe you'll come back and tell me that the e-bookers site is too complicated for the average user. Well, it's very popular with people and it hasn't changed it's interface for over 2 years, so it must be working for most people.....this is the kind of thing I had in mind for your solution to the product first/brand first conundrum. Pedrito, I didn't say your diagrams were simple, just that you were actually building the DATA structure, not necessarily the navigation for the site. The data structure could be 50 levels deep, imagine if you tried to mirror navigation to such a structure?? But you are right, there is no perfect answer - I'm only making suggestions!

User Behavior

Submitted by Garrett on March 15, 2001 - 22:37.

There is a clear need for a database in this model. Due to the fact that these multiple dimensions exist, there would always exist some uncertainty as to which method the user would prefer. But why worry about that? Using a db and a backend scripting language, users could easily generate pages full of all the "male" products, or the "blue" products, or whatever they wanted. Just create db fields for each variable, and then loop through and print the options out. I find a complicated hierarchial model too confusing for a multi-tiered shopping site like this. I do, however, agree with pedrito's opinions on users. You shouldn't give them a search box and expect them to know what to do... you have to compromise. Maybe the users -don't- know what they want... they could very easily just be browsing and exploring the site. There has to be a way for them to access thumbnails of products and their current "location" on the site. My suggestion would be to include a menu on the front page of the major types of products (tshirt or shoe). Then, they would be taken to a page where identifying db fields (color,gender,brand,etc) are printed out with their options underneath them. After selecting an item, the user would be taken to a page of thumbnails. If they want to institute more than 2 dimensions, they can use a search box located on each page.

i have met a few databases in my time...

Submitted by pell_mel on March 16, 2001 - 06:28.

but i don't for one minute think they're gonna drive the way i design my navigation system.

of course if it was a huge store (or even a modest one with hopes of growth), the info would be in a db and we could dynamically generate the pages. agreed.

however, this is *still* not getting me 'round the site.

" You also ask them if they plan to sell more products...but there will definitely be more products than companies". i'd be thinking about going for broader categories - "footwear", "leisurewear", "underwear", like a virtual dept. store. (it's using a model i know my users have seen before). I know, i know, there's the gender thing.

but a lot of things can be unisex- running shoes, tshirts, jeans, trackpants, etc. So maybe once i'm there in the footwear section and i'm choosing a sub-category of "running shoes" i get a form that asks me size color, etc, BUT if i'm in a section like "leisurewear" and i choose a sub-cat of "tshirts", then the form that asks me size, etc can ask if i want women's sizing or men's.

that is one way i could organize this kind of content for browsing. and in each main category i could have a search box that gave me a way to search the sub-cats AND the size, colour, etc depending on the product. that's one way of emulating the search or "excuse me, where are the adidas tshirts?"

breadcrumbs

Submitted by pedrito on March 16, 2001 - 08:14.

As you're designing a navigation for something like this, another interesting element to consider are breadcrumbs. They work very well (I've never seen a user look at a well executed breadcrumb and wonder "what the hell is this?"). However, for a pair of adidas shoes, do you put "home > adidas > shoes > killerpair" or do you put "home > shoes > adidas > killerpair"? Or do you let it depend on how users got there? You can clearly see the potential for confusion here, and the need for testing. I actually saw a site letting the breadcrumbs depend on how people got there, but I've lost the URL. Darn!

Note: as for the database: we're not talking about how things are done on the server side (you could store the information in flat text files, or on punchcards for all I care), we're talking about designing a navigation structure.

follow the trail

Submitted by pell_mel on March 18, 2001 - 18:06.

breadcrumbs are very interesting.
according to my model, the breadcrumb trail would be home > footwear > running shoes > adidas > killerpair, so guess that confirms i have used the first heirarchy over the second one. (but i realise also that i have conveniently left the gender issue "swinging in the breeze"!)

as for sites that let the nav. trail be generated by the "how you got there" rule, but to me that seems potentially *really* confusing.
if i the user don't ask the question the same way, how the hell do i find my way back to that pair of shoes ever again?

the backend CAN determine navigation

Submitted by andlang on March 19, 2001 - 03:33.

The use of a database CAN determine the navigation, it is certainly not a "seperate element" of the site - it is integral to all aspects, since you can *generate dynamic content*, rather than have to lead the user down a multiple click tree navigation like "home > footwear > running shoes > adidas > killerpair" (I am making an assumption here that each level in this hierarchy requires the user to click - correct me if I'm wrong!!). A well designed site using a db gets the content the user wants to see from the database (from the user's feedback - be it clicking on a thumnail, a form, or tree navigation) - this definitely influences your options as to HOW to let the user get the information ("navigation" and "getting the info from the database" are totally inter-changeable terms here)......the faster they can get to the content they want, the better (of course!). You can also remember their likes and dislikes using a db if their a regular user of the site, and can give them a "my personal page" as the home page with stuff their interested in (as in, what they've shopped for/looked at before)

It's all about choice (user choice, that is...)

Submitted by Calum on March 19, 2001 - 08:52.

It seems to me that the main difference here (from a UI point of view), is that in one case the model is sequential, eg.

Use the DB to enhance navigation...

Submitted by eli on March 21, 2001 - 08:48.

The db can be designed in such a way as to provide navigation considerations "on the fly". An example, you have primary navigation items that appear consistently throughout the site and secondary navigation items that appear based on selections made. This may cause you to think a little more "multi-dimensionally" but it is certainly not difficult. This is an extension of Andlang's "The use of a database CAN determine the navigation, it is certainly not a "seperate element" of the site - it is integral to all aspects, since you can *generate dynamic content*". My addition is that you can "generate dynamic navigation" as well.

navigation / show me the info!!

Submitted by andlang on March 21, 2001 - 21:23.

Yeah, I think the word "navigation" itself is a confusing term. The bottom line is this:- getting the information the user wants......to the user!!! Databases offer intelligence - they can learn quickly from user responses and accordingly set up pages unique to the particular user. They can offer information to the user, or simply allow the user full control and let the user decide what information they want to see. We often think of websites as a bunch of pages, so we wonder "How do we get from page A to page B?" - that is true for static, non-changing pages. For db, "on the fly" (as eli writes) navigation is possible.

from a user's perspective...

Submitted by pell_mel on March 21, 2001 - 23:38.

websites ARE a bunch of pages - whether they're templates which build pages on the fly or whether they're a whole bunch of flat pages

eli, if you're gonna build navigation on the fly, as a user, i'd be wanting to know that i couldn't get "lost". i personally hate sites that change the nav as i go- i never know where i am if it's big site!

andlang says "The bottom line is this:- getting the information the user wants......to the user!!!". i agree- but i don't think that the search model finds me what i want, *every* time. look at a search of most sites- firstly you put in the search terms that you think will take you to what you want. if that doesn't work, you *might* keep on trying other terms. (or you might just leave- "bye bye customer", as Calum has already stated)

i don't know if the search experience can adequately encompass the breadth of things i might be able to choose from if i browse the site. amazon has lots of levels of browsable content AND a great search. it caters for both kinds of navigation. it uses the database driven dynamic page experience in fantastic ways- if i am browsing palm pilot's in electronics, i can click on "show me other handhelds" and compare them. that's cool, that's useful, and that works in a way i can understand!

I agree with most things here

Submitted by andlang on March 22, 2001 - 00:26.

Pell-mell, I agree with you about Amazon, you can normally get to where you want to within a click or two; it uses a very traditional folder tabs navigation so you visit the different "main" areas of the site easily - you can search under a number of types of products that normally return results since their database is so vast too!!! About the "search model" - I am a little confused, as I mentioned form objects, not explicitly a text field search engine. Let's not lose track of the original question - if you are a shop selling a finite number of goods, I agree, you're going to get the "zero results returned" factor when you search for your "yellow and green striped stilletoes" (search TEXT) at the sports trainer website. Using other form objects such as drop down menus, radio buttons, check boxes, you can give the user finite options and allow them to get accurate results without waiting for 3 or 4 pages to load. The form objects themselves are the dynamic navigation.....what eli is on about.... this kind of navigation doesn't juggle options around to confuse the user - the site becomes more of a living thing, updating itself with new links for new products, deleting links for discontinued products *automatically*, rather than the manually updated site with the webmaster FTPing every time a minor update is required.

I should have been more succinct

Submitted by eli on March 22, 2001 - 08:18.

pell_mel I should have been more complete in my explanation. There should always be some sort of baseline navigation on each and every page of a site which should result in the user not being lost. The dynamic navigation is additional to the baseline, depending on where you are within the site. On a limited site selling finite goods you should set up form objects as andlang describes above. Here is an example; On the "baseline" nav we have a drop dpwn box for the (remember, this is a site limited in the scope of products it sells) items that are for sale and another for the brand of item (given pedrito's original matrix above. These drop downs encompass the first level of the heirarchy in the diagrams (the "home" level is not the "first" level...I count as a programmer would count arrays, beginning with zero). Not only does this provide the user with more options from the start, but it nearly eliminates Pedrito's matrix decision in his original models. As for the second level and beyond additional navigation can be generated (leaving the original navigation items in place) from a db where things are related to each other. You get where you want to go quickly (from the baseline) and then have options presented to you based on a path you have followed. In this example those additional navigation option are the second tier level above (shoes, t-shirts, Adidas, Nike). The great thing about this is that this is a scalable operation. Referencing a small slice of Amazon.com, click on a book title. Just below the information about the book itself is a section entitled "Customers who bought this book also bought:" This info is maintained automagically in a db and is returned to subsequent users based on a searched choice. This particular example is just a small way in which this can be used. Perhaps I now have the impetus for my first series of articles?

Great Discussion!

Submitted by kasparek on March 23, 2001 - 11:57.

I am new to this community, but can see some real wheels turning here. All of you have brought up valid points: Database design can give good dynamic results to the navigation of the information (isn't that what we're really concerned with here is navigation of the information rather than the navigation of the 'site' per se?) BUT... Users are and should always be our first concern. After all, without them, whats the use of building the site?! Users wanting to return to a search result should be given the ability to bookmark the resulting page. In most cases, the URL will based on the original query. If the user returns before any changes are made to the content of the site, it should return the same results. BUT, if the user returns AFTER changes have been made (a new product line added, or an old line removed) it may change the results. Although I may have thrown another monkey at my wrench :o) ...is that all bad?! If product line changes have been made, you can highlight them in the returns with "You may be interested in this NEW product", or SORRY but that product is no longer available" type comments. As far as browsing versus 'knowing what you're after' - I agree that some real concern exists here, and some real thought needs to be used to address both types of customers! Thanks for allowing my $.02 worth... Cheers!

Submitted by pell_mel on March 25, 2001 - 05:08.

andlang, i can't imagine that you can offer a form-based search/navigation composed whole lot of dropdowns, radios, whatever, once this example gets extended out to the multi-dimensional model. (and even e-bookers has a text-box ;-)). i'd reckon you'd have to break it into a few different searches on different sections of the site.

btw, both you and eli seem bent on "educating" me as to the power of the database - it isn't necessary, thanks. eli, i see what you mean by your "dynamic navigation". yep, it was clearer the second time. :-)

in your model you have (eg) a dropdown for tshirts etc and a dropdown for brands. then on the next level you have more form elements (are they of the same kind so i the user get to form my mental model of how the site works?) one for (eg) sizes, colours, gender, etc. - it's getting crowded and confusing to me! is it "keeping it simple"?

look, i'm not really arguing with your very clear logic, andlang and eli. but there's something in me that says "is this reallly supporting user's behaviour?". Have you *ever* been to a shop, walked in and bought something and walked straight out without looking left or right? Of course not! Surely you had to at least look at the other products to make sure you weren't paying too much, if nothing else. With your solution, i kind of feel like i was being "teleported" round the store, but that i was being taken to a new room each time with only one product in it- the one i selected with my form. it feels kind of unnerving!

That's true..

Submitted by andlang on March 25, 2001 - 18:29.

"i kind of feel like i was being "teleported" round the store [if I just saw the products of the shop I searched for]" - I have to agree with that! Browsing for goods is often how people find the product they end up buying, rather than knowing in the first place (depending on the product of course!). And, I think we're all agreed on usability and simplicity as all important too. I think the solution to the question of how to build an on-line store that offers so many permutations (spelt right?) of options to the user is to offer a baseline navigation (as eli said, where a user can browse by TYPE of product first (if it's JUST a T-shirt website, then perhaps the next biggest category might be brand, or it might be gender....depends on the product and how well you know it!!) . I would further add that once the user has selected "T-shirts" (e.g product type), they then see information on t-shirt offers, maybe a "top-5 best selling t-shirts", newest t-shirts in stock....whatever, but a sort of "homepage" for T-shirts to give the user an idea of what's on offer (this homepage would be dynamically generated).....AND of course, the dynamic navigation we've been going on about to get specific OR general information from the product database.

Ditto the trueness...

Submitted by eli on March 26, 2001 - 07:12.

Just remember that once this has been designed that you must provide heavy doses of Quality Assurance & Testing to whatever model you decide upon. It is the users during this test, as well as input from users once you 'go live', that will ultimately determine what you need to do. Be flexible and remember that because those of us who are 'in the business' say this is good does not necessarily make it so. I have never performed any medium to large scale design that didn't change and mutate up until and after 'go live'.

What is the best paradigm for the user?

Submitted by billabel on April 4, 2001 - 10:24.

Information architecture is not about technology, programming or databases. It's about organizing content in a way in which benefits the user, one in which the user can understand in a way they are used to doing things.

With this in mind, ask yourself how do you shop for shoes? And, how do you shop for t-shirts? Then, in case your not the average shopper, look around, watch people, do some research to find out the trends.

I believe the answer to the author's question of which IA model works best can be answered this way. People are generally used to shopping for shoes in a shoe store that organizes the shoes into two main areas, men's and women's (a third area being children's), then they are organized by use, hiking, running, casual, etc. Within the use categories, shoes are usually organized by brand. Please take note, shoes are not organized by color, size or price. One must sort these out for himself while in the store or by making multiple shopping trips and plenty of notes--this process usually is reserved for more expensive items.

T-shirts are of secondary importance and are used by the retailer to increase their profit margin on a sale. Thus a customer purchasing a $100 pair of Nike's may drop another $15 for a Nike t-shirt.

Common sense dictates, in this example, that this business's focus has to be on shoes. The profit margin is higher and just ask yourself how many times you've shopped at a t-shirt shop for shoes? I can't even think of ever seeing a t-shirt shop that sells shoes. But practically everyone who has shopped for shoes knows if they want a Nike t-shirt, they can go to their local shoe store to get one.

So, I believe that IA hierarchies should follow the shoe store paradigm that users understand and already use. With this particular site, the following hierarchy might be considered: "men>running>killer pair". In addition, a search function should be available to sort shoes by brand and other descriptors. Bread crumbing and other common navigation elements will make the site very easy to navigate.

I would recommend to the client that t-shirts be made of secondary importance in order to not confuse customers shopping for shoes (the primary business). My suggestion would be to simply place them in key places along the user's purchase path. For example, if the user clicks on the specs page for a pair of Nike's, then also on that page should be an option to add a Nike t-shirt to their order. I would still include a path to t-shirts in the global nav, but I would not include any mention of t-shirts in the home page messaging. This would be to satisfy those few customers who are in fact shopping only for a t-shirt.

I don't believe that shoppers behave in exactly the same way online as they do in the real world. Online shoppers are very goal focused, they want to achieve that goal and be done with it. Whereas a shopper in a store is usually...shopping. In other words, someone who goes online to buy something, usually knows what it is they want and simply purchases it. Whereas someone going into a shoe store at the local mall is more likely to not have any clue as to which pair of shoes they want. This is the reason I believe that t-shirts, in this example, should take a backseat to shoes. Online shoppers are buying shoes, not t-shirts. Real world shoppers have time to browse the t-shirt rack and make a t-shirt purchase spontaneously. This doesn't work in the Web-based store.

I believe that IA should be dictated by simple solutions that work according to real world standards. You have to put yourself in the users shoes and go shopping. You have to alss put yourself in the retailers shoes as well and figure out the best business model to use. I don't believe that the author's question as to which matrix to choose makes any sense? My answer is neither of them. My reasoning is that they simply are asking a question based on a lack of information and a lack of inference from the matter at hand.

I am interested to see what kind of responses you guys have to my thoughts. Thanks for providing such a good discussion.

I went towards the tech side of things...

Submitted by eli on April 4, 2001 - 10:58.

...to illustrate the point that you just made, which I agree with billabel. That's why I suggest heavy doses of user testing, preferably in a controlled environment before releasing the beast on the public.

IA's have a huge tendency to do a couple of things, aThey get so hooked into their own creation that they fail to listen to the user. Any suggested changes hurt the IA's sensitive ego. bThey "test at the desk". Instead of relying on user feedback at all they declare that the solution they provided will work for everyone, everywhere, all of the time. That is why I am happy to see and participate in this discussion, because it may open many an IA's eyes!

continue billabel's thought process...just because you arrive at a solution for shoes (through sound and documented user testing), don't assume that the same solution works for jewelry. There are many technical solutions to apply to the challenge, but there is a fairly clearly defined method for shoe shopping amongst the majority, (there is always a select few unique users who will not fit the usability profile). The ideal situation is to have enough of a cross section to make all testing valid and usable.

In my earlier responses I went too far towards the tech side of things, for which I apologize. billabel's comments brought me back to the question at hand, which is, "How do users do what they do when shopping and how do we, as IA's, quantify that so that a solution can be applied?"

Sounds like boo.com

Submitted by joshkress on April 28, 2001 - 13:43.

When reading through Peter's article and the comments above, I had to think more than twice about one of the problems of boo.com: Building a huge site with many products being sold to many people in a lot of countries, paying with many different currencies. In the end, it's not just confusing for the user, even developers get some headaches and sleepless nights. If you just suggest massive user testing and revising, before launching the whole project, you have also to think of things like budget and time. In most commercial projects, and Peter's shop example would be one, these two factors are the main problem. User testing is expensive and I'm not just talking about money; as a developer you're under immense pressure by a lot of people, especially by the investors, who want to make a lot of money as fast as possible. And these people don't even care about IA, they just want to see a '+' in the last line! You see, it would be far to "easy", if you're only problem was IA itself. Of course, user tracking would be a nice thing and a fine solution to the IA problem, if you were allowed to use it all extends. But that isn't the case, at least here in germany, where you're highly restricted. And this can be the worst thing for website to happen. Let me compare a site with a good friend (and that's what most usabiliy-gurus want a website to be) : Can you really imagine that someone can be good friend to you if he can't listen, can't speak to you. He just sees a shape of your person. I can't!!! And most site are more like this than being a "friend" to the user. I know this comment doesn't fit to all the others, but it's a nice thing to think about; and if you're under pressure by your boss or an IPO just say 'boo.com': For them it's like a 'buh' in dark for a small child and you can consider again on Peter's article.

Usability testing expensive?

Submitted by MartinB on April 29, 2001 - 04:03.

If management see usability work as expensive, let them consider the alternatives - a site which no-one can use, so no-one can or will buy your products.

Boo is a good example. These guys are another - completely killed by poor usability. They had 1500 users rather than the 100,000 or so users predicted, all caused by nightmare usability issues which management and the developers refused to even admit the possibility of, let alone explore and rectify. Work24 went through about £30,000,000 of shareholder money, and has probably ensured that the boards of the two parent companies now consider eBusiness a waste of time.

Another regular occurance is where a meeting whose attendees (many with no IA/usability experience) cost a total of £1,000 or more an hour spend several hours arguing personal prejudices as to where a button should be, when less than the total spent could do some simple user testing and come up with the correct placement.

The other situation where usability intervention can be expensive is when it is applied too late in the development lifecycle. As with security, applying the results of usability work towards the launch phase usually means largely ripping out much of the work already completed and starting again. Not only is this going win few friends in management for delaying the launch, the developers will find all sorts of ways of making the work expensive in their change control estimate, so as to avoid doing it.

Example: The development partners for a site I worked on had produced a six page teaser site for us. In frames. Knowing the issues with frames, I asked that the frames be removed and the site produced as single pages. The change control request went to the developers who estimated it would take 5 working days to remove the frames from this six page site. Needless to say, the change didn't get made.

if "traditional" testing's too expensive

Submitted by pell_mel on April 30, 2001 - 08:25.

consider doing the old "cheap and cheerful" model. what we do is just grab a few different people from 'round the office (luckily it's a big one) and sit them down with a 'puter and a video camera. we tape the session, and also usually run a line to a monitor in another room where stakeholders/developers/members of our IA team can observe.

even this kind of testing where we grab impressions, or give our subjects a few tasks, or whatever's appropriate to where we're up to in our development of the site are better than nothing. It's amazing what a fresh set of eyes can find for you. (or completely miss! - that's our common experience. "how could they not see that!")

this isn't OUR department's idea, btw; we got it from "Don't make me think" by Steve Krug. (amazon link) He's got some how-to's about testing if you haven't had any experience with doing any before, too.

It's a suggestion for when you get that "testing's too expensive" line.

Inform yourself (and your process).

Submitted by lkantrov on May 6, 2002 - 00:06.

IA's have to first inform themselves. There are many ways to gather info/data before striking out on a design:

- User research (your own)
- Marketing research (e.g. how do people shop in physical stores)
- Field studies (go watch people)
- log file analysis

Then, once you have a prototype or initial idea, you can gather feedback and additional data to inform your process further:

- Card sorting
- scenario-based walkthroughs
- lo-fi prototype testing (I like Krug's guerilla style/cheap testing for this)
- etc.

If I had a dime for everytime I proved myself wrong, I'd be pretty well off. Many times I get it almost right, but off the mark enough that the methods above pay off big-time in showing me ways to improve the design. If you're talking about a business site or application, then you have to weigh in the business risk (additional support cost, wasting $, brand degradation, rework, etc.) versus the cost to properly design and test a system. Too often products are rushed to be "first to market" -- but often they are just "first to market with a sucky product" Lyle
Croc O' Lyle

Faceted classification

Submitted by pedrito on October 7, 2002 - 02:36.

I just realised using something called faceted classification solves exactly these problems. Try a Google search.

Basic principles and processes of IA

Submitted by gianna on October 14, 2004 - 05:40.

Although this article is quite old Information Architecture is more needed than ever. I think the best starting point to get hold of some basic principles (e.g. faceted classification, too) is the book called "Information Architecture for the World Wide Web" by Louis Rosenfeld and Peter Morville, O'Reilly. Of course what brings your further in exploring IA is only practice, practice, practice.

Start of page header

Submit

Article Categories

Highest rated articles

Recent comments