The UX of the Long Tail

The long tail should be familiar to everyone.

theLongTail

Every project I have every worked on was like this.  Here is the breakdown:

1. The Logos. Greek word which is defined as “Meaning”.  We all have experienced the boss who comes in and says, “I want you to design a widget system.”  So in essence, they have given us a logo (“widget”) and nothing more.  It is just a word or phrase or idea.  Maybe the logos is “This competitor is kicking our ass, what can we do?”  This is the most important part of the process.  The single word defines a project at the highest level.  It gives big picture marching orders.  The Design (big D) has already begun with just a simple phrase.

2. The Design. This is where the logos is turned into something tangible.  This is the where the major breakthroughs in the design are made.  My best work is always in this phase.  I love this phase.  This is where I use PowerPoint to make storyboards and use cases and mockups and architecture.  R&D happens here and you find a great partner or a great technology to get you 80% of the way there.  I specify a ton of details and it all progresses very quickly.  Everyone is happy during this progress.

3. The Long Tail. This is where the real work of the design really happens.  It is the long, hard slog through the details.  The granularity is tiny.  You are working out what to name the button.  What should the instructions say?  Should it be allowed to do X or Y when Z is “active?  Question after question after question.  I hate the long tail.  It’s not very creative.  The energy sinks to near zero.  You end up staring at screen after screen and forgetting where you are.  Everything blurs together into a huge mosh of details.  This is where people differ on opinions.  Pixel position, subtitles galore.  The long tail makes slow progress because there are so many details.  It’s not the “short tail”.  80% of the design effort helps you flesh out the last 20% of the project.  Personally, I would be happy chopping the tail right off the design and working those details in iterative fashion with the developer.

The big problem with this whole reality is that bosses often expect design to “finish” before you move on to the next design project.  It’s unrealistic.  Why spend so much time making so little progress if you have many projects in the hopper?

It’s much better to chop the tail and move on.  Get 80% of all of your projects before starting on any of the long tails.  Work with the engineers to see how much details they must have to do task decomposition and estimates. The estimates are critical, because once they come in, you might say, “If it’s going to take that long, let’s defer this project until next year.”  No point working on a long tail that won’t even get past go-nogo.

The long tail is reality, don’t fight it.

2 thoughts on “The UX of the Long Tail”

  1. That’s why I love using a framework like ExtJS. Things like how buttons are going to look, where they’re going to be placed, their grouping, and tons of little design details like that are completely removed from what needs to be done. Since I started using a framework like that and stopped designing everything in shop, the amount of time I take doing the Long Tail has dropped quite a bit!

    I mean, all my applications now look exactly the same, but still — they work! :P

  2. We have been using ExtJS since 0.33, and love it for the same reason. If we had to add the interaction design details to the long tail, it would be 3x as long, for sure.

    However, there is still the long tail of decisions for any non-trivial application. Specifics about how things are supposed to work. Little logical questions. So the long tail becomes more qualitative and hopefully yields a more intuitive result.

What do you think?