Today's Story: The Brains on the table, The Master Race, and The Keyword Usability

*** I posted this to Star Control  section since the game's development process is currently on the way and in the early stages if I understood correctly. In addition all the posts I post are related to Star Control anyway 'cause it's the only thing on these forums I'm interested in currently.***

1. The Story so far..

Once upon a time in the land ruled by a master race, there was an office, where a particularly nasty piece of software were being developed. During a lunch break, the notorious post delivery guy dropped a mysteríous, sealed box on the conference room table. After a while one of the office's primitive inhabitants noticed it, ripped it open hastily seals and all, hoping to find some Creme Milk Chocolate Donuts and Grande Skinny Decaf Latte cups. However, to its surprise there was something actually interesting there: freshly harvested brains! The brains were just lying there at the bottom of the box peacefully, bleeding statistically insignificant amounts of blood. Next to the brains there was a note which read "This is a usability problem. Call the surgeon!". So the confused inhabitant did as the note commanded, and that's how it all began.

2. The Problem

"I suppose it is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail." - Maslow, a famous psychologist (1966)

Well, my hammer today is The Usability Hammer of Unforgivenessful and I will be hammering around like there is no tomorrow while sharing with you some of the nails I've found along the way. I will also tell you how brains should not be dissected later on and what the SW development master race actually is. You will see how all these things are connected with each other.

The problem is, that when designing almost anything the product will live in the designer's mind. That's why the designer will always see the vision and the model of the product, not the actual product. That is *funny*. You think you *see* Orz but Orz are not *light reflections*. Okay.. please forgive me my Orz. Anyway, that's why a designer thinks that the product is more understandable and better than it actually is often. It is impossible for the designer to see the product as a new, mysterious, and unknown thing, from the user point of view. The knowledge about users can be acquired however, but acquiring it is not simple, easy or cheap.

3. Bring Forth The Scalpel!

The previously mentioned problem is the reason why the team needs to have the fresh brains of an end-user/users on the table for dissection, for everyone to see. The dissection should be done publicly by a usability/UI/UX expert, otherwise you'll only end up with blood on your hands, mess on the table and splatters on the curtains. This dissection event should not be seen as a one time amusement which you could just do hastily and then rush into your office to break something else. This surgical operation needs to be researched all the time during the development process, from the very humble beginnings of the process until the very end. Every iteration done without proper and current user/usability knowledge enlarges the gulf of unknown between the product and the user, i.e. the risk of making misguided decisions grows. Every iteration strengthened with the usability knowledge ties the user and the product together more firmly decreasing the amount of nasty surprises. Don't do it wrong because you don't want to guess and gamble with the features and implementations any more than it's necessary.

4. Too many minds

The proper and current usability/user knowledge is one of the necessary tools needed in decision making. It's easier to lead the process forward when you know your target audience, i.e. what makes the user happy. After all, the sw development process is not a creative process of producing funny things out of thin air. It's a process of producing things accepted, welcomed and enjoyed by the users. Have all hands on deck early on and don't lose the sight of the user amidst all the strategy, agile process, leadership, matrix organisation, innovation and techno mumbo-jumbo (*1).

You will want to avoid the idea of pleasing people around you and the idea of making a product which makes the boss happy, you happy, other designers happy, everyone in the office happy, or various experts happy. The only one who fits into your head properly is the user and with that all the things that will make him/her/it happy. All that pleasing of others is for nothing when the product fails with the users, the money isn't being generated and everyone gets sacked, cursed and burned on a bonfire. The efficient use of the usability knowledge ensures that the available skills and resources are used to produce a product for the user, not for anyone else. When everything is moving toward the user, then you can think about making someone else happy as well.

5. Expendables and Irreplaceables

Designer does not equal user. If you are a designer writing the code for example, the ultimate algorithm you are working on right now, it's not for you. Your efforts won't matter if they don't serve the will of the user. The designer is the puny slave working for the user master race. Any designer should be able to clearly separate his own wishes/wants/needs of those of a user. It might be a good practise to map out the wishes/wants/needs of various stakeholders (including oneself), write them down on a paper and find a way to balance between them without sacrificing the user's part. Maybe staple that paper to your forehead as well, just to be sure.

6. Are You Surgeoning or Bleeding Moneys?

All these attitudes & principles go well with the well-known fact that projects that skimp on upstream activities for example, typically have to do the same work downstream at anywhere from 10 to 100 times the cost of doing it properly in the first place (*2). So call your trusted surgeon, get the brains from the freezer and dig in before it's too late. Additionally, this all goes well with the famous (overused) usability article about the $300 million button (*3). The article tells a true story about a situation, where designers thought everything was functioning well, but there was this tiny problem with the UI. Don't make a $300 million mistake, it might not look nice in your CV.

Donald Norman and Jakob Nielsen are well known gurus in the field of usability and hopefully everyone has heard about them. However a quite short book I recommend for everyone to read is not written by either of the previous two. If you are interested about usability, read "Psychology of Usability" (*4) to get an idea about what the interdisciplinary thing called Usability is and also to see where some of the usability principles of this post come from.



That's all for now. Hopefully the Star Control project is going well and everyone is *smelling* *pretty colors*!

References

*1 Coplien and Bjørnvig (2011). Lean Architecture for Agile Software Development. http://www.google.fi/books?hl=en&lr=&id=tW7Ux9fA7nMC&oi=fnd&pg=PR12&dq=lean+management+agile+software+development+process+book&ots=loRS9tHuw7&sig=trBqv8lqVQ21dPcLKAi8LvTnEjc&redir_esc=y#v=onepage&q=lean%20management%20agile%20software%20development%20process%20book&f=false

*2 Fagan M.E. (1976). Design and code inspection to reduce errors in program development. IBM Systems Journal, 15, 182-211.
*2 Boehm and Papaccio (1988). Understanding and Controlling Software Costs. IEEE Transactions on Software Engineering, 14, 1462-1477.
*2 Wetland (2002). The cost of errors in software development: evidence from industry. The Journal of Systems and Software, 62, 1-9. http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.88.1508&rep=rep1&type=pdf

*3 Spool (2009). The $300 Million Button. User Interface Engineering. http://www.uie.com/articles/three_hund_million_button/

*4 http://www.amazon.com/Professional-Psychology-Usability-Irmeli-Sinkkonen/dp/9518266492