Дизайн поведения людей

Меня зовут Майк Лисянский. Я занимаюсь проектированием UX с 2001 года (19 лет). Начинал в «Студии Лебедева» (2000–2003). Проектирование UX или UX-дизайн — не единственное мое занятие в жизни, но весьма важное и регулярно используемое.

UX‑дизайн — это вечно-горячая тема, его обсуждают как индустрию моды — много, с удовольствием, восторгами, рассуждениями о «прекрасном» и мотивированием. Непростая производственная реальность швейной промышленности при этом остается за кадром «модных журналов», узнать из них ответы на вопросы «Как стать модным кутюрье?», «Как сшить красивую вещь?» и «Как организовать отшив модельной линейки?» — невозможно.

Есть и другое сходство между UX‑дизайном и модной индустрией. Кто делает что‑то сам — тот очень мало рассказывает, кто много рассказывает — очень мало делает сам.

Я хочу разбавить поток «теоретических боксеров» и рассказать о практике UX‑дизайна и проектирования приложений. Для этого я отвечу на вопрос «Что такое UX-дизайн?» и объясню почему не нужно путать иллюстрации с дизайном, а также почему пользователи приложения — это статистическая абстракция, что такое простота, системность и хаос в интерфейсе. Завершу все объяснением планирования и оценки интерфейса приложения.

UX‑дизайн

UX‑дизайн — это проектирование поведения людей в компьютерном приложении, чтобы они поступали в соответствии с целями владельцев этого приложения (владельцев в прямом смысле, не Agile).

Если у приложения нет цели — UX‑дизайн не поможет. «Направление», «желание», «чувство» — это не цель, а средство определения цели.

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

Главный инструмент проектировщика — развитое, связное и последовательное мышление. Другие инструменты (теории, знания, опыт, техники, программы, артистизм и прочее) дополняют мышление, но не могут его заменить.

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

Поведение человека

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

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

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

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

Изменение поведения человека

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

Есть два внешних метода изменить поведение человека — сотрудничество и принуждение. В компьютерном приложении возможно только сотрудничество, а принуждение в самом приложении исключено (даже если очень хочется).

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

Отсутствие «наказаний» ломает естественные (эволюционные) механизмы мышления — человек ощущает любые свои действия как «правильные», но некоторые — как «особо правильные».

Долговременные следствия отсутствия «негатива» — снижение обучаемости и внимательности людей, восприятие ими компьютерного мира как «доброго». В проектировании приложений всё это нужно тщательно учитывать.

Принуждение, однако, может быть внешним фактором приложения — когда оно исходит от других людей. Это может быть необходимость оплатить штрафы, сдать экзамены или отчеты, корпоративные требования, групповое давление (мода) и так далее. Такое принуждение увеличивает адаптивность людей к приложениям, но вызывает конфликт с ощущением «доброго» компьютерного мира.

Влияние на действия человека

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

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

Например, активно применять вместе логику и эмоции нельзя. Привычки и новые технические решения могут противоречить друг другу («не зашло», «непонятно»), а могут вызывать интерес («наконец‑то новое!»).

Важная цель UX‑дизайна — закрепить у человека изменения в поведении, которые сделало приложение, то есть сформировать привычку.

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

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

Иллюстрации против дизайна

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

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

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

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

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

Важность дизайна

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

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

В качестве стартового дизайна («чертежей») вполне подходят даже сделанные от руки наброски — это прекращает разговорные фантазии и начинает предметное обсуждение.

Дизайн отлично подходит как средство объединения и синхронизации команды разработки.

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

Пользователи

Для проектировщика пользователи любого минимально массового приложения — это статистическая абстракция.

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

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

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

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

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

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

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

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

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

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

Приложение — всегда эксперимент

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

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

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

О простоте

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

Ничего простого и очевидного «само по себе» не бывает. Всё становится простым и очевидным только после изучения и использования.

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

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

Системность против хаоса

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

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

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

Главный метод снижения усилий пользователя — системность.

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

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

Когда вы проектируете интерфейс и разрабатываете его системные правила, нужно помнить — телепатии не существует.

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

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

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

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

Именно для создания системности и нужен главный инструмент UX‑дизайнера — развитое, связное и последовательное мышление.

Цель приложения

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

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

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

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

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

В разработке приложений подобная роль до сих пор еще в стадии формирования, хотя в больших опенсорсных проектах уже есть представление о «Великодушных диктаторах».

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

Планирование интерфейса

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

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

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

Главная выгода раскадровки — полная «картинка» проекта. Она снижает неопределенность и позволяет обсуждать проблемы не по мере их возникновения, а заранее. Если так не делать, то проект зависает на «99% готовности», и — чем ближе к завершению, тем больше проблем.

Другая выгода раскадровки — изображения, даже самые схематичные, легче обсуждать и синхронизировать по ним команду. Без этого люди обсуждают собственные — и различающиеся! — фантазии.

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

Даже если у вас бесплановый метод разработки приложения (Agile), понимание общего направления очень важно — без этого работа превращается в круговорот спринтов на месте. Раскадровка — хороший и дешевый способ определить это направление и объяснить его команде.

Оценка эффективности

Эффективность — это соотношение полезных действий ко всем действиям. Без понимания «всех действий» вы не можете посчитать эффективность в принципе. Раскадровка интерфейса получается нужной не только для проектирования, но и для оценки эффективности.

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

Для каждой «сцены» интерфейса нужно определить варианты «полезных», «бесполезных» и «нежелательных» действий пользователя, и оценить вероятность каждого варианта. При проектировании это будут грубые «экспертные» оценки, после запуска приложения — оценки на опыте реального использования.

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

Оценки реальной эффективности интерфейса всегда очень интересны, но не менее интересно и сравнивать предложения при проектировании — и реальность.

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

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

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

Эта статья — часть моего проекта «Контрольная проба», в котором я пишу о практическом дизайне в UX, IT и обществе. Заходите, читайте, подписывайтесь на обновления.

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

Подробнее обо мне на моем сайте, почта — mike@lisiansky.com

{ "author_name": "Mike Lisiansky", "author_type": "self", "tags": [], "comments": 22, "likes": 7, "favorites": 70, "is_advertisement": false, "subsite_label": "design", "id": 181233, "is_wide": false, "is_ugc": true, "date": "Thu, 26 Nov 2020 16:57:05 +0300", "is_special": false }
0
22 комментария
Популярные
По порядку
Написать комментарий...
2

Ну наконец-то. Об UX и абсолютно не соплями по раковине! Приятно читать.

Ответить
0

Спасибо!

Ответить
1

Это ахуенно. 

Ответить
1

Спасибо!

Ответить
1

Пишите почаще, Майк

Ответить
1

Воу. Жду ещё.

Ответить
0

Спасибо! Еще будет скоро.

Ответить
0

я конечно дико извиняюсь но у вас написано что вы занимались ребрендингом и новым логотипом компании BSS (2018–2019)

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

Ответить
2

Для того, чтобы понять «что такого», нужно посмотреть на какое-нибудь околобанковское мероприятие, например — iFin. Логотип BSS — всегда единственный, который не нужно искать, всегда узнается и четко читается.

Есть и другие «особенности», но у меня не статья про тонкости ребрендинга в реальном мире ;-)

Ответить
0

Вы так и не ответили - это ваше творение? 

У вас написано даже не ребрендинг а новый логотип что подразумевает создание. Зная как АЛ и его "банда просвещенных в UX/UI" любит засерать подобного рода творчество мне просто интересна ваша аргументация

А и трюк с шириной логотипа это тоже какая-то новая тенденция в мире дизайна?

Ответить
3

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

За творчеством АЛ, если я правильно понял о ком идет речь, я не слежу последние 15 лет, ничего не могу сказать по этому поводу. Подозреваю, что как и 20 лет назад там делается подмена иллюстрации и дизайна (об этом я писал в статье), после чего единственный «участник обсуждения» объявляет себя победителем.

Драка со связанным противником и самосудейство не украшает никого. В крайнем случае, всегда можно спросить про Полит-порку и удачно сгоревший винт ;-)

А в подобном споре аргументы простые. Какие задачи поставлены? Как они решены? Какие были/есть варианты? Все сравнения с фантазиями — в шрёдер. Но, обычно, всё заканчивается еще на первом вопросе.

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

Ответить
0

Про АЛ вы правильно поняли. Теперь и мне становиться понятнее логика в поведении адептов этой секты

Относительно ширины логотипа - я почему то думал что все дизайнеры смотрят на мир исключительно через объектив какого либо графического редактора

Ответить
2

Через графредактор на мир смотрят иллюстраторы, это они — про картинки.

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

С логотипом мне подсказали про полупрозрачную вставку справа — у меня ее не видно. Это эксцесс исполнителя, забивание шурупа молотком. Собственно, так всегда происходит, когда картинка важнее всего ;-)

Ответить
1

Спасибо. Идею понял
Подписался. Пишите еще

Относительно разъяснений касательно сектантов отдельное спасибо

Ответить
0

Всегда пожалуйста! Писать буду, не сомневайтесь

Ответить
0

Цитата: "Если человек использует выражение «простой интерфейс» — это точный маркер того, что он не сделал ни одного реального интерфейса для реального и работающего приложения".

С вашего сайта: "Главное, что я делаю, — это простые, удобные и эффективные решения".

Решения, а не интерфейсы, но смысл тот же.

Ответить
0

Я правильно понял, что для вас «решения» и «интерфейсы» — это синонимы с одинаковым смыслом? Поясните, пожалуйста, подробнее.

Ответить
0

Такая же абстракция, как и простой интерфейс.
"Простота — это относительное понятие, оно имеет смысл только в прямом сравнении. Нечто (предмет, действие, идея) может быть простым для одного человека, но сложным — для другого. У простоты нет никаких эталонов или «стандартных единиц», в которых ее можно измерять."

Ответить
0

Вы ответили на какой-то другой вопрос, не который я вам задавал, но который придумали сами. При этом у вас фиксация на слове «простой», видимо именно оно кажется вам главным.

Я повторю вопрос, на который хочу получить ответ — являются ли «решения» и «интерфейсы» синонимами, то есть словами с одинаковым или близким значением?

Ответить
0

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

Ответить
0

Смотрите.

Вы зациклены на слове «простота» и ничего кроме него в тексте не видите. Вы не различаете понятия «решение» и «интерфейс», у которых для вас «смысл тот же». На вопрос с вариантами ответа «Да/Нет/Не знаю» вы выдаете истерику «Зачем мне отвечать».

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

Хотите доказать что я не прав? Начните с ответа на заданный мной вопрос.

Ответить
0

Так я же с вами согласна и понимаю, почему вы так написали на сайте.
Сделаю простой интерфейс/простое решение продает лучше.

Ответить

Комментарии

null