Millions of sites and systems in the world are exhausting to use, very ugly and filled with features that are not needed by anybody. But there are glimmering exceptions where everything just seems to be working smoothly together. What makes the difference? Is there a secret formula? In this post I will let you in on some of those secrets. Creating usable applications is within your reach, but only if you are willing to make usability your number one priority!
I was invited to give a seminar a few month ago. The topic was “The necessity of a good-looking, well functioning web site”. A first, the title made me uncomfortable because it is such an obvious statement. I mean, who does not want a good-looking and well functioning site? On second thoughts however, I asked myself : “How many of the system owners in the world actually have one?” Isn’t the obvious conclusion then that just wanting one is not necessarily give you one?
So, the big question is: “If you want good-looking site or system badly enough, what should you do?” I have worked with more development projects I can remember and have experienced fiascoes as well as great successes. My conclusion is that the biggest secret behind great sites and systems has to do with how you prioritize the resources and organize the work. The work needs to be focused on maximizing the user value or the end result will be a mess.
In the past a computer program was created with little or no concern for the users. The technicians made the systems and the humans had to adapt to it. This reality does not exist any more. Since the introduction of the first PC and then the Internet into our everyday lives we simply are not willing to spend the time and effort to learn how a system works. Instead, the systems and the people that create them need to learn to adapt to how the users work. But herein lies a problem. Programmers are good with machines but usually not so good with people.
Today, input from people with other skills and knowledge is absolutely necessary in a software project, in order to fulfill the users needs and make it easy to use. People with business development and marketing skills, experts on computer-human interaction and graphic artists are suddenly as equally important as the programmers. In some cases even more important.
I believe strongly that all expertise needs to be allowed to contribute to the end product. The technical solution cannot be separated from the interface or from the business model behind the system. They all have to dynamically merge together with the end in mind. If the developer comes up with a brilliant technical innovation then the interface may need a slight redesign, or if the interaction designer finds a way of doing a task more easily it will affect how the features need to be developed.
Such a process demands that the team members are allowed to interact with each other and gradually build solutions based on each other’s input. These solutions are constantly improved by adapting and adjusting all aspects of the concept when new information and input become available. In each step of this process every one involved needs to focus on creating the best possible user experience and at the same time remember to preserve the project budget.
So now the next big issue: In order to make this happen the teams must work very closely together and let go of traditional interdepartmental boundaries. In order to get it right you have to give up the old project management methodologies that do not work as well. Classic waterfall production methods cannot be applied if the end result is suppose to be beautiful and usable. Agile development is one step in the right direction, even though I think that the agile methodologies need to involve everyone in the team, not only the developers.
One secret I share with my clients is how to put their focus on the user experience by ensuring that the features offered and the design of the system makes sense to the users. Because, if it doesn’t, the users will go elsewhere.
When you develop the software, start with the big picture and make sure that it is complete before starting to detail the separate parts. Throw away the piles of pages of system requirements. Start with tangible visualization techniques to get an overview of the system that everyone can understand. Be willing to go back and change the things that in a later stage do not make sense anymore. Simplify, simplify and simplify until you get it simple enough for the intended audience. Ask the users before you think you know what to do. Test solutions on real users before finally deciding. Be willing to redesign the system even in late stages of the development.
The good news is that when you start by focusing on the users, all other parts will fall into place. Remember, it is not what you want, it is what the users need that matters in the end.