Information comes in all shapes and sizes. Some is simple. It’s copy that goes on a page. It’s an image. It’s a sound file. It’s a single PDF. It’s whatever atomic piece of information you can imagine. Then there is the molecular level, for instance, whole web pages with mixed content. Then there is listed information: movie titles, collections of documents, retail products, animals with feathers, types of beer, whatever.

Listed information can get tricky. I poked around the web to see how people were describing their lists and presenting them to the world. In the end I came up with a set of STEPS to help break off bite-sized pieces to digest. I even came up with a cute little acronym in the process.

Here’s how it works: STEPS is Sort, Transform, Eliminate, Paginate and Search. It goes in that order, even.

Sort

The first thing to do with the list is sort it. Generally you’ll want to sort in order of general importance. Sometimes alphabetically will be better. Other times a different sorting algorithm may be useful. Depending on the sheer volume of the information you may be able to do this by hand or, much like the meat in Chicken McNuggets, your information will need to be mechanically separated. I won’t dictate the correct sorting algorithm since it will vary, but it needs to be sorted first. Sorting will make life easier through the coming steps.

Transform

Once you have the basic sorting figured out, you’ll need to run a basic transformation on the resulting list. This transformation usually includes chunking the sorted list into manageable portions, and preparing the set for display. It is key, at this point, that you have already assessed personas for your project. The personas you have developed, along with your understanding of business goals will be key in understanding how to effectively transform your information into something your users can use.

Eliminate

This is the first presentation step. Elimination may be done accessum priori or it may be done on the fly. This depends on your use cases. Often you will know something about what your user needs before they start digging in, so why not make their lives easier and pitch the stuff they don’t want?

Paginate

Even after eliminating all of the information your user doesn’t need, there may well be a large list left to sift through. Fortunately they are already sorted! Pagination helps to trim what the user is looking at and makes each group manageable. It’s easier to skim a short list without getting tired eyes, the same cannot be said for a list hundreds of items long. Keep the displayed list short.

Search

Even after doing all of this, you may still have page after page after page of information the user has to wade through. Don’t forget that users are generally search-oriented. If they can just type in keywords and get what they want, or at least get close, they will be much happier. Preparing information for search is at least a post in itself, so I won’t talk about it here, but this last step could be the critical piece that makes or breaks your user experience when looking for something.

This is just a skeletal framework you can use to help focus each step along the way when you are organizing long lists of information for your users. In the end, the way each step works will be defined by the scope of your project, the amount of information, business goals and chosen personas. The same information could look radically different depending on these factors. In the end, though, working step-by-step will help to focus efforts and steer you away from analysis paralysis. Try my 5 STEPS process and make the web a better place.

As is typical with the break room at many offices, we have a microwave. Actually, we have two, but there is one in particular that everyone knows about and avoids. Everyone but me*, that is. It is a machine crafted in the forges of bad usability and total misunderstanding of user journey.

The main requirement for a microwave is that one be able to set the time for which their food will receive a nuclear blast, converting last night’s roast beef into magma. Either there is a “time cook” button, or you simply enter the time directly. The uranium-235 does the rest.

In all seriousness, people expect time and power level entry to exist with a clear designation. If a microwave has no designation, people often assume it is reasonable to simply begin keying a time. This microwave is different.

My coworkers avoid the evil microwave because it doesn’t do things the way they expect. If you begin keying time, it sets off “auto cook” mode and cooks food for some pre-designated time in full-minute increments from 1-6. There is no “time cook” button, only a “power” button. It appears there is no way to enter the exact time something should cook for.

As it turns out, there IS a way to enter an exact time. If you press “power” you can freely key in your time. Yes, by opting to enter your power level, you are free to enter the amount of time to cook your food.

Clearly someone decided it would be efficient to trim the “time cook” button out of the process because it was an “unnecessary” action that make the overall process slower. What they forgot to take into account is what people actually look for: how to enter the time.

Translation to the rest of the world?

Fewer clicks is just that: fewer clicks. Just because you took away a couple of clicks in order to get the user to their destination doesn’t mean you did them a service. They may have relied on that waypoint on your site. Though it cost them an extra click, they knew each click was an important step upon the journey. You helped build their confidence in your site by marking the path clearly. If you eliminate a critical sign at a fork in the road, your users may get lost.

If you find your users getting derailed at a certain point on your site, look for the missing “time cook” button. Take care in guiding your users carefully through your site, adding an extra step if it makes the entire journey clearer. Users only mind extra steps if they don’t lead to clarity. Avoid building the efficient and impractical microwave and make the web a better place.

*I intentionally use the bad microwave. Since nobody knows how to use it, the traffic to that appliance is low. Food for thought.

Most of what I have seen on the web regarding Information Architecture has been related, primarily, to what the user sees and interacts with directly. This means, what users see, and how the site is, ultimately, hierarchically constructed. Very little consideration is given for what is ACTUALLY going on with the site.

In the early days of the web, a website was mostly HTML and associated miscellany. There were some content management systems and dynamic utilities out there, but they were typically purpose-built and totally proprietary. One company I worked for had a system that, essentially, took in HTML snippets and stored them in a database as a web page that was 90% constructed, doing the last of the construction for presentation on the fly. It wasn’t graceful, but it served its purpose.

Today websites are web apps and vice versa. There are fewer and fewer business sites on the web that are old-fashioned HTML. The company I work for now, has a broad-reaching infrastructure for its web presence which involves various computers and disparate web services. This is all very important to the experience the end-user is going to have when they visit your site.

Information Architects today need to be cognizant of the systems they will be working with, the limitations of technology already implemented and the latitude they have regarding direction for the site and the user’s end interactions.

Let’s assume you have a list of items you already account for in your work: page layout, important items both for users and internal, site hierarchy, taxonomy, findability of information, etc.

Here are other items which should be considered:

Content Management

What kind of a system is being used? Is there an e-commerce solution in place? What e-commerce package is being used? Does it integrate with the existing content solution or is it a separate tool?

Integrated or Decoupled Site/Content System

Is the site being run on a simple Wordpress/Movable Type/Drupal install where the site management is tightly coupled with the website itself? Is the website requesting content across the wire from a service on another site/computer/continent? How will this impact speed? How easy is it to integrate custom features and functions?

Data Transport

This is a biggie. If you have an old-school web project, this is unimportant. If you are sending data across a wire to a custom tool or application, this becomes VERY important. How do you want to connect to the data? Do you want to make a direct remote connection to the database or do you want to send the data as a single package across the wire? If the data is being sent as a package, what do you want to use? JSON? XML? Serialized string? Something sneaky I don’t know about?

These sound like much more engineery/techy/geeky considerations, but they are important in the end. Perhaps you are pulling information from your company’s database, a Twitter feed and pictures from Flickr. All of a sudden, you are working with mixed coupling. You will need to know this in case something fails. You are the one they are going to ask when they need an error screen.

Why data transport? Simple. You don’t need to know how to implement it, but if you work with the engineers and pick a standards-compliant data transport system, you will save them lots of headaches and yourself extra work in the end. By understanding the way data is being passed across the wire, you can start to understand how to better integrate RSS feeds into a design, present useful information to users and do it in a way that will be quick to implement and easy to maintain. Ultimately, if you want to invent a better wheel, you’ll want to be armed with a damn good reason.

Ultimately, there is a lot of information that needs to be shaped and directed. In order to best your user, yourself and your company, you need to consider things that are more than skin deep. By tackling the tough questions about your project early, you can write a more clear and useful specification. In the end, by peeling back the layers, you help to make the web a better place.

I’m taking a brief detour and talking about something other than user tolerance and action on your site. I read a couple of articles, which you’ve probably seen yourself, and felt a deep need to say something. Smashing Magazine published Does The Future Of The Internet Have Room For Web Designers? and the rebuttal, I Want To Be A Web Designer When I Grow Up, but something was missing.

Both articles focused on content and how it gets passed around. The problem is, there is a lot more going than just content on the web. What both articles overlook is the work of the web developer or web engineer. No, this isn’t an attempt to shoehorn engineers into this discussion. It’s about the fact that they are needed to produce function.

Beyond the world of content is a whole slew of function on the web. Web apps have become increasingly important in the landscape of the web. As a matter of fact, you’re currently visiting a web app. Yes, you’re seeing content, but you are also interacting with an application which allows me to manage and publish that content for you to see.

Other things which happen on the web include buying insurance, banking, playing games, posting comments, public forums, meeting whiteboards, chat and many other items which are missing from my list. Web applications are vital to the new web experience.

So, what about the web designers?

Web designers are needed to make all of the extant and constantly emerging applications sensible and enjoyable. Regardless of the particular language or server structure used to produce the web apps you use every day, one of the primary interfaces is still the browser. This means what is an application in one sense is a web page in another. Who designs these pages you see? Web designers.

This link between the design world and the application world has been developing for decades. Designers are vital in the production of web applications just as much as the engineers are. The world of applications today isn’t the same as it was even in the 1990’s.

Users crave satisfaction.

As little as 15 or 20 years ago, to simply have a working application was a feat unto itself. If you could enter input and get a meaningful result in return, the application was launched. People, today, expect more. They want to be able to enter what they need and get the meaningful output they expect, but they also desire rich interaction. They crave visually stimulating and sensible interfaces. Users have gotten more design savvy and they won’t stand for mediocre if they can have the best.

Regardless of where the content, which is fed from a website, is displayed, neither Facebook nor Google will ever be able to serve the function you provide on your site. Moreover, they will not give your user the experience they expect from your company. Only by interacting directly with YOUR site will the user ever find the satisfaction they seek.

Ultimately, the people responsible for bridging the gap between the engineer and the user are designers. Designers come in various flavors from the jack-of-all-trades to the specialist interaction, user experience and interface designers. Designers make the user comfortable. Designers provide the problem-solving expertise which is so crucial to making an interface meaningful and usable.

In the end, to say that the future of the internet has no room for designers would be just as foolish as saying the future of the internet has no place for engineers. I mean, there are all of these turnkey software packages out there, what do you need an engineer for?

It’s foolishness.

Ultimately, engineers and designers are both critical to the web experience. They have been until now and the need is only expanding. Even as content is served out to other distribution channels, the home still needs to be somewhere. Even as content is still king, the sea of applications continues to expand. Much like Jell-O there is always room for designers. Go, design and make the web a better place.

Congrats, you’ve made it to the third part of my math-type exploration of anticipated user behavior on the web. Just a refresher, the last couple of posts were about user tolerance and anticipating falloff/satisficing These posts may have been a little dense and really math-heavy, but it’s been worth it, right?

I have one last function to look at. This function will let us sort out how long a certain percent of our users will hang out at a site, trying to accomplish their goals given a random population interacting with a page or site they have never visited before. By having the ability to calculate the output of the user falloff function, we can compare user test results to our falloff curve without plotting the entire curve to show anticipated versus actual results.

We’ve already talked about the user tolerance constant (L) and our starting number of users (u_0). These are all the elements we need to figure out at what time (t) we will have a percentage (p) of our users left actively seeking on our site. The actual number of users remaining is trivial to calculate after you pick a percentage, i.e. p*u_0.

(Reminder: percentages should always be expressed as a decimal between 0 and 1.)

Without further ado, here’s the function of the day:

t = L*[ln(1/p)/ln(u_0)]^0.5

There are some interesting features of this function which are a direct result of the falloff/satisficing function we talked about last time. First, as we get closer to 100% (or p gets closer to 1) t gets closer to 0. This shows us that, at least at one end, this function must be meaningful since none of our users should have fallen off before the testing or site loading began.

At the other end, we can see that as we get closer to 1% (or p gets closer 0.01) then time is going to approach L, our user tolerance limit. This means our function is actually behaving the way it should and our results will prove to be reasonably meaningful, regarding our test population.

This function is probably as important, if not more so, for testing than our falloff function because you can actually see how you are performing in your test group against a theoretical control group. This means, if you take your testing group, collect data and analyze it against standard statistical curves, you should be able to get a reasonable estimate of how your users are measuring up against when visiting your site.

On the other hand, if you are underperforming, you now have a reasonable metric to deduce when things are going wrong. You can do things like plug in .68 for the percent and see if you are actually capturing the first standard deviation of your users within the allotted time.

In the end, this should all relate back to one question: are my users accomplishing what they want to do before they are getting too frustrated to continue with my website? If the answer is ‘yes,’ then pat yourself on the back and then make it even better. If, on the other hand, your answer is ‘no,’ it’s time to start evaluating how your site is impacting the users who visit it.

Are they suffering from unintended ad-blindness as the users tested for the US census website were? Are you suffering from a hover-and-cover anti-pattern which is causing your users to have to steer all over the page to get to what they need? Are you not using language that makes sense to your audience?

All of these questions and many more should come to mind to improve your performance against the baseline we’ve defined. Just remember, even when you are consistently beating my model you can still improve more. Surprise and delight your users. Beat the curve and then improve again. Think about your users, make your site a delight to use and make the web a better place.