12 заметок с тегом

интерфейс

Конспект книги Алана Купера «Психбольница в руках пациентов»

Три вкусных цитаты

  1. Если программа сложна в применении, это раздражает пользователей, и они избегают работы с ней.
  2. Красивый интерфейс — это классно. Но когда с таким интерфейсом непонятно, как работать, пользователь плевать хотел на внешний вид. Это называется «роспись по трупам».
  3. У обыкновенных людей, новичков в использовании продуктов, нет специальных знаний, которые позволяют судить, как избавиться от когнитивного сопротивления. Вместо этого они полагаются на подсказки компьютерных «ботаников», которые пожимают плечами и говорят, что «надо быть компьютерно грамотным», чтобы использовать продукты, основанные на программном обеспечении.


Введение

Чтобы создавать мощные и приятные продукты, основанные на программном обеспечении, надо использовать простой приём: проектировать взаимодействие продукта с пользователем до этапа программирования.


В индустриальную эру, до появления программ, продукты создавались из реальных материалов — из атомов. Затраты на добычу, плавку, приобретение, транспортировку, нагрев, формовку, сварку, окраску и снова транспортировку преобладали над всеми прочими расходами. В бухчёте эти расходы называются «переменными», поскольку они различны для каждого созданного продукта. «Фиксированные расходы» не варьируются и включают затраты: корпоративное администрирование или начальная стоимость завода.

Классические правила управления бизнесом уходят в производственные традиции индустриальной эпохи. Они не учитывают новые реалии информационной эры, в который продукты создаются не из атомов, а состоят из программного кода.

Цель любого бизнеса — стабильные прибыли. Способ их получать: продавать товары или услуги дороже, чем обходится их создание. Из этого следуют два пути повышения прибыли: снизить затраты или повысить доходы. В старой экономике лучшим способ было снижение затрат. В новой экономике намного лучше работает повышение прибыли.

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

Единственный возможный источник экономического подъёма — повышение качества и, как следствие, привлекательности продукта или услуги. А повышения качества не добиться, если сократить затраты на проектирование и программирование.

Разработка программ похожа на разработку лекарств, но не на строительство завода.

1. Загадки века информации

Компьютеры сообщают нам факты, но не информируют нас.

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

Наши компьютеризованные инструмента слишком сложном применять.

К сожалению, программисты проектируют возможности, но не то, как программа ведёт себя, общается или уведомляет.

Ключ к решению проблемы — проектирование взаимодействия.

2. Когнитивное сопротивление

Когнитивное сопротивление — это то, с чем сталкивается человеческий интеллект, пытаясь разобраться в сложной системе правил, которые изменяются динамически.

Интерактивные продукты должны проектироваться проектировщиками взаимодействия, а не разработчиками программного обеспечения. Дизайнерам — то, что влияет на конечного пользователя; программистам — код.

Чтобы сделать пользователей могущественными и удовлетворёнными, надо думать концептуально -> в терминах поведения -> в терминах интерфейса.

Швейцарский армейский нож сложен и насыщен возможностями, причём некоторые из них хитроумно спрятаны, но изучение и применение ножа — процесс простой, предсказуемый, интуитивный.

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


У обыкновенных людей, новичков в использовании продуктов, нет специальных знаний, которые позволяют судить, как избавиться от когнитивного сопротивления. Вместо этого они полагаются на подсказки компьютерных «ботаников», которые пожимают плечами и говорят, что «надо быть компьютерно грамотным», чтобы использовать продукты, основанные на программном обеспечении. Программисты валят всю вину на технологии, объясняя пользователям, что сложность взаимодействия — неотъемлемое свойство компьютеров, и она неизбежна.

Это неправда. Сложных взаимодействий можно избежать.


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

Высокое когнитивное сопротивление раскалывает людей на два лагеря. Первые впадают отчаяние и чувствуют себя глупо из-за неудач. Вторые чувствуют эйфорию от способности преодолевать крайне серьёзные препятствия.


Востребованность функции обратно пропорциональна количеству действий, которые необходимы для её управления.


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


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

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

3. Пустая трата денег

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

Что такое «готово»? Имея на руках конкретное описание завершённого программного продукта, мы сравниваем наше творение с этим описанием и понимаем, готово ли.

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


Большинство руководителей разработки продуктов, с которыми приходилось работать, предпочтут выбросить на рынок неработоспособный продукт, но не опоздать со сдачей.

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


Много функций не значит «хорошо». Пользователи решают задачи.


Если программа сложна в применении, это раздражает пользователей, и они избегают работы с ней.


Хорошо разработаете продукт — практически откажетесь от технической поддержки.


Есть важные цели для пользователей, и их надо добиться. И плевать, что мы не делаем операционную систему.


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


Нельзя хорошо программировать и проектировать одновременно.

7. Хомо логикус

Не заставишь программиста простыми методами делать всё, чтобы пользователю было удобно. Нужно вдохновить, а для этого понять психологию.

Четыре фундаментальных отличия образа и действия разработчиков программ от обычных людей:

  1. Пожертвуют простотой ради контроля.
  2. Обменяют успех на понимание.
  3. Сосредотачиваются на исключительных ситуациях.
  4. Ведут себя грубо и прямолинейно.

Для хомо логикус цель — контроль, а цена, которую они готовы платить за достижение цели,— сложность. Для нормальных людей цель — простота, и цена — отказ от контроля.

Тяга программистов к пониманию заставляет их инстинктивно создавать взаимодействие, приближённое к внутренним механизмам продукта.

8. Отмирающая культура

«Это ведь окна. В плане указано, что окна на этой стороне. В чём проблема?»

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


Коллективная психология хомо логикус порождает общую для программистов культуру.

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

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


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

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


Программист отвечает за результат. Поэтому не меняет код, потому что так посоветовал дизайнер или руководитель. Он боится, что из-за этого пострадает результат, как было много раз за карьеру.

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


Компьютеры сегодня намного мощнее, дешевле и быстрее, чем всего несколько лет назад,— это факт.

9. Проектирование для удовольствия

Самый эффективный инструмент проектирования взаимодействия прост: это точное описание пользователя продукта и его целей.

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

Персонажи определяются своими целями. Цели же определяются персонажами.


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

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

Если спроектировать интерфейс с учётом одного персонажа, ничто не сможет встать между этим персонажем и счастьем.

Любовь людей к продукту, пусть этих людей мало,— ключ к успеху.

Счастливые пользователи — ценное приобретение. Сужая фокус, вы можете получить фанатично преданных клиентов целевого рынка. Они расскажут друзьям и не забудут в трудные времена.


Термин «пользователь» — источник трудностей. Те, кто говорит «пользователь», обычно подразумевает эдакое «гуттаперчевое» создание, которому приходится изгибаться, растягиваться и адаптироваться к потребностям момента. Наша цель — проектировать программы, которые будут изгибаться, растягиваться и адаптироваться к потребностям пользователя. Проектирование для гуттаперчевых пользователей даёт разработчику разрешение писать код как угодно. Реальные пользователи не эластичны.

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

Шаблонный персонаж более эффективен, если шаблонность придаёт достоверность.

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


Не путайте точное определение пользователя с реальным человеком. Людям присущи забавные причуды поведения, которые мешают процессу проектирования. Очень силён соблазн приписать причуду одного человека всем пользователям, но этого соблазна стоит избегать.


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

Персонаж — типичный пользователь. Исключения оставьте программистам.

Средний пользователь не бывает математически средним. Родитель, имеющий 2,3 ребёнка, не существует. Существует Андрей, отец двоих детей. Нужна конкретика.


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


Набор персонажей становится системой, которая помогает объяснить решения по проектированию.

Жизненно важно, чтобы каждый в команде проектировщиков держал в голове набор персонажей и воспринимал, как реальных людей.

Программистам свойственен математический подход, и они не склонны рассматривать отдельных пользователей, предпочитая обобщение. Но кодом владеют они и делают, что хотят. Чтобы программисты приняли в счёт ваши аргументы, заставьте их поверить в существование и реальность созданных персонажей. Мы проектируем для Серёжи, а не для кого-то.

Когда программисты начинают называть персонажей по имени по своей воле, вопросы проектирования обсуждаются, разрешаются и остаются разрешёнными навсегда.


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


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


Каждый проект получает свой набор персонажей в количестве от трёх до двенадцати. Мы проектируем не для каждого из них, но все персонажи полезны для выражения пользовательской аудитории. Некоторые создаются только, чтобы было ясно, для кого мы не проектируем.


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

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

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

Есть четыре персонажа. Наш интерфейс должен удовлетворить их, не причиняя никому неудобств.

Находим ключевого персонажа. Идеальная система для него сделала бы счастливыми и всех остальных, всех до единого.


Цели и задачи не тоже самое. Цель — это конечное состояние. Задача — переходный процесс, необходимый для достижения цели. Их важно различать. Проектирование под задачи не всегда уместно, а проектирование под цели уместно всегда.


Принцип соразмерности усилий: пользователь готов приложить дополнительные усилия, потому что ожидает за них дополнительное вознаграждение.


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

Цель Пример
Личная Не чувствовать себя глупо
Корпоративная Увеличить прибыль
Практическая Сохранять информацию о заказ клиента
Ложная Экономить память

Список элементов, которые повышают качество взаимодействия для людей и высокотехнологичных, основанных на программном обеспечении продуктов, насыщенных когнитивным сопротивлением:

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

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

11. Проектирование для людей

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


Создаются сценарии на основе информации, собранной в ходе первой фазы — исследования. Обычно в интервью и наблюдении за пользователями удаётся узнать многое о задачах.

Важно, чтобы сценарий описал каждый шаг в подробностях.

Разрабатывайте только два вида сценариев, хотя сценариев каждого вида может быть несколько. Это сценарии повседневные и сценарии обязательные.


Повседневные сценарии — самые важные. Описывают основные действия, которые пользователь выполняет чаще всего. Нуждаются в самой надёжной поддержке качественным взаимодействием: инструкции, потом клавиатурные сокращения и ещё дальше настройка под себя.

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

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


Адаптирующийся интерфейс: показывать пользователю элементы, необходимые для повседневных сценариев, остальные — на второй план.


Большинство пользователей — вечные середняки.

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

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

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


«Представь себе!»: держишь в голове цели пользователя и представляешь идеальный компьютер.


Для процесса проектирования нужен подробный словарь. Каждый в команде должен одинаково трактовать термины. Например, можно разбивать процессы, задачи, программы на чёткие фрагменты и назначить им новые имена, не имеющие унаследованного смысла; не помешает чувство юмора.


Ограничения надуманны. И это нельзя понять, не обойдя их.


Аппаратное обеспечение должно учитывать потребности программного.


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

12. В отчаянных поисках эргономики

Важнейший аспект проектирования — последовательность событий в процессе разработки. Последовательность такая: проектирование взаимодействия → программирование → устранение дефектов и юзабилити-тестирование → доводка. Другая последовательность приведёт к плохому результата.


Юзабилити-методы как наждачная бумага. Если вы делаете стул, наждачка сделает его более гладким. Но никакая шлифовка не превращает стол в стул. К сожалению, тысячи людей из лучших побуждений шлифуют столы методами эргономики, чтобы получить стулья.


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


Руководства по стилю помогут, но не решат проблем проектирования взаимодействия.


Фокус-группы — сомнительный инструмент для создания новаторских продуктов. Эксперт по инновациям Ларри Кили: «Пользователи отвергнут новые идеи, если вы их предложите».


Красивый интерфейс — это классно. Но когда с таким интерфейсом непонятно, как работать, пользователь плевать хотел на внешний вид. Это называется «роспись по трупам».


В промышленном дизайне тоже надо думать о проектировании взаимодействия.


«Майкрософт» работает так: выпускает сырой, плохо спроектированный и сконструированный продукт. Индустрия над ним смеётся, специалисты критикуют, а «Майкрософт» делает новые улучшенные версии. Такая стратегия эффективна только для компаний с железобетонным именем, кучей времени, выдержкой игрока в покер и неисчерпаемыми финансами.

13. Управляемый процесс

Слушать клиентов надо: вы накладываете на услышанное фильтр и получаете ценные знания. Но вы не должны следовать за клиентом.

У клиента есть деньги, но нет двух важнейших качеств: 1) он не заботится о ваших интересах и 2) не знает, как проектировать.

Клиенты, даже выкрикивая противоречивые приказы, ожидают, что вы самостоятельно выберете правильные.


Ваша компания делает работу и придумывает инновации. Клиенты видят, что нужно похожее, и зовут вас. Но они мешают вашему процессу: заставляют штамповать то же самое, убирают проектирование взаимодействия, приносят списки функций. Теперь остальные видят, что вы середнячки, и идут к ребятам с инновациями.

Это смертельная спираль. В неё попадают те, кто идёт на поводу у клиента.

Задача руководителя компании — удержаться на передней линии, избегая смертельной спирали, в которую тянут клиенты.

Для этого надо понять:
Долгосрочное прогнозирование лишает вас хлеба сегодня, но умножает его завтра.

Отложите долгосрочное планирование на завтра — не доживёте до завтра.

Инновации в проектировании взаимодействия быстро делают.

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


Производство фильмов — занятие сложное и дорогое. Создатели кино тратят время и деньги на создание подробных раскадровок и съёмочных расписаний и тем самым экономят кучу времени и денег на съёмках.

Создатели программ, сайтов, создавая на бумаге подробный план для продукта, исключают неопределённости в программировании и снижают риски, которые всегда преследуют выпуск продукта.


Запомните мантру: «Если этого нет на бумаге, значит, это не существует». Проектировщики взаимодействия должны фиксировать свои предложения в письменной форме. С подробностями, примерами и в терминах, имеющих смысл для программистов. Достаточна детализированная спецификация неотличима от кода. Она должно быть напечатана и переплетена во множестве экземпляров. Её следует лично представить команде разработчиков. Важный начальник в этот момент должен присутствовать, кивать и улыбаться.


Маркетологи получают от проектировщика персонажи и думают над тем, как чётко изложить покупателю, каким образом продукт облегчить жизнь.


Качественное проектирование уменьшает документацию и количество звонков в техническую поддержку.


Раньше проект управляли, ориентируясь на фиксированные сроки сдачи, и корпели над тем, чтобы было больше функций. Теперь этого нет, потому что есть документальное описание продукта.


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

Мандат доверия команды проектирования взаимодействия включает проектирование реальных, простых в применении, привлекательных продуктов, с которыми пользователи достигают практических целей, не отказываясь от целей личных.


Для компании главное — включить проектирование взаимодействия в процесс, поставив перед программированием.


Лучше собирать команды проектировщиков из двух-трёх человек. Надо назначить человека главного по документации. Дать время.

14. Мощь и удовольствие

В суровой жизни программист по-прежнему игнорирует проектировочный документ, независимо от его качества. Но этот документ — чертёж, которому необходимо следовать, а не предложение.

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


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

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

Сократит затраты времени на разработку продукта. Если заранее знаете, что конкретно надо сделать,— потратите меньше времени на поиски верного пути.


Штат Детройт производил гигантские хромированные прожорливые автомобили и лицемерно утверждал: «Мы даём потребителям то, что им нужно».

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

Сегодня автомобильная индустрия Америки проявляет гораздо большее уважение к желаниям потребителя и уже не осмеливается утверждать, что все знает лучше.

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

Точно так же высоты в проектировании программного взаимодействия сегодня остаются свободными, они не захвачены никем. Мiсrоsоft уязвима не меньше, чем General Motors в 1974 году.


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


Цели у разработчиков программного обеспечения и проектировщиков взаимодействия общие: и те, и другие хотят, чтобы продукт стал успешным. Просто их инструменты и термины для измерения успеха коренным образом различаются.

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

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

Точность и полнота проектировочной спецификации — точка соприкосновения проектировщиков и программистов. Когда проектировщики дают абсолютно верные решения, программисты доверяют и полагаются на них.


Люди: «Моя машина заставляет меня думать, что я идиот!». Апологеты: «Пользователи не знают, чего хотят, а когда знают, то каждый хочет своего. Пусть лучше читают руководства и изучают программы». Мир спасут проектировщики взаимодействия.

28 октября   интерфейс   конспект

Неудобный кран

Чтобы вымыть посуду, мне надо включить тёплую воду. Этот процесс настройки крана напоминает управление самолётом.

Мне нужна вода только двух температур: тёплая для мытья посуды и ледяная для готовки. Почему я должен каждый раз «сажать Боинг»?

Мечтаю о кране, который сам льёт воду, какую мне надо.

2017   интерфейс   кран   кухня

Пустой пододеяльник. Продолжение

В пятницу я написал, что ненавижу, когда одеяло выходит из пододеяльника:

В комментариях мне посоветовали специальные булавки:

Такой способ работает, но это додизайн. Сильное решение выполняет полезное действие без дополнительных средств.

Я вспоминаю похожий случай из дизайна урн для мусора.

Если на урне не закрепить пакет, он упадёт:

Так же с одеялом: если его не зафиксировать — съедет.

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

Так же одеяло зажимают булавками.

Но сильный дизайн не требует булавок, прищепок — пакет прижимает часть урны:

Мечтаю о пододеяльнике, который держит одеяло и не мешает спать.


См. также: Как закреплять пакет на урне

Пустой пододеяльник

Ненавижу, когда из пододеяльника выходит одеяло. Хочу, чтобы оно закреплялось один раз и никуда не слазило.

2017   интерфейс   постельное бельё

Ложная связь

Я создаю письма для ежедневной рассылки книги «Круг чтения».

Когда заканчиваю последний этап: заряжаю письмо на автоматическую публикацию — мне показывают уведомление. Оно сбивает с толку:

Крестик намекает на ошибку, хотя операция прошла успешна

На самом деле, крест не связан по смыслу с сообщением, он просто сворачивает уведомление. Если бы он стоял дальше, например, в углу, меня никто бы не сбивал.

2017   интерфейс   путаница   теория близости

Джеф Раскин «Интерфейс»

Три вкусных цитаты

1. Кушать, ходить или печатать вслепую лучше всего получается, если об этом не думать. Как только задумаетесь — собьётесь.

2. Пиктограмма, изображающая ладонь поднятой руки, означает в США «стоп», а в Греции — «вот вам экскременты на ваше лицо».

3. Запаздывания скрывают. В карточной игре на создание каждой новой раздачи требуется несколько секунд. Игра кажется быстрее, если в это время воспроизводить звук тасуемых карт. Ценность такой маскировки обнаруживается, если звук отключить — задержка станет раздражать. 

Следующий выйдет 16 декабря на «E-mail маркетинг» Дмитрия Кота.

2016   интерфейс   книги   конспект   Раскин

Создание таблицы в Гугль-доке

Мне нужна таблица размером 7×15. Я кликаю в меню и вижу поле 5×5. Как сделать таблицу моего размера? Наверное, создать «пять на пять» и добавлять ячейки?

Оказывается, всё проще. Мне нужно переместить курсор:

Вот так выглядит создание таблицы в любимом Гугль-доке. О нём у меня есть ещё один пост.

2016   Гугль   гугль-док   интерфейс   наблюдение   таблица

Пишите проще

Сайт «Решу ЕГЭ» напоминал авторизоваться, чтобы люди получили доступ ко всему сервису:

Некоторые читали уведомление и шли писать в службу поддержки:

Они не знали слово «авторизоваться», поэтому сталкивались с трудностями и тратили время службы поддержки. Возможно, какой-то пользователь ушёл к конкуренту. И это всё из-за того, что одно слово было не в мире обычного человека.

Пишите проще

Секрет иконки «Солнышко»

Иконка солнышка выглядит живее и веселее, если повернуть на 15 градусов. И это справедливо для всех пиктограмм, симметричных относительно центра: спасательного круга, снежинки, шестерёнки.

Секрет раскрыл Рома Воронежский, а я узнал об этом из лекции Анастасии Ларкиной

2016   иконка   интерфейс   лайфхак   пиктограмма

Вы не заполнили поля, поставьте прочерки!

Людвиг Быстроновский советует книгу «Поток» Михайя Чиксентмихайи. Хочу её прочитать, нахожу в интернет-магазине, нажимаю «Купить», и на меня вываливается куча полей:

Сайт заставляет делать какие-то непонятные вещи. Я уже хотел читать, как перевести обыденную работу в приятное состояние, когда не ощущаешь времени, когда вместо усталости — постоянный прилив энергии. А вижу 19 полей, 2 чекбокса и 1 выпадающий список.

Правда, книга в этом интернет-магазине дешевле, чем в других, поэтому терплю. Меня спрашивают способ доставки — выбираю самовывоз. Для этого можно заполнить не все поля, а только пять. Но сайт всё равно ругается:

Ему не понравилось, что я оставил поля со звёздочкой пустыми. Оказывается, мало заполнить пять полей, надо поставить прочерки в остальных. Иначе машина не пропустит дальше.

Эти действия бессмысленные для пользователя. Они оттягивают момент покупки — отсеивают неопытных покупателей и уменьшают оборот магазина.

Исправит ситуацию упрощение формы. Например, такое:

Всё равно девушка из колл-центра позвонит, чтобы подтвердить заказ,— вот и спросит всё, что нужно.


См. также, как Илья Бирман в совете упрощает форму

2016   интерфейс   форма

Гугль не думает о сценариях пользователей

Люблю Гугль-документы. Пишу в них всё по дизайну: проектирование, описание персонажей, процесс проекта,— собираю макеты для вёрстки. Классный сервис.

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

Может я придираюсь, но если бы документ открывался там, где я вчера закончил, было бы удобнее.

Уместно вспомнить Джефа Раскина, проектировщика интерфейса Макинтоша:

Хорошая программа
открывается там,
где в последний раз закрыли

Почему дизайнеры стесняются слова «пользователь»

Константин Горский из Яндекса говорит «люди» вместо «пользователи». Шутит, что на слайде места не хватило. Потом объясняет, что это унизительное отношение, а тех, кто говорит «юзвери», нельзя допускать к проекту:

В чём проблема

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

Люди, которые говорят «пользователь», подразумевают «гуттаперчевое» создание, которому приходится адаптироваться к потребностям машины. Например, инженеры знают, как чертить бронежелеты, но им необходимо ездить на курсы, чтобы научиться работать в новой программе. Хороший дизайн — делать машину, которая адаптируется к человеку.

Как писать по-другому

Если аудитория понятна, абстрактный пользователь превращается в конкретного. Например, я делаю сайт для подготовки к ОГЭ. Вместо «пользователь» пишу «девятиклассник».

Не пользователь, а инженер-конструктор 48 лет

2016   интерфейс   пользователь