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

конспект

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

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

  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 октября   интерфейс   конспект

Раздел «Книги» на моём сайте. Проблема с редактированием конспектов

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

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

Теперь я буду использовать время на более полезные дела. Это же не статья, а конспект.


См. также:
Раздел «Книги» на моём сайте. Проблема с обновлением
Раздел «Книги» на моём сайте. Проблема с конспектами
Конспект книги «Интерфейс» в 200 тысяч символов

Спонсор поста

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

Пишите в телеграме.

26 октября   автоматизация   книги   конспект

Конспект книги Максима Ильяхова, Людмилы Сарычевой «Новые правила деловой переписки»

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

  1. Быть внимательным к имени.
  2. Оценивать личные впечатления от работы, а не человека.
  3. Читайте и учитесь, чтобы о вас говорили: «Как приятно с этим человеком работать!».


Введение

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

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

Без шаблонов: от них всех тошнит.

Читайте и учитесь, чтобы о вас говорили: «Как приятно с этим человеком работать!».

Шесть вещей в письмах, которые раздражают всех

  1. Небрежность.
  2. Панибратство.
  3. Перекладывание ответственности.
  4. Повторение за другими.
  5. Спешка и срочность.
  6. Натянутая вежливость.

Кайтесь, что баклан, давайте право на нет.

Уважать время и внимание

  1. Одно письмо — одно дело. Несколько вопросов можно.
  2. Продумать тему. Должно быть понятно, что требуется и когда.
  3. Обозначить срочность. Человеческим языком, «срочно» сберегите на пожар.
  4. Изложить суть в первом абзаце. Дальше подробности, вопрос отдельно.
  5. Вспомогательные материалы — сразу. Чтобы не лазить.
  6. Расположить по полочкам. Подзаголовки, нумерация.
  7. Грамотно поставить ссылки. Ссылка описывает содержание страницы.

Соблюдать правила вежливости

Вежливость — это забота, а не слова.

Быть внимательным к имени.

Представляться понятным именем.

Извиняться и предлагать план.

Обращаться к нескольким людям сразу: «Иван, Сергей, Александр!» — вместо «коллеги».

Не злоупотреблять словечками.

Делать удобно читателю.

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

Уважать границы

  1. На работе — о работе.
  2. Не лезть в голову. Не «Вам нравится», а «Что из этого вам нравится?»
  3. Оценивать личные впечатления от работы, а не человека.
  4. Не распоряжаться чужим временем.
  5. Не «пинать», а вежливо спросить о состоянии проекта и предложить помощь.
  6. Критиковать прямо. Это признак уважения.
  7. Не манипулировать. Не прикрывать истинные мотивы.
  8. Не делать вид, что всё окей.
  9. Не писать то, что нельзя переслать.
  10. Если собеседник говорит дичь, понять, почему он это говорит.

Когда лучше не писать

  1. На эмоциях. Надо побить грушу, позвонить или встретиться лично.
  2. Чтобы договориться с коллективом. Надо лично.
  3. В случае пожара. Надо звонить или бежать к человеку.

Холодное письмо

  1. Спокойный тон.
  2. Не предполагать и не решать за читателя.
  3. Не уговаривать.
  4. Читатель ничего не должен.
  5. Предложить простое действие.
  6. Упомяните общее, но без манипуляций.
  7. Пишите лично, лучше без прикреплённых пдфок.

Письмо в ответ на вакансию или объявление

  1. Спокойно отвечать по пунктам.
  2. Приводить доказательства.
  3. Прислать так, как просили.
  4. Не обидеть.
  5. Сделать удобно получателю, а не отправителю.
30 сентября   инфостиль   книги   конспект

J. Fried, D. Hansson. Remote

О книге

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

Я читал оригинальное издание на английском, и мне понравилось. Советую так же прочитать Rework: книги небольшие, написаны современным языком и разделены на короткие главы. Яндекс-переводчик в помощь :-)

Книжку взял в любимой библиотеке.

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

1. Если сидят 8 человек на часовом совещании — компания тратит не один час, а восемь.

2. Стереотип: человек в офисе с 9 до 18 + приятен в общении = он, должно быть, хороший работник.

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

Майк Монтейро «Дизайн — это работа»

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

1. Вы должны уметь объяснить, чем вы занимаетесь, кратко и интересно.

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

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

Следующий выйдет 17 февраля на «Психологию убеждения» Яна Чихольда.

2017   дизайн   книги   конспект   Монтейро

Дмитрий Кот «E-mail маркетинг»

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

1. Спам и e-mail маркетинг — две разные вещи. Человек должен добровольно дать свою почту.

2. Представьте, что подписка на вашу рассылку — платная. Убедите за неё платить.

3. Главное, не копировать тематику конкурентов, а «отстраиваться» так, чтобы человеку было интересно читать и конкурентов, и вас. Выберите узкую и интересную нишу, чтобы привлечь внимание потенциальных клиентов.

Следующий выйдет 6 января на «Дизайн — это работа» Майка Монтейра.

2016   e-mail маркетинг   книги   конспект   Кот   рассылки

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

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

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

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

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

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

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

Джим Кемп «Сначала скажите „нет“»

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

1. Если противник интересуется вашим мнением по какому-то вопросу, он, скорее всего, добивается вашего согласия.

2. Важный принцип: задавайте открытые вопросы последовательно. Один простой вопрос за другим, ответ за ответом — и постепенно вы поможете противнику самому увидеть проблему.

3. Гольф-клуб «Большая Берта» привлек внимание игроков, потому что владелец клуба Каллауей ввел очень высокие членские взносы: $400 в месяц. Каллауей понимал: если членские взносы будут, как у всех, «Большая Берта» станет еще одним гольф-клубом и обеспеченные потенциальные клиенты не увидят в нём пользы.

Следующий выйдет 4 ноября на «Интерфейс» Джефа Раскина.

2016   Кемп   книги   конспект

Ян Чихольд «Облик книги»

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

Вместо этого дам три вкусных цитаты и ссылку на конспект. О книге лучше всего расскажет сама книга.

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

1. В хорошей книге первые и последние две страницы пустые.

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

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

Следующий выйдет 30 сентября на книгу Джима Кемпа «Сначала скажите „нет“».

2016   книги   конспект   Чихольд