Front-End Book

The iPhone is getting more and more popular around the world, and soon we will see mobile phones implementing Googles mobile platform Android. For years we have been waiting for the mobile revolution on the web, but the revolution has been more like a breeze with 3G-enabled services for small screens and the Blackberry-concept. In order to make the revolution speed up we need molotov-cocktails such as usable services, standardized platforms, large user base and a change in behaviour. With iPhone and Android, this is what is about to happen.

In this article we have choose to focus on four areas of the web that will change when the mobile revolution starts.

Technical

Anyone who has ever built or run a web serving platform, knows that multiple platforms are a bad thing and adds to complexity and maintenance time and money. In order to serve both traditional web and web for iPhone and Android, changes to the platform will be necessary (Of course, there are always someone who “took aim” for this in their platform when building it). The biggest changes we will se is an even stricter separation of the presentation layer from the business layer. In order to make a platform able to serve x number of types of devices, we need to make sure that nothing in the business layer makes any assumption on what type of presentation device it will be serving the generated content. The presentation layer must be able to choose the correct presentation resources and device-specific services such as payment methods, social bookmarking tools etc.

Usability

When moving services to a mobile platform, focus tends to move to ease of use and effective use of the service, trying to maximize the usability of the service. It is not as convinient to type on a mobile phone as it is on a keyboard, even if iPhone has wonderful mechanisms for scrolling, zooming and changing viewport orientation, it is still far more difficult to navigate the web via an iPhone then it is with a fully featured web browser on your desktop OS. In order to minimize the effects of these short comings, focus on easier and more focused services will be the case. This will of course effect the services we use daily on the desktop web as well, why should I stick with a semi-usable product on the web, when I know the service provider can do better.

Advertising

There are two things with mobility and platforms such as iPhone and Android that will revolutionize the advertising possibilities on the web.

The first and most obvious is of course mobility itself. With positioning it will be easy to target your advertising on the mobile web geographically making conversions more likely and advertising space bigger. Of course geographical targeting is available today as well, but not to the level of detail possible with mobiles using GPS. I believe this will help to increase advertisers and publishers revenue from ads greatly if implemented correctly.

The second possibility opening up is ease of payment. Often when a transaction take place on the traditional web, credit cards or solutions such as paypal are used, adding to the complexity of making a buy, sometimes even customers bounce due to the fact that they feel it is to much hassle to grab the VISA-card or finding the password for your online bank solution. With platforms such as iPhone and Android implementing transparent payment solutions will make conversion rates pop due to the fact it will be easier for the user to actually make a buy, the integration of the purse into the platform makes a buy more like an ordinary buy in a store. On top of platform solutions for payment, mobile phone operators may implement solutions where they charge the user on the next bill. This is a win-win situation for the operators and the users, operators can start charge percentage on credits not payed within 30 days, and the users get a free payment option, as long as they pay within 30 days. I believe this is where mobile web will revolutionize the web the most.

User Expectations

As soon as the iPhone and Android-enabled web services have grown in numbers, user base and revenue people using these services will start to expect all good services they learnt to like on the desktop web will be available and mobile enhanced. This change in expectations will effect market shares in the long run, as the web services able to adapt and serve mobile services as well as the old plain web services will get more users and bigger revenue.

Conclusion

iPhone and Android will change the way we build, use and monetize web based services. The mobile revolution has just begun, and it is important for companies acting on competitive markets online to implement solutions for their customers, because they will start to expect that mobile services are a natural complement to their traditional web service. These days are interesting times.

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.