Reset password:

Strategic insights
The A-second-or-so Problem

Written by on December 1, 2008

One of the most important lessons I have learned from making web experiences, is that the little things are much more important than the big stuff. It is the little things that kill you.

The big stuff is never really a problem. It is easy to see if you make a big mistake, or if some big part of your web application isn't working. The big problems are easily identified and solved.

But what about the little things? What if you have a tiny problem? What about a problem that is so tiny that it seems insignificant. The kind of problem where you say:

"Oh, that isn't a problem because you will rarely use it, and it only takes about 8 seconds longer to do. In fact, it would take much longer to fix it, than the time lost over the cause of a year."

...or what about (when people are complaining that your system is slow):

Oh, it is actually quite fast because it will get you where you want to be in about a-second-or-so... see [click], there you are!

Here is another good one.

IT guy: We have added another check to the startup sequence.
Normal person: How long does that take.
IT guy: Oh, you won't notice the difference.

The problem with little things is, that on its own, it isn't really important. Each individual thing is not going to change the experience. It is so small and insignificant, that we tend to ignore or dismiss its importance.

But the little things are far more important than that. You don't have just a single little thing that takes about a-second-or-so. You probably have 100 little things. Each little thing isn't important, but when they are combined in a workflow you suddenly end up with a sluggish system that everybody hates.

When people are complaining about performance it is rarely caused by a single big issue. It is caused by a thousand little things over the cause of a day that all takes about a-second-or-so to do.

When people are complaining about complexity, it is rarely caused by one big problem with the workflow. It is caused by small amount of tasks that is repeated over and over again.

7 little things you should do everything to avoid

Here is a list of 7 little things you should do everything you can to avoid. You should say no to them the very first time it is brought to your attention.

1: Security

The most important threat to your web application is security. Not that somebody might break into your system, or create havoc with your data. The threat is the security initiatives by your IT department. Security people will try very hard to put as many "security checkpoints" between your web application and the people who have to use it.

And just like security initiatives in the airport means that you have to show up 2 hours before your flight (instead of 15 minutes), so does security put a major drag on the performance of your web application.

Never add security for the sake of adding security. Find out how you can be secure in the most efficient way possible. And base your security on a realistic scenario.

2: Office policies

Another big problem is when you have to adhere to a number of policies. Every company seems to have a knack for making up policies every time something unforeseen happens. These policies are, in most cases, completely ridicules.

The next thing that happens is that your web application should act as the enforcer, drastically increasing the complexity of your system.

Things like, being able to control what each person can do, in minute details. Or that some people cannot add or edit something before it has been approved.

All of these things should be handled by people, not by a web application.

3: Too many cooks

The third "little thing" that can cause major problems, is when people want to add little things that is only usable to a small group of people.

Everyone thinks their content is far more important than it really is, and forcing it upon others is not a good idea.

You should create a system where content can be "featured" for a short period of time, but you should not allow people to fill it up with whatever each person wants to show.

4: No archives

The fourth "little thing" is archives. You know, when people wants to add some functionality or put up content that is useless for everyday use.

A web application is not the place to put an archive. In fact, it is - in most cases - never a good idea to support archiving at all. Everything you put online has to provide value, and it has to provide it now! If you want an archive go to the library, or put the files in a shared folder somewhere on the network.

5: Developers

Developers are particularly bad. If you allow developers to roam free, you will probably get something that is (technically) pretty impressive, but soon your web application will look like the cockpit of a Boeing 747.

Developers like to be able to change settings, fiddle with controls, and being able to adjust pretty much everything. Without a strict plan and "it has to work as a whole" ideology, your web application is going to fail badly.

6: Personalization

Personalization is a great thing, unless you design it to be personalized.

I mean, if you design personalization so that people can set their own preferences, then you are in trouble. Personalization should not be designed as a tool. It should be invisible, completely automatic, and a natural part of the flow.

Personalization is not about giving people power over the experience. It is to "empower" them. That is you get the power, without ever realizing it.

7: It only takes a second or so

And the final "little thing" that can cause major problems are all those other things that people want to add, or to be able to do, or wants you to support. It is all the things that add an extra step to the workflow.

If you really need to support it, do so as a secondary part of the system. Fight as hard as you can against the "it-only-takes-a-second-or-so" extras.


At the same time you should really seriously try to optimize how something is done. Consider merging tasks together, remove system actions from view. Consider if something could be completely automated behind the scenes. Do everything you can to remove settings.

  • Do you really have to show a printer dialog box?
  • Do you really have to add an "accept current list" button?
  • Do you really need to validate that part now?
  • Do you really have to show that progress indicator?
  • Do you really need people to click "yes"?
  • Do you really need people to enter that pin number?
  • Do you really need to know a person's phone number?
  • Do you really need that drop down list?

And...

  • Do you really need a person, to tell the system, what to do in this case?

Note: Up next is an article about how to "do" little things to make your web application remarkable (in about a-week-or-so).

Share on

Thomas Baekdal

Thomas Baekdal

Founder of Baekdal, author, writer, strategic consultant, and new media advocate.

Follow    

Baekdal PLUS: Premium content that helps you make the right decisions, take the right actions, and focus on what really matters.

There is always more...

The Many Business Models of News »

ONLY FOR
SUBSCRIBERS

21
PAGES

The Economics of Individual Media »

ONLY FOR
SUBSCRIBERS

31
PAGES