🏍️ Более быстрая лошадь

🏍️ Более быстрая лошадь

Продуктоводы любят цитировать Генри Форда:

Если бы я спросил у людей, чего они хотят, они бы попросили более быструю лошадь [а не автомобиль]

Вывод делается такой, что пользователи, мол, сами не знают, чего им надо.

Кажется, в этой байке очень мало хорошего:

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

2. Допустим, реально ответили, что нужна «более быстрая лошадь». Это весьма полезная информация, только надо сфокусироваться на «быстрая», а не «лошадь». Почему важна именно быстрота, а не выносливость, комфорт или там стоимость владения? Что смогут они такого делать, чего раньше не могли? Сразу возникают вопросы, которые помогут увидеть правильное направление.

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

4. Средний продуктовод — далеко не Генри Форд (сорян). Не грех и спросить, корона не свалится.

В общем, я за другую цитату Форда:

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

Редактор UX Movement Энтони написал о цветовом контрасте и доступности интерфейса по стандартам WCAG

1. Требования WCAG не всегда оптимальны. Алгоритм оценки контраста занижает её для белого текста на ярком фоне (синем или оранжевом), хотя читать его легче чёрного текста.

2. Контраст текста не обязательно тянуть на уровень 7:1. Это полезно, если большая часть вашей аудитории — люди старше 70 лет с потерей зрения 20/80. Для определённого контента достижение уровня 7:1 невозможно вовсе.

3. Так как текст надо читать, его стандарты контрастности выше, чем у других компонентов интерфейса. У текста 4,5:1 против 3:1 у иконок.

4. Если у иконки есть доступная подпись (контраст 4,5:1), контраст самой иконки не важен. Также не важен цвет кнопки, если находящийся на кнопке текст доступен. Требование контрастности не распространяется на неактивные компоненты (например, отключённые кнопки).

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

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

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

https://ux.pub/mify-o-dostupnosti-tsvetovogo-kontrasta/

Итог по блоку исследования

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

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

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

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

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

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

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

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

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

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

Dropbox оппубликовала пару новых материалов на своем ресурсе dropbox.design.

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

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

---

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

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

2) Инверсия
Заключается в рассмотрении сценариев ровно противоположных желаемому результату. Формируется образ «антирезультата» и, отталкиваясь от него, формируется путь поиска решения.

3) Лестница абстракций
Используется для поднятия на уровень абстракции выше, чтобы «увидеть лес за деревьями». Начинается с отправной задачи, от которой можно опуститься ниже для детализации, либо подняться выше для поиска альтернативного решения. Для погружения вниз стоит использовать вопрос «Как». Для уход на уровень выше стоит использовать вопрос «Зачем».

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

---

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

Я рекомендую самостоятельно глянуть полную версию статьи, там и с примерами проще понять, о чем речь, и более подробное описание можно почитать — https://dropbox.design/article/mental-models-for-designers

Core Protocols 2

На прошлой неделе я начал писать про Core Protocols и мы посмотрели на список Core Commitments. Если вы пропустили пост и не понимаете, о чем вообще речь, можете вернуться вот к этому посту — https://t.me/designgest/377.

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

И первый протокол, о котором хочется поговорить — Check In.

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

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

Чек-ин протокол предлагает простую схему для изложения чувств, он предлагает использовать всего 4 основные эмоции (напишу их на английском, чтобы у вас потом не было путаницы, если пойдете читать книгу):

GLAD (радость)
SAD (грусть)
MAD (бешенство)
AFRAID (испуг).

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

Плюс комбинацией этих базовых эмоций можно получать описание более сложных эмоций. Так например, EXCITEMENT = GLAD + AFRAID.

Стандартные правила для чек-ина следующие:
1) высказывать свои чувства без оценки и цензуры. Можно объяснить причину, по которой вы испытываете конкретные эмоции. Нельзя преуменьшать свои эмоции, говоря, например: «немного грустно».
2) нужно говорить только о своих эмоциях
3) с уважением слушать чек-ины других
4) не обсуждать и не ссылаться на чек-ины других, если нет явного приглашения для этого.

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

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

Массовый опрос

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

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

После инструктажа и обучения, полевик выходит на точку (кластер). Обычно, в одном исследовании требуется собрать данные с 25 респондентов, число которых, в свою очередь, ограничено квотой — то есть заданным количеством людей определенного возраста. Например, 4 мужчины и 4 женщины возрастом от 18 до 34 лет и т.д.

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

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

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

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

Оплата за опрос происходит только за полностью заполненную квоту (она, напомню, обычно составляет 25 человек), то есть за 24 человека не заплатят ничего. И наоборот — если ты перевыполнил план, то сверх квоты доплачивать не будут.