Front-End Book

Maybe your boss, contractor or project owner has just started to be usability-savvy and is planning for usability-studies, personas and interviews in the next big project coming up. You may even have a vision defined on your company saying that you are going to be focusing more on usability. It is good that more people in the organisation identify users as the key to success, too bad they use old metrics to get there. This article will show why traditional usability sucks and how you listen to your users in a more efficient and thus better way.

Traditional Usability

Traditionally usability focus on taking care of user aspects early in a project. The best thing in traditional usability is to be able to identify key user personalities, also called personas, early and stick to those personas until they are proven wrong, then we have to refine the personas to fit reality. A persona can be used to identify people you invite to a usability study to test your interaction designs or even better, your prototypes. If your personas actually are correct and you have managed to find 5-10 people that fits the personas for your study, you should be able to take actions on the things that arise during the testing. They say that if someone has a problem with some of the key use-cases, we have a usability problem. Back to the drawing-board. New prototypes, new tests and new evaluation or if errors are small instruct designers and developers on the issues and possible solutions (patterns).

As you all see, this only fits in large projects never aimed for release or projects where the usability work is more important than the end-user usability. The later happens when someone would like to label their product as “user-friendly” they can say that:

We added years of usability testing, user identification and yada yada yada in to this product.

Often sayings like that translates to:

You may think that this product suck, but we have actually used a usability expert with all the fancy methods to achieve this; It doesnt just suck, it sucks in a way you dont understand. But from our point-of-view this product is usable.

To be honest, most of the time, the reality looks a little bit different than explained above.

The errors:

• Big projects
• Personas based on imagination
• Time consuming process
• Based on the key assumption someone knows “usability”
• Based on the key assumption someone knows “the user”
• Based on the key assumption that we are building something people want

OK, enough ranting, now I have to come up with an idea on how to solve these problems, otherwise I am just another grumpy old man ranting about stuff I tend to dislike for no apparent reason.

Below I have listed processes and entities within your product that will increase the end-user usability without even touching personas, usability testing and “usability experts”. The key to all is agility, responsiveness and user centered development.

Daily releases

By releasing daily. It may be features, bug fixes, smaller or bigger redos, you will come closer to your users, and they will feel that the product you are working on is responsive and fixes things when they arise. Releases in short cycles opens up for shorter experiments as well, test that new listing of news, didnt work? Remove it tomorrow. I am pretty sure that your users will like your approach as it is evident that you are trying to build a better product in the open, and not with your “usability expert”-suit on.

Developer Communities

Talk to your customers. Let the developers and marketing managers blog about the work you are doing on the product. This will invite users to comment on the blog and discuss the upcoming features, bug fixes and releases that will be made on the product. I believe this is one of the big things for services such as Flickr, Digg and Geni. Of course your manager will find some reason for not doing this, maybe he/she will say that you are a public company, and it is important to control information and so on. But that is not an argument, that is just plain old bossing and being scared. Yahoo, Microsoft and Google all blog about their products, of course you can as well. No argument apply from bosses.

Extendable Web and API:s

If you are getting users to your web you must have some content they like. Offer a way for coders and entrepreneurs to use this data. When exposing data as services and API:s you will get enable user centered development. You have your roadmap for your product together with your users, but sometimes it is difficult to achieve everything you have in mind due to resources like time and people. An example of how API:s can benefit your users is Flickr once again, where the best integrated uploading tools for image software (iPhoto etc etc) are made by external developers, and the existence of such tools make the product Flickr even more user friendly.

I bet that in the future there will even be a user-centered and usable application built on Facebook. Nah, just kidding.

Tuning

A lot of websites of today, with old fashioned project-based development, and huge work package releases do not focus so much on tuning of the product. The development is more feature-driven and when one feature is developed and released the development team move on to the next feature and the philosophy of this is easy to understand, but should be avoided. When we run a website, we should tune, tune, tune, tune and tune. This is true for usability, performance, security, conversion rates and so on. By adapting daily releases and Core Teams for Core Products you will be able to tune your product to perfection.

Core Teams for Core Products

Within your website (product) you may have different core products, such as:

• Community
• Signup and User Profile
• The USP (Unique Selling Point)
• Customer Support
• Payments
• Platform

By forming teams around your core products you will get dedicated people working on your product with a big focus on the end-user, and when the end-user is in focus, we will get even better usability, and as the teams are constantly working and blogging about their part of the product they will of course deliver what the user wants daily. This type of organization guarantees that you get people to love your product, both users and developers. But this does not mean that you should arm a fleet for this purpose. Often a small team performs better than bigger ones. It is my strong belief that keeping the number of developers onboard to a minimum will increase your efficiency.

People Dependency

I am going to advocate something that almost everyone who is into organisation and processes dislikes: People Dependency. This is tightly connected to the Core Teams for Core Products thing. By letting people get a bigger responsibility for parts of the product, they will start to care more for that part, and other people in the organisation will know that this person is one hell of a girl/guy to go to when it has something to do with [PROCUCT-NAME]. Responsbility, felt or given, is a key thing when it comes to focusing on users. if you feel that you are responsible for a certain part of the product, you will not let that part die slowly, you will break your neck for giving the users what they demand of you in their blog comments to you.

Product Development not Projects

Die projects, DIE! Often a website can be seen as a product. Products are tuned into perfection and every aspect of the further refinement of the product should be considered product development. The key difference is small steps. By changing something that works in small steps, we guarantee that we at least deliver the quality we had yesterday, but hopefully with a small extra feature, bug fix or other enhancement made, and not as in project based product enhancment, with a big bang that hits the users and reality hard as a rock, and if we are lucky without destroying something that actually worked. Users are not better of with a new product every 10 months, they are better of with a fine tuned product development cycle that focus on giving users something every day in order to make their experience better.

No extra features

By giving users something every day, does not mean that we get feature creep and start adding new functionality to our product every day. We should be careful about that. The key of daily releases is tuning of the existing features and maybe even removal of unusued ones. By focusing on creating the best product available it is important that we can give our users the best features available, but no more than they need to complete the tasks they are using our product for. If we start to create extra features we will end up spending a lot of time tuning the things people may not actually use. Of course there are different approaches to this, but I advocate the few features approach. I think that few features makes it easier for the user to understand what you are offering, and your product will become more sticky to them. But features is a big thing for argument, just compare Zune with iPod. 37signals.com advocates the introduction of fewer features as well in order to create better products for the end user.

User Input based on Analytics and Statistics

This may sound like something that is actually not worth mentioning but it has been known to happen that people sometimes makes assumptions and create things from these assumptions only to be proven wrong. Do not get me wrong, I believe that we must do this in order to find new cool products, but I also believe that we can create more usable products by using all statistics and analysis we can get our hand on in order to getting to know our product and end-user better. But we do not want to get stuck in some Business Intelligence/CRM-crap organisation that makes it impossible to fart without asking the stats first. We want to be agile, and then all of this intelligence must be agile as well. Everyone working on a product should have access to this kind of data, because a marketing manager may draw one conclusion from the data, an analyst one conclusion and a developer another. By making this data available in the organisation end users gets a better product. We must not hide such information for a few managers.

Conclusion

Start blogging, create small teams based on your core products, stop calling people usability experts, start listening to your users, remove features that is not needed, start tuning, focus on product development not projects, release something everyday, create API:s for your content and tune, tune, tune, tune. This will make your product usable.

And remember, there are no such thing as usability experts. Only users.