Книга: Психбольница в руках пациентов (+конспект)

Больше года уже планировал прочитать эту книгу, но постоянно откладывал. Среди менеджеров по разработке сайтов она считается обязательной к прочтению. Так ли это и причем здесь психбольница – давайте разбираться.

Глобально книга состоит из двух частей. И на первую часть отведена реально половина книги. В первой части автор очень красноречиво передает свою боль о том как в данный момент проектируются интерфейсы. Под его критику попадает все: продукты Microsoft, меню телевизора, будильники, цифровые фотоаппараты и даже брелок от автомобиля.

В первой части автор пытается донести на сколько важно подходить ответственно к проектированию, как это упрощает и сокращает этап разработки. В конечном счете можно даже позабыть про срок сдачи проекта, ведь если вы выпустите удобный продукт – он в любом случае понравится, а если вы сделаете не удобный, то никому не будет дела, что он сделан вовремя.

Индустрия высоких технологий по недосмотру поставила во главу программистов и инженеров, поэтому доминирует их сложная в применении инженерная культура.
Несмотря на кажущиеся полномочия, люди на руководящих постах попросту не контролируют индустрию высоких технологий. Этим шоу заправляют инженеры. В своем стремлении принять многочисленные преимущества кремниевых микросхем мы отреклись от ответственности. Мы позволили пациентам завладеть психбольницей.

Хотя первая часть сильно затянута, с автором сложно спорить. Всем нравятся вкусные и удобные продукты. О том как их создавать рассказывается во второй части книги. Подход к проектированию расписан не так чтобы очень подробно, но подход автора понятен.

Перед реализацией всегда должен идти черед проектирования. Первый шаг проектировщика – это определить ключевых среднестатистических пользователей. Такому пользователю обязательно дается имя, место работы, придумывается стиль одежды, привычки, марка авто и расписываются его типичные цели.

Под каждого пользователя должен быть свой интерфейс. Вот почему автор считает, что в проекте не должно быть более трех типов пользователей. Если вы хотите создать проект удобный для всех – то скорее всего он станет неудобным ни для кого.

Алан упоминает о интересном исследовании, в ходе которого выяснилось, что люди при работе с компьютером воспринимают его как человека. Думаю вы и сами не раз замечали как вы или ваши коллеги пытались уговорить компьютер работать быстрее или ругались на очередное диалоговое окно. Все мы знаем, что это бесполезно, но ничего не можем с собой поделать.
В этом ключе рекомендуется создавать интерфейсы, которые будут имитировать поведение вежливого человека.

Программы постоянно скулят при помощи диалогов подтверждения и хвастают ненужными строками состояний. Я не желаю слышать о том, насколько тяжело трудится компьютер, это излишняя информация. Меня не интересует, что у программы проблемы с уверенностью в себе, когда она не может решить, очищать ли мусорную корзину.

Чтобы сделать программу вежливой, следует ориентироваться на следующие пункты:

Вежливая программа интересуется мной
Вежливая программа относится ко мне уважительно
Вежливая программа обходительна
Вежливая программа ведет себя разумно
Вежливая программа предвидит мои потребности
Вежливая программа отзывчива
Вежливая программа не склонна делиться своими личными проблемами
Вежливая программа в курсе происходящего
Вежливая программа проницательна
Вежливая программа уверена в себе
Вежливая программа всегда сосредоточенна
Вежливая программа покладиста
Вежливая программа дает мгновенное удовлетворение
Вежливой программе можно доверять

Принцип здесь очень простой: Разрешайте человеку делать, что ему угодно, но храните очень подробные записи об этих действиях, чтобы можно было с легкостью восстановить ход событий (например восстановить удаленный файл).

При проектировании каждый шаг должен быть зафиксирован в документации. Описание сложно включать в себя все исчерпывающие подробности и примеры. Разумеется оно должно быть представлено разработчикам и восприниматься как чертеж, а не как руководство. Достаточно детализированная спецификация по объему неотличима от кода, эта документация реализующего.

В итоге проектировщик отвечает не только за удобство использования будущего продукта, но и за качество проекта в целом. Именно проектировщик работает со списком функций и графиком разработки.

В целом с автором сложно спорить. Он проводит отличную параллель с кинопроизводством, в котором львиную долю занимает проектирование. Еще до съемок прописывается не только сценарий и диалоги, а так же положение предметов в кадре, кто как будет выглядеть и как двигаться.

Даже не смотря на то, что книга в некоторых местах слишком затянута, она по праву считается must-read для руководителей проектов.

Вся полезная информация о проектировании у меня уместилась на 12 страничках. Если нет времени читать всю книгу, то можно скачать конспект “Заметки по проектированию”.