Дизайн привычных вещей. Дональд Норман

Ссылка на OZON.

Я давно ждала эту книгу! Когда-то давно о ней благосклонно отозвался Дизайн-линчер, который делает рассылку про дизайн интерфейсов. Мнению Антона я верю, поэтому полезла на Озон, а там... Пусто :-( Книги нет. А читать электронные я не люблю, мне же пощупать книжку надо...

Шли недели, даже месяцы. Но у меня дома еще стопка непрочитанных книг, так что я не торопилась. А потом книга начала всплывать перед моим носом. Например, в коворкафе Горбунова аж две бумажные книги Нормана! Я спросила: могу ли взять почитать? Нельзя ((( Можно там сидеть и читать, ну как-то не клево. Ходила облизывалась. Мелькали даже крамольные мысли утащить одну по тихому, прочитать и вернуть. Собственно, коворкафе пробудило интерес к книге и я даже уже решила купить электронный вариант, как тут она появилась в продаже! Разумеется, я тут же ее купила! О чем не жалею 

Книга — must read для тестировщиков, которые интересуются тестированием usability. Она учит отстаивать интересы пользователей. Она учит тому, что очевидное для разработчика нифига не очевидно простому пользователю. И это — нормально! Это не значит, что пользователь тупой. Это значит, что систему можно сделать лучше.

Правда, варнинг! Читать надо, включая мозг  И применять в реальной жизни тоже. А то у меня на курсе у студентов фантазия и так скачет в бескрайние просторы вселенной. «Это мне непонятно, тут неудобно, поэтому давайте срочно исправлять, да еще с большим приоритетом!». Представляю, как они радостно потирают ручки и показывают мне этот пост: «Но вы же сами писали, что, если пользователю неудобно — это проблема дизайна. Нормальный usability-баг, принимайте!». Нет, дорогие, увы и ах, но все космолеты мы закрывали и будем закрывать. Надо с младых ногтей учиться тому, что некоторые баги никто править не будет. И не все должно быть доступно простому смертному (например, документация по АПИ биг-боссу, ну зачем?)


Но это уже вопрос переговоров и умения обосновать свою задачу. Да, когда мы видим продукт впервые, у нас свежий, незамыленный взгляд. И мы можем найти места для улучшения. И даже поставить задачи. Но надо принять и тот факт, что их могут закрыть. Увы, такова жизнь. Можно пойти к аналитику и узнать, почему. Обсудить. Попробовать обосновать свою позицию. Если позиция аналитика: «Оля, это фигня, кому оно надо вообще?», то стоит задуматься. Может, он прав?

Если вы уверены, что есть реальная проблема — ищите доказательства. Не мифические "а если луна повернется вспять и трижды обойдет вокруг солнца, черный кот перебежит пользователю дорогу и он придет к нам на сайт злой?!», а реальные сценарии. И предлагайте решение, такую задачу рассмотрят в бОльшей вероятностью, чем «Тут плохо, сделайте хорошо. Не знаю как, главное, чтобы мне понравилось».

Если проблемы нет, то, может, оно и правда того не стоит. Все баги не найдешь, все не исправишь. А что-то просто бесполезно исправлять, потому что времени потратишь много, а выхлоп минимальный. Свои ресурсы тоже надо ценить. Но и делать абсолютно неиспользуемую фигню — тоже плохо. Конечно, не всегда тестировщик может на что-то повлиять, но тут уже ваш выбор, работать там, где на качество совсем начхать или нет (но не путайте "совсем начхать" и "они игнорируют мои минорные предложения!").

Однако вернемся к книге. Что полезного рассказывает автор?

==============================================================

Принципы дизайна:

1. Концептуальная модель — вещь должна говорить сама за себя. мы ищем смысл во всем. Если мы не знаем, как что-то работает, мы придумываем модель сами. И проверяем свою теорию. Важно, чтобы она совпадала с реальностью. Мы входим в помещение, нам холодно, мы включаем обогреватель на максимум, думая, что так комната быстрее нагреется — а вот и нифига. Это как раз яркий пример неправильной концептуальной модели =)
2. Обратная связь — очень важно, чтобы был виден результат действия. Вот раньше ты звонил и слышал тихий шум. Это напрягало, но ты хотя бы точно знал, что разговор идет, ты не повесил случайно трубку. Сейчас связь бесшумна, но и обратной связи нет.
3. Ограничители — чтобы сделать вещь простой в примененении, нужно исключить все возможные неверные действия, то есть ограничить их выбор. Пытались воткнуть флешку не той стороной? Вот вот. При это воткнуть ее поперек вы наверняка не пытались, потому что наглядно видели ограничение, длина не войдет в ширину =)

Наглядность и обратная связь:

1. Наглядность. Сделайте так, чтобы важные детали были видны.
2. ОС. Сделайте так, чтобы результат действия был заметен сразу.

Увидев что-то новое, мы начинаем действовать, руководствуясь ответами на следующие вопроса:

• Какие детали подвижны, а какие закреплены?
• За что можно взяться? Какую деталь нужно двигать? Какую нужно держать? Куда вставлять руку? Если устройство реагирует на голос,, куда нужно говорить?
• Какое телодвижение возможно: от себя, на себя, поворот, разворот, прикосновение, удар?
• Каковы основные физические характеристики телодвижений? Какую силу нужно прилагать к предмету? Как далеко его можно передвигать? По каким критериям оценивать успешность действия?
• Где находятся опорные поверхности? Предметы каких размеров и тяжести они смогут выдержать?

Вот очень точно написано. Я вроде ит-шник, но тоже боюсь всего нового. Когда начинаешь тыкать какую-то новую программу, всегда так страшно! А вдруг я нажму вот сюда И ОНО СЛОМАЕТСЯ? Или удалится? А как исправить? Вдруг необратимые последствия будут? Исследовать страшно.

Чтобы система была исследуемой, она должна отвечать 3 требованиям:

1. В любой момент времени пользователь должен видеть доступные действия и иметь возможность выполнить их. Наглядность играет роль напоминания о наличии действия и призыва к исследованию новых приемов.
2. Результат каждого действия должен быть очевидным и легко интерпретируемым. Это позволяет изучить последствия каждого действия, создать хорошую концептуальную модель системы и понять причинно-следственную связь между действиями и их результатом.
3. Действия не должны наносить вред. Должна существовать возможность отменить действие, которое приводит к нежелательным последствиям.

==============================================================

Книга написана еще до моего рождения, но остается актуальной до сих пор. А все потому, что автор не привязывается к конкретным технологиям. Он рассматривает дизайн простых вещей, с которыми мы сталкиваемся постоянно — дверь, включатель света, радиомагнитола и т.д.

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

Автор говорит о том, что людям свойственно ошибаться, но они винят себя в этом. «Это я тупой, а не дизайн» ©. А, так как казаться глупыми мы не хотим, то и вопросов не задаем. А в итоге дизайнер искренне считает, что все сделал круто. Вопросов то нет!

Ну и конечно, всегда стоит помнить:

Дизайнеры — не обычные пользователи. Равно как и вся команда.
Что удобно нам, у других будет вызывать только вопросы.

Об этом пишут все авторы книг про юзабилити. Но это очень сложно «понять и принять». Как же так? Мне то удобно. Значит, и всем тоже будет. А если не будет — это просто пользователь дурак, умным удобно. Это неверно. Помните об этом!

В общем, книгу рекомендую всем людям, имеющим отношение к ИТ. Она того стоит! Пожалуй, даже оставлю пока в своей коллекции, не буду отдавать, а то ведь просто так и не купишь, вечно нету в продаже!

PS: добавила книгу в общий список прочитанных мною книг.