Алан Купер — дизайнер и разработчик из США. Отец Visual Basic — языка программирования, на котором до сих пор работают макросы Office. Как личность сильно неравнодушен ко всему удобному. По крайней мере такое впечатление создается уже после чтения первых глав. Вероятно, мятежный дух и питал его новаторские устремления в попытках сделать интерфейсы лучше, практичнее и подчинить их человеку (а не наоборот).
Всем, кто хотя бы раз злился на технику
Книга понравится всем, кто любит поворчать. С ходу Алан ругается на будильники с лишними опциями, сложный интерфейс банкомата в его районе и цифровую фотокамеру, которая на последнем издыхании заряда зачем-то сфотографировала его ногу. Получается очень смешно: «…Далее я выбираю подходящий ракурс и приближение камеры для получения наилучшего кадра. И в тот самый миг, когда мой палец почти нажал на спуск, камера вдруг решает, что одновременное увеличение кадра, питание вспышки и поддержание яркости экрана принимает ответственное решение: уменьшить нагрузку. В результате этого энергоемкий LCD-экран гаснет. Я недоуменно гляжу на камеру, пытаясь понять, почему не получилось сделать снимок, пожимаю плечами и опускаю руку, в которой держу камеру. Однако сэкономленная на отключении экрана энергия позволяет дополнительно запитать другие элементы камеры. У программы управления питанием открывается «второе дыхание», и она решает, что прямо сейчас энергии хватит, чтобы сделать снимок. Она посылает сигнал основной программе, которая терпеливо ждет момента, когда можно будет продолжить процесс фотосъемки и выполнить ранее посланную мной команду сделать снимок. В результате камера делает великолепно сфокусированное, безупречно экспонированное высококлассное цифровое фото моего колена».
Снова прикладная когнитивистика
Мы уже писали о том, как круто получаются цифровые продукты, если программист думает о пользователе (или как пользователь). Что удобно — что не так чтобы удобно. Что необходимо оставить в интерфейсе — а чем можно пожертвовать в угоду позитивному юзабилити. У Купера эта тема раскрыта через понятие когнитивного сопротивления. «Это такое сопротивление, с которым сталкивается человеческий ум, когда ему приходится разбираться в сложной системе правил, меняющихся в зависимости от поставленной задачи», — пишет автор и следом уточняет, что коэффициент такого сопротивления высок, когда человек сталкивается с программами. Грубо говоря, разобраться с механическим будильником проще, чем с электронным.
Но есть проблема. «Экспертам в программном обеспечении приходится привыкать чувствовать себя комфортно при высоком уровне когнитивного сопротивления. Они с гордостью восхваляют свое умение выполнять рабочие задачи, несмотря на неудобства», — уточняет Алан. И вот здесь, конечно, кроется боль пользователей. В итоге ведь продукт для обычных людей. Есть о чем подумать изобретателям и проектировщикам.
К слову, о проектировщиках
Алан Купер отмечает: «Значительному количеству разработчиков программных продуктов неведомо, как создавать удобные в использовании программы, но вместо этого им хорошо известно, как пичкать их новыми опциями, потому они делают именно это». Не согласимся с таким обобщением.
Однако в книге есть довольно интересный пример того, как делать не надо.
Вот так автор рассказывает про свой двухкнопочный, но излишне навороченный ключ: «Говоря о системе бесключевого доступа в моем автомобиле, я сильно сомневаюсь, что хоть кто-то из ее проектировщиков спросил себя: “Какие функции будут нужными и сколько их должно быть?” Напротив, я больше чем уверен, что какой-то младший инженер взял типовую микросхему, которая, по “счастливой” случайности, оказалась двухканальной. Один канал он приспособил для блокировки и разблокировки, а затем вспомнил, что у него есть еще один, лишний “бесплатный” канал. Этот инженер, вполне вероятно, будучи под началом инициативного менеджера по маркетингу — полного энтузиазма, но плохо информированного, — вообразил кажущуюся ему логичной схему, что выключение сигнализации вручную может для чего-то пригодиться. Наверное, он даже гордился тем, что смог предоставить дополнительную функциональность без явных затрат».
Собственно, возмущение Алана не беспочвенно: «Стоит удержать нажатие чуть дольше, как тихие трели сменятся адским воем автомобильной сигнализации, то орущей, то щебечущей, то завывающей во все свои 100 децибел, возвещая на всю округу, что некий дурень вроде меня только что сотворил ужасающе глупую вещь. Хуже того, после срабатывания сигнализации кнопки маленького пластикового брелока прекращают на что-либо реагировать, так что он становится бесполезным. Единственное, как я могу положить конец этому громкому возвещению о моей явной глупости, – это дойти до моего страшно завывающего автомобиля, сгорая от стыда под взглядом каждого встречного, воспользоваться ключом для открытия двери со стороны водителя, затем вставить ключ в зажигание и повернуть его». Вставить ключ в зажигание, черт побери! Без кнопок!
Внимание: упражнения
Кроме того, что автор критикует неудачные разработки и высмеивает проблемы (что уже несет практическую пользу, поскольку читать такое — все равно что ходить на психотерапию), в книге описаны классные психологические упражнения. Например, самолетный тест, с помощью которого вы определите, кто вы: контролер или типичный пассажир, и техника «волшебный компьютер» — для мозговых штурмов в команде.
Вообще, Алан Купер собрал много базовых моментов на страницах этого издания. В том числе, по полочкам разложил все про аватары целевой аудитории и сценарии пользовательского поведения. Можно читать, сразу применять советы на практике и прокачивать свое мышление в сторону этичного, прогрессивного, направленного на улучшение жизни людей. Рекомендуем к чтению, в том числе корпоративному.
Полезное от Онлайн Патент:
→ Как стартапу защитить свою интеллектуальную собственность?
→ Как IT-компаниям сохранить нулевой НДС и попасть в Реестр отечественного ПО
Комментарии (13)
engine9
01.09.2023 15:10+1Во многих интерфейсах от дизайнеров новой волны наблюдается одна большая всеобемлющая проблема — "размазывание" семантики контролов. Это когда кнопка модификатор ставится в один ряд с кнопкой, вызывающей модальное окно. Или когда в таб-бар (переключающий режимы работы глобально) ставится кнопка, которая вызывает меню настроек (в отдельном окне).
Часто вижу как в UI городят локальные костылики и страдает общая структура интерфейса, например в приложении могут быть три, по-разному работающие окна поиска, с разными стилями и поведением.
Мне кажется это все результат прихода на десктоп дизайнеров, вскормленных вебом, мобильными, игровыми UI. А дизайнеры "старой школы" воспитывались на десктопных приложениях у которых был весьма схожий UI который делали инженеры. Например, это было сильно заметно по UI/UX программы blender, когда туда пришли дизайнеры новой волны и принесли "своё видение", а когда стало понятно сообществу что это поломало много что в привычном (и очень красивом, надо сказать) интерфейсе, они начали мучительно всё исправлять.
[Читать голосом ворчливого деда]
VladimirFarshatov
01.09.2023 15:10+2Достаточно посмотреть на перемещения какой-нибудь типовой настройки виндовз от версии к версии, скажем начиная с Win-98 (про Win 3.1 ладно, ок молчу, молчу) по меню, его глубине и т.д. чтобы понять что книжку Алана там не читали и что такое "эргономика" Мелкософту не известно. Впрочем .. последнее время Убунтоиды начали страдать тем же самым.. :(
engine9
01.09.2023 15:10+2Беда корпораций, они ведут себя как колониальный организм без нервной системы, одно щупальце пилит тут, другое там и оба не ведают что творят соседи.
VladimirFarshatov
01.09.2023 15:10+2Там всё хужее. Там есть специально обученные люди - аналитеги, задача которых как раз и состоит в том "а куда мы ещё этот кейс не совали?" .. типа "по просьбам пользователей".. :(
Но в целом, соглашусь с Аланом (возраст позволяет поворчать синхронно) особо бесят "умные" интерфейсы, которые "за тебя" часто принимают совершенно идиотские решения и с этим ничего нельзя поделать.. последний снимок колена камерой .. ещё мелочи.
olgherd
01.09.2023 15:10Тут всё объяснимо. Сначала настроек было немного, и это не напрягало. Потом их стало больше и они стали группироваться. Потом начались попытки сгруппировать их осмысленно. А уж потом началась неведомая магия. Больше всего раздражает невозможность открыть несколько окон настроек одновременно. За это действительно хочется убить.
cliver
Почитывал я эту книжицу в оригинале (Inmates Are Running the Asylum) некоторое время назад. Насколько помню один из посылов автора заключался в том, что людей, которые пишут код нельзя допускать до создания интерфейсов пользователя, потому-что они не могут понять как "cредний" обыватель будет через этот интерфейс взаимодействовать.
Насколько это верно или неверно - спорный момент.
Einherjar
Сам факт что человек пишет код не исключает способность поставить себя на место пользователя и сделать толковый интерфейс. Но одно точно верно - людей которые НЕ прочитали эту книгу точно не стоит допускать до создания интерфейсов.
SadOcean
Ну это спорно, но мысль была не совсем такая.
Самое главное - инженеры являются обученными пользователями, которые хорошо разбираются в приложениях и технике.
А пользователи - нет.
Можно обучиться паттернам, понять пользователей лучше, но это когнитивное искажение остаётся.
Думать как пользователь, который чего-то не знает, сложно, потому что ты это знаешь.
Поэтому ничего не скажет о приложении лучше, чем реальные пользователи.
Ну и там хорошие рекомендации по организации и проектировании в целом
engine9
Видел такую ситуацию, когда программист решил "сделать красиво и хорошо" в маленькой локальной приложухе для бухгалтерии которая исправно работала и была всем привычна. Обновил он прямо во время рабочей недели от чего работники просто завыли, т.к. их привычные паттерны работы оказались поломаны и это создало затор из задач.
И каждая сторона этого противостояния не хотела слушать друг друга. UI\UX проектировщику нужно быть еще и чуточку эмпатом и любить людей какие они есть...
VladimirFarshatov
На моей практике было нечто подобное, но не так фатально. Турагенство, внутренняя СРМ. Сделал параметризованный поиск, собирающий данные из 80% БД, т.с. "всё обо всех": кто вылетает, какие билеты, куда, рейс, доставка, когда, оплаты, долги .. собственно "просили" сделать поиск опаздунов, дабы намекать им звонками что "пора сбираться в а/п"..
Первое впечатление: "А как этим пользоваться, слишком сложно!" ибо дизайн (не дизайнер, бэк) сделал в виде таблички а-ля Эксель: верхняя строчка с названиями полей содержала ещё и поля ввода, куда можно было занести как строчно "имя", так и перечень идентов через запятую (свои - знали их), а также в ячейках вывода данных была совмещенная структура вывода, например: ФИО Заказчика, и ниже в этой же ячейке как-бы подтабличка: "летит с .. жена, ребенок, свекр.." Тыкнув на каждого можно было получить всплывающим окном детали: паспорт, телефон и т.д. Даже номер строки вывода имел всплывающий виджет: дата создания записи, дата последней корректировки, кто создал "туриста", кто последний правил, сколько правок .. наворотил, в общем..
Ну ок, давайте упростим.. как хотите? Две недели народ думал над ТЗ со стороны Заказчика .. вердикт: "Да, всё классно, но давайте вот сюда к датам вылета дополним, также как с ФИО подтабличку пересадок.. Э-э-э, ась? Всё же слишком сложно, уже не?
Не, мы привыкли, зато можно выбрать всё, даже то, что планировали делать тремя следующими задачами.. аппетит приходит во время еды, но .. когнитивное сопротивление - большая сила.
engine9
Вы (программисты) думаете оперируя сущностями, потоками данных, абстракциями и т.п.. Пользователи, чаще всего, привыкают к местоположению кнопочек, полей ввода и т.п.
Например, я ни одному из своих не айтишных родственников не мог привить понимание концепции URL и что у каждого сайта есть свой адрес, как у здания в составе города. Они продолжали искать свои одноклассники в яндексе, потому что привыкли. И это нормально.
VladimirFarshatov
Продолжу ворчать в стиле Алана: да, и поэтому умный хром, набор урла без протокола в адресной строке .. ищет в Яндексе или у себя в поиске.. задолбали..