January 16, 2015 at 12:06Squeezes from “Mental hospitals in the hands of patients”
I recently read Alan Cooper's book, The Mental Hospital in the Hands of Patients. From it I managed to draw a number of ideas on the topic "how to improve development." Below are a number of recommendations from the book that I am adopting. Milfgard
inspired me with this post . I will try to read all the books of interest to me from this list.
I had heard about him before in the presentations of Dmitry Satin and other respected comrades, but I never took him as a guide to action. However, Alan Cooper says that this must be done.
So, the bottom line is to move away from the concept of "user" and move on to real-unreal people. Those. we come up with characters from the real target audience of our product, but at the same time, they should not be real people. For example, for a hotel website, it would be like this:
For such a person it is already much easier to design than for a spherical user in a vacuum, and when the question arises whether she needs a print function, we will answer yes, we need it: Marina will print out information about the reservation and go through the people leaving for a business trip. Or save it in PDF and send it to employees by mail.
Every person who uses our product has some goals. It:
These goals are given in order of priority for people. First of all, personal, and then everything else. If personal goals conflict with corporate goals, personal ones will win in the long run.
It is important to distinguish goals from tasks. To accomplish one goal, we can perform many small tasks, however, we should never forget about the ultimate goal.
It’s good to concentrate on the scenarios of people’s work. This is the thing that allows us to put ourselves in the place of Marina from the previous example. It sounds like this: “I am told the dates of the trip, the employees who need to be sent, and the place where I need to be sent. I’m looking for hotels in this city via the Internet, I will find out prices, available rooms and, if everything suits me, I will book. ”
And there are three types of scenarios:
Programmers usually focus on exceptional situations, but in the case of scenarios, you need to focus on everyday, often repeated actions.
Programmers tend to assume that people have opened our website / program and know what to do here. But the more functions we do with it, the higher the entry threshold. There will be a definite tilt towards a trained audience.
On the other hand, executives and sales managers, by contrast, underestimate the ability of users. They think that they need to chew, show and do everything as simple as possible. Roll towards an unprepared audience.
The correct one will count on the middle peasants. Preliminarily, of course, having determined who these very middle peasants are.
It is important to remember the frequently used functions and make them as accessible as possible. Rarely used functionality can be hidden. Microsoft tried to introduce such an approach in its MS Word, starting with the 2007 version, however, with a detriment to the rare functionality that now can not be found.
Often the same concepts by different participants in the process can be interpreted differently. The client may mean one thing, and the developer is completely different. For example: "On my site should be able to buy custom research." If you ask the client about the possibility of payment, he will answer that the price of a custom study is not determined in advance and, therefore, you can not pay for it on the site. It is better if the application is sent to the post office. Thus, we have just abandoned the purchase / payment functionality with all that it implies, simply by specifying the term “buy”.
One of the most important things is interaction design. Interaction designers who prepare scripts, think about people, etc. should be responsible for the success of the project. From the programmers with the approach “Designing UI → Design → Programming → Testing” responsibility for the overall success of the product is removed.
It is important that everything that the designers have designed is carefully documented. Then you can always re-read and understand whether we are moving in the right direction. The documentation necessarily uses the names of characters developed by the person method.
PS: We ourselves still do not really apply any of these principles completely (but really want to) and it will be interesting if those who read this book share their experience in implementing these principles in the comments.
inspired me with this post . I will try to read all the books of interest to me from this list.
1. Person method
I had heard about him before in the presentations of Dmitry Satin and other respected comrades, but I never took him as a guide to action. However, Alan Cooper says that this must be done.
So, the bottom line is to move away from the concept of "user" and move on to real-unreal people. Those. we come up with characters from the real target audience of our product, but at the same time, they should not be real people. For example, for a hotel website, it would be like this:
Marina, 25 years old. Office manager of a small company of 30 people. She works in the bright Moscow office during the day and she likes everything. Responsibilities: maintain a good atmosphere in the office, ensure that everything works, prepare business trips and draw up documents for this: book hotel rooms and book tickets. Most decisions are made independently, giving for signing only the final bill. Good husband and three year old daughter.
For such a person it is already much easier to design than for a spherical user in a vacuum, and when the question arises whether she needs a print function, we will answer yes, we need it: Marina will print out information about the reservation and go through the people leaving for a business trip. Or save it in PDF and send it to employees by mail.
2. Remember the goals
Every person who uses our product has some goals. It:
- personal (not to feel silly, not to make mistakes, to perform an adequate amount of work, have fun);
- practical (avoid meetings, meet customer requirements, keep order history, call back customers);
- corporate (increase profits, defeat competitors, recruit staff, open two more stores);
- false (easy to learn, save memory, improve appearance, speed up data entry).
These goals are given in order of priority for people. First of all, personal, and then everything else. If personal goals conflict with corporate goals, personal ones will win in the long run.
It is important to distinguish goals from tasks. To accomplish one goal, we can perform many small tasks, however, we should never forget about the ultimate goal.
3. Scripting
It’s good to concentrate on the scenarios of people’s work. This is the thing that allows us to put ourselves in the place of Marina from the previous example. It sounds like this: “I am told the dates of the trip, the employees who need to be sent, and the place where I need to be sent. I’m looking for hotels in this city via the Internet, I will find out prices, available rooms and, if everything suits me, I will book. ”
And there are three types of scenarios:
- Everyday (They are the most useful and important. The actions described in them are performed most often);
- Mandatory (They can be used rarely, but the possibility of their use must necessarily be. For example, urgent reservations with cash advance payments from legal entities or cancellation of reservations);
- Exceptional situations (They are developed last and can be hidden in the depths of the interface. Example: Marina has a broken keyboard, but she needs to book a room immediately).
Programmers usually focus on exceptional situations, but in the case of scenarios, you need to focus on everyday, often repeated actions.
4. Product for average audience members
Programmers tend to assume that people have opened our website / program and know what to do here. But the more functions we do with it, the higher the entry threshold. There will be a definite tilt towards a trained audience.
On the other hand, executives and sales managers, by contrast, underestimate the ability of users. They think that they need to chew, show and do everything as simple as possible. Roll towards an unprepared audience.
The correct one will count on the middle peasants. Preliminarily, of course, having determined who these very middle peasants are.
5. The main thing - the main thing
It is important to remember the frequently used functions and make them as accessible as possible. Rarely used functionality can be hidden. Microsoft tried to introduce such an approach in its MS Word, starting with the 2007 version, however, with a detriment to the rare functionality that now can not be found.
6. Agree on a common dictionary
Often the same concepts by different participants in the process can be interpreted differently. The client may mean one thing, and the developer is completely different. For example: "On my site should be able to buy custom research." If you ask the client about the possibility of payment, he will answer that the price of a custom study is not determined in advance and, therefore, you can not pay for it on the site. It is better if the application is sent to the post office. Thus, we have just abandoned the purchase / payment functionality with all that it implies, simply by specifying the term “buy”.
7. Interaction design and detailed documentation
One of the most important things is interaction design. Interaction designers who prepare scripts, think about people, etc. should be responsible for the success of the project. From the programmers with the approach “Designing UI → Design → Programming → Testing” responsibility for the overall success of the product is removed.
It is important that everything that the designers have designed is carefully documented. Then you can always re-read and understand whether we are moving in the right direction. The documentation necessarily uses the names of characters developed by the person method.
PS: We ourselves still do not really apply any of these principles completely (but really want to) and it will be interesting if those who read this book share their experience in implementing these principles in the comments.