This book from Alan Cooperdiscusses the advantages of using goal oriented design to create good products. I think it is a must read for all programmers, designers, project leaders and managers as well. By using a lot of examples from the field, this book explains why designing your software is important and why you must use specialist to do the job. But beware, some parts of the book might be to confronting to some readers.

The first part of the book introduces you into the dancing bear and cognitive friction. Cognitive friction deals with people feeling stupid while using products like tape recorders, tv sets, computer programs, etc. This all has to do with the Dancing bear products.

A dancing bear is someting wonderous to see. Not that the bear can dance well, but the fact that it can dance at all. The same is valid for a lot of software. The programs don’t do a good job, but the fact that it works and makes the users life much simpler makes him forget that it can be even better. This is what is called cognitive friction, the fact that products we use on a daily basis are hard to use. People dealing with cognitive friction tend to fall into two groups:
apologist :
make excuses for the creators since they can make the programm do something they could not do before.
survivors :
they know something is radicully wrong, but they do not know what.

The apologists say, “look a this, a dancing bear!”. The survivors say, “I need something that dances, so i guess a bear is the best I am gonna get.”.

Ofcourse the solution for the dancing bear is a good design upfront.

The second part of the book is interesting from a project management perspective. One of the issues is about deadline management. To often managers rather ship a failure on time than risk going late. If the product is great, being late is not a problem very long. Another issue with deadline management is the requirements. How many of you have working with these long feature lists. To often programmers determine how long it will take to implement a feature. Then some of the features will be out of scope and others won’t. Programmers have a very big influence on this process. It would be way better to let the Personas goals determine which requirement is within scope, since these goals are the only important thing for the product. If you find it hard to separate features from goals, the book gives a nice example:
Students must write down the type of product as soon as possible based on provided features.
1. internal combustion engine
2. four wheels with rubber tires
3. a transmission
4. a steering wheel

A lot of students will now write down a car, then the following two goals are given
5. cuts grass quickly and easily
6. comfortable to sit on

Therefor goal oriented design will point you to the right direction and most often better solutions.

The next section explains why programmers ‘Homo Logicus’ can never be good designers. This was sometimes confronting to me, and therefore a very good read. One thing that I remember is that programmers use the implementation model for designing user interactions. This way the program does not mirror the end users goals, it reflects the mechanisms within. The most important part is that programmers create programs they would like as users. They put in a lot of features that they think are cool or good to have. Usually these do not support an end users goal.

Another problem in the current software world is that most of the project leaders are former programmers. Designing is not there nature. If a designer is on the team, most of the time he is not the one taking the desisions about what is in and what not. In the end it is the programmer that has the power. He takes the design as a guidance, while it should be the law. This way, if you have a designer, he can create the greatest design, but it must be followed by the programmers.

The next part of the book is very interesting. It gives you some guidelines about the way to get a good design.
The biggest thing to talk about is the creation of personas. From conversations with the stakeholders a number of personas are created. One very important thing is that the end user does not directly affect the solution. It can only be that one of the personas get an extra or more specified goal. Personas are not real people. The personas have there goals in there work. When designing a product usually a large number of personas are taken and they should all be satisfied. It turns out that this is wrong. The best products are designed for 1 persona. Let me explain this with an example. As a car company, you want to create a new car. You have three personas: Wendy is a mother of three children, she uses the car to get the children to school. Fred is a salesman that uses the car alone and is a lot on the road. He likes to ride sportive. Then we have Henk, who has his own construction company ans needs to take a lot of tools with him. Trying to please them all would lead to a very strange car: a convertable van with room for kids and large tools. It would be way better to create three different cars. The same is valid for software. You need to define your primary personas. These are the personas you design for. You can have a maximum of three primary personas per product. In theory you should design a different interface for each primary persona. When documenting the requirements for the system, you do not write down features anymore, you create personas and there goals.

The books continous explaining about the goals the personas can have and how to find these goals:
- Personal goals (not feel stupid, not make mistakes, have fun)
- Corporate goals (increase our profit, defeat our competition, offer more products or services)
- Practical goals (avoid meetings, handle clients demands, record clients orders)
- False goals (run in a browser, be easy to learn, speed up data entry, use cool technology or features)

The final part of the book tells you more about designing with the software development process. The most important lesson here is to design first and well, stick to it while programming and create good products.

This is a very short introduction into the book, I am very enthousiastic about the book. Ofcourse you can find it at amazon, please use the link below and support me.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>