Опубликованы видео с Mail.ru Design Conf 2020:

1. Александр Васин и команда Groza Design — О себе, команде и проектах
youtube.com/watch?v=MDMC5rwYQA8

2. Команда Сбербанка — Истории про 3 тренда: художники, динамичность, переход от пластика к цифре
youtube.com/watch?v=wkDGnFD8I_U

3. Василий Хлебников, Моторика — О себе и миссии компании
youtube.com/watch?v=81TchEsXkxE

4. Никита Василевский и Алексей Комаров, ex-Рокетбанк — О проектах и работе в Рокетбанке
youtube.com/watch?v=XWCXX_QLw0k

5. ESH Gruppa — Об организации процесса, проектах и закладываемых смыслах
youtube.com/watch?v=O3pddD0t3Zg

6. Миша Лихачёв и Илья Гришин, ВКонтакте — Об уменьшении энтропии, команде, дизайне, эффективности дизайн-системы, VKUI, обратной связи, связке дизайна и разработки
youtube.com/watch?v=3yynEAA0Wsw

7. Bang! Bang! — О проектах агентства, принципах работы, манифесте команды
youtube.com/watch?v=_IuxE7FRKhw

8. Юлия Гонина и Саша Денисов, TypeType — О шрифтовых технологиях и кастомном шрифте как инструменте решения дизайнерских задач
youtube.com/watch?v=hcYYHxG_24Y

9. Оля Яковлева и Артём Чернобровкин, КБ Стрелка — О функции красоты, роли дизайна и иллюстраций в городском консалтинге
youtube.com/watch?v=5IDfQIFHnHk

10. Александра Гуляева и Дарья Шаклеева, UX-лаборатория Mail.ru — О пользе исследований для дизайна и дизайнеров
youtube.com/watch?v=-pUAmX9J6Uo

— Все видео в одном плейлисте: youtube.com/playlist?list=PLzqQCeTtpSBrablTVd8lvYDSJVqiNltwr
— Альбом в ВК: vk.com/videos-50773057?section=album_42

Дарья Шаклеева написала о тестировании сложного продукта в корпоративной UX-лаборатории.

Форматы работы внутренней UX-лаборатории с остальной компанией: а) агентство, когда исследователь работает с разными командами и проектами попеременно; б) каждый исследователь работает только со своей продуктовой командой.

Исследовать надо интерфейсы, с которыми пользователи работают часто и с которыми работают редко, но которые значимы для бизнеса (например, административные панели).

Такие интерфейсы ориентированы на специалистов. Исследователь без специальных знаний будет путаться в сокращениях вроде AD, SSL и ВКС и в происходящем на экране, не сможет задать уточняющие вопросы. Спасает выбранный формат работы (б), подразумевающий глубокую вовлечённость остальной команды продукта в исследования.

Сисадмины не могут показать работу со своими административными панелями и установщиками, так как там содержится конфиденциальная информация. Нет каких-то сложившихся паттернов взаимодействия, к которым все привыкли, чтобы от них отталкиваться. Приходится тестировать 2−3 варианта структуры прототипа без каких-либо предпочтений между ними. Основной вопрос — не какой из сценариев удобнее, а попали ли мы вообще в логику поведения респондентов или нужно всё переделывать?

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

https://habr.com/ru/company/mailru/blog/518108/

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

Классическое понимание:
— Есть базовые эмоции: страх, гнев, горе, отвращение, радость, удивление;
— У каждой — свой набор нейронов и своя уникальная реакция. Эмоция — цепь неконтролируемых изменений мимики лица и других физиологических реакций, запускаемая событием;
— Эмоции универсальны для всех людей.

Современные исследования показали:
— Нет значимой связи между активацией мышц лица и определёнными эмоциями;
— Люди в среднем плохо считывают эмоции незнакомых людей по выражению лица. Средняя точность оценки: 48%. Если исключить из набора фотографий самые яркие эмоции, точность падает до 35%;
— Нет связи физиологических реакций вроде изменения сердечного ритма, давления, периферического сопротивления сосудов, кожно-гальванической реакции с конкретными эмоциями;
— Самоотчёт (когда испытуемые говорят о своих эмоциях) работает плохо: люди подвержены стереотипам в оценках, с меньшей охотой сообщают о негативных эмоциях, иногда не способны описывать свои эмоции словами (алекситимия).

https://v-shliachkov.medium.com/85d0038b20fe

Павел Шерер опубликовал 2-ю статью цикла о функциональной архитектуре.

— Этапы создания ФА: высокоуровневый (скелет продукта) и детальный (мясо);
— Это разделение условно: где-то приходится возвращаться к переосмыслению общих решений, где-то нельзя продолжить без более глубокого погружения в область;
— Кажется, что набросать общую структуру проекта проще, чем детально расписать каждую функцию. Загружать в голову функциональность большого продукта и анализировать её — сложно. В начале работы важно сохранить высокий уровень абстракции, чтобы не уйти в детали и не ошибиться с основными решениями;
— Простейшие функции складываются в крупные, которые входят в функциональные разделы, которые тоже могут быть вложенными. Раздел «Логин и регистрация» → подраздел «Аутентификация» → функция «Валидация формы» → функция «Проверка на обязательное поле»;
— На 1-м этапе обычно описываем только функциональные разделы и ключевые функции;
— Функций всегда лютая тьма. Проще всего выявлять их через функциональные сценарии продукта (часто строятся на основе User Flow или аналогов);
— Сперва создаём базовые сценарии, затем углубляем их по мере появления детальной информации о продукте;
— Выносим отдельно функциональность, встречающуюся в нескольких разделах. Например, просмотр списка новостей (карточки новостей, их обновление и подгрузка новых) на главной и на странице «Новости».

#functional_architecture

Ралука Будиу из Nielsen Norman Group написала о кнопках переключения состояния.

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

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

Когда за всё отвечает один элемент, есть 2 варианта реализации.

1. Кнопка показывает состояние, в которое переключится система после нажатия (после нажатия текст или иконка меняются на противоположные):
— Так работают обычные кнопки — текст на них обычно говорит, что произойдёт после нажатия;
— Довольно понятное решение, если текущее состояние системы понятно из контекста. Например, кнопка «Пауза» при проигрывающемся видео.

2. Кнопка показывает свойство системы. Она может быть нажата (свойство активно) или нет:
— Например, в текстовом редакторе кнопка Bold нажата, если выделен полужирный текст;
— Показывать активность свойств системы следует одинаковым способом. В этом была ошибка WebEx.

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

https://vc.ru/design/169065

Гиги Джанелидзе написал о принципах хорошего сервиса.

Хороший сервис:
1. Востребованный. Новые клиенты приходят сами по рекомендации знакомых, так как сервис хорошо решает их задачи;
2. Не заставляет думать. Если клиент не знает, что конкретно ищет, не может правильно сформулировать запрос, сервис помогает в поиске или предлагает решение, исходя из обстоятельств;
3. Говорит с клиентами на одном языке. И это живой язык, без канцелярита;
4. Легко транслирует свою ценность. Клиент должен хорошо знать, какие задачи решает сервис;
5. Прозрачный. Клиент понимает, какой результат за какое время и по какой цене он получит. Сервис не подводит эти ожидания;
6. Упрощает клиентам достижение их целей. Узнавайте реальный User Flow, внедряйте этап Discovery и Experience Research, чтобы понимать клиентские цели;
7. Выходит за рамки основного предложения. Сервис закрывает типовые ожидания клиентов в отношении подобных сервисов и предлагает что-то, соответствующее ещё только формирующимся ожиданиям;
8. Привычный. Не меняет радикально интерфейс, к которому пользователи привыкли. А если меняет, то тщательно об этом информирует;
9. Работает без лишних посредников. Например, чтобы пополнить счёт, не надо идти в отделение;
10. Бесшовный и консистентный. Принцип одного окна — клиент решает все свои задачи через один канал коммуникации;
11. Создаётся в компаниях с культурой прозрачности и доверия. Чем разобщённее компания внутри, тем разобщённее будут её сервисы;
12. Оптимизированный. Клиент делает минимальное количество шагов, необходимое для решения задачи. Автоматизировано всё, что можно;
13. Не создаёт дополнительных проблем. В сервисе проработаны не только основные сценарии, но и второстепенные, и нежелательные для компании (отказаться от кредитки должно быть так же просто, как приобрести её);
14. Инклюзивный. В реальном мире нет идеального пользователя;
15. Вдохновляет и дарит положительные эмоции при использовании;
16. Адаптирован под изменчивый мир. Изменения могут быть прямыми (все конкуренты добавили бесконтактную оплату) и косвенными (люди стали больше думать о приватности).

https://medium.com/gigijanelidze/77330ff7032

Мэтью Стрём написал об аффордансах.

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

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

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

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

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

#affordance #definition

Вадим Митякин опубликовал 5-ю главу книги «Метод параноика» о базовом принципе метода — проектировании.

— Проект требует усилий постоянно. Надо следить за возникающими рисками и вовремя их устранять. Главный противник — неопределённость;
— Без правильной мотивации, которая учитывает их личные цели, люди не могут день за днём быть изобретательными и творческими;
— Метод максимально полезен для проектов типа «Мозги», в которых происходит поиск новых способов использования технологических инструментов в бизнесе;
— Базовый принцип метода — проектирование, то есть продумывание решения до воплощения. Альтернатива — не отсутствие продумывания, а одновременность поиска решения и его воплощения;
— Разделение проектирования и воплощения всего проекта на 2 этапа было бы возвратом к водопадной модели. Вместо этого метод предполагает разделять на 2 этапа отдельные задачи;
— Проблема в том, что те, кто говорят, что делают проектирование, фактически его не делают. Проектирование ≠ UX Design;
— В рамках метода принцип проектирования распространяется на все аспекты проекта: от организационных задач до технических вопросов;
— Проблема традиционного подхода в том, что бизнес перед проектированием плохо формулирует цели, а разработчики игнорируют решения проектировщиков;
— Проектировщики работают с первоначальными требованиями и условиями, которые даёт бизнес (описание бизнес-модели, набор функций, схемы процессов, цели проекта), но в них тоже могут быть ошибки, это скрытая неопределённость;
— Проектирование должно быть фильтром для идей и решений, отсеивающим те, которым не стоит жить и на реализацию которых не стоит тратить ресурсы;
— 3 базовых идеи: 1) Каждое решение в проекте должно уменьшать неопределённость; 2) Каждое решение требует своего уровня абстракции, компетенции и ответственности; 3) Все решения должны быть связаны между собой;
— При проектировании будущего продукта ключевая задача состоит в том, чтобы в принципе разобраться, каковы действительные требования;
— С добавлением компонентов сложность системы возрастает не только за счёт количества новых компонентов, но и за счёт их взаимодействия (новые связи, новые сценарии, затрагивающие несколько компонентов);
— В проекте должен быть тот, кто будет в дальнейшем использовать разрабатываемый продукт;
— Продукт должен быть всегда готов, но с разным уровнем детализации и проработки в зависимости от этапа работ.

https://paranoidmethod.org/paranoid-method-book-05

Михаил Правдин рассказал, как проводить больше исследований.

— Дизайн-спринты идут параллельно спринтам разработки, их результат — проработанные и обоснованные предложения для беклога. Они опережают разработку на несколько недель и не тормозят выпуск обновлений;
— В одном спринте у дизайн-команды около 5 гипотез о проблеме и её решении. Их надо проверить в течение одного спринта;
— Чтобы лучше понять клиентов, найти или проверить гипотезы, компании чаще всего проводят интервью и usability-тесты;
— Как увеличить количество таких исследований: 1) Вовлечь дизайнеров (субъективно лучший вариант из этих трёх, но есть нюансы); 2) Взять отдельного исследователя; 3) Привлечь агентство;
— Ещё один вариант — привлечь внешних экспертов-фрилансеров. Их становится больше, работать с ними становится проще, но их сложно найти (в статье есть пример решения этой задачи);
— Подойдёт, если не уверены, что команде нужен исследователь, проект на начальном этапе, нет ресурса для самостоятельных исследований или нет уверенности в правильности своих действий, хотите получить непредвзятый взгляд со стороны;
— При работе с ними важно составить хороший бриф, согласовать и детально прописать работы, сроки и ответственных, показать примеры ожидаемого результата, создать условия для подключения команды на каждом этапе;
— В сравнении с агентством получается дешевле, выше качество, исследователь плотнее общается с командой, происходит взаимное обучение;
— В сравнении с собственными исследователями фрилансеры медленнее погружаются в задачу, хуже разбираются в вашем продукте, могут не обладать доступом к какой-то внутренней информации.

https://sense23.com/post/zachem-avito-oblachnye-ux-issledovateli-i-kak-s-nimi-rabotat

Иван Меллер побеседовал с Мишей (Pinkman) и Лерой Розов (Typical).

— Об HR-компании Леры Typical и подходе No Code;
— Появлении названия конкурса Position Oneum;
— Разных шаблонах письма с приглашением на церемонию награждения «Золотой сайт» (просто приглашение и настойчивое приглашение победителям);
— Оценке проектов на конкурсах (не рандом, а пулемёт, 20 секунд на каждую работу);
— Кейс-чемпионатах, как будет обеспечиваться объективность конкурса Position Oneum;
— Переходе дизайн-студий от дизайна к консалтингу;
— Проблеме выхода в СМИ с кейсами своих клиентов (нужны бизнес-показатели, которыми клиенты делиться не хотят);
— Заградительных критериях, когда компания хочет работать со студией, но всё равно должна провести открытый тендер;
— Статуэтках за победы в конкурсах (атавизм).

https://www.youtube.com/watch?v=SCYXYPMmv4k