Энтони из UX Movement написал о таком состоянии кнопки как «загрузка».

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

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

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

Чтобы пользователь лучше понимал, что происходит, текст на кнопке можно менять, например: «Отправить» → «Отправка…»

https://ux.pub/v-kakih-sluchayah-neobhodimy-knopki-s-indikatorom-zagruzki/

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

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

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

Юлия рассмотрела плюсы и минусы 4 основных инструментов и сделала выводы, для каких исследований они подходят:

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

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

3. Excel или Google Таблицы. Подходит для любых количественных данных. На одном листе могут быть исходные данные, а на других — результат их обработки. Можно делиться с командой промежуточными результатами с дополнительными гипотезами и инсайтами.

4. Word или Google Документы. Подходит, когда не нужны рекомендации по изменениям, а нужны только факты по результатам исследования (например, перечень проблем, с которыми столкнулись пользователи). Отчёт в таком формате легко оформить.

https://medium.com/julie.kozhukhova/284673aa2b6e

Опубликованы записи лучших докладов с 404fest 2018:

1. Антон Шеин, арт-директор, Яндекс Поиск — Мечтать вредно
youtube.com/watch?v=0wgj5ARt-GU

2. Евгений Кот, frontend teamlead, Wrike — Flutter против мобильной Инквизиции
youtube.com/watch?v=EazZVeXSqGQ

3. Михаил Танский, дизайнер и cо-основатель, Хантфлоу — Дорогой UX: экономим на всём. Несколько историй про интерфейс и бабло
youtube.com/watch?v=KBlsZRpdows

4. Денис Пушкин, head of product marketing, Skyeng — Как заработать миллиард
youtube.com/watch?v=6pVVA_E6uG4

5. Владимир Маринович, ex-CEO GetTaxi, основатель бизнес-школы Вверх — Типология отмазок и способы борьбы с ними
youtube.com/watch?v=h8RCViK__p4

6. Сергей Котырев, директор, 1C-UMI — Мой путь предпринимателя и менеджера. Период зрелости
youtube.com/watch?v=hNqAf_c7TPQ

7. Евгений Казначеев, head of product, Ecwid — Как сделать тайм-менеджмент, если ты ленивая безвольная скотина
youtube.com/watch?v=6soEK56hd9s

8. Александр Ковальский, design director, CreativePeople — Дизайн-прокачка: как мы качаем дизайнеров в агентстве
youtube.com/watch?v=LqVpjctBzew

9. Самвел Аветисян, ex-главный маркетолог Тинькофф, основатель АрхИдея — Тренды потребления в эпоху перепостмодернизма
youtube.com/watch?v=KMKddJMK88c

10. Евгений Романовский, руководитель проектов, Собака Павлова — Добро пожаловать в мир сложных интерфейсов
youtube.com/watch?v=9GB0vF8zLBI

Все видео с описаниями в одном месте: https://habr.com/ru/company/404fest/blog/465973/

Михаил Греков написал о формах, с которыми пользователи работают постоянно.

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

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

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

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

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

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

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

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

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

Изображения и файлы:
— Автоматически обрабатывайте картинки так, чтобы они подходили под требования (сжатие, кадрирование, изменение формата), не грузите пользователя некритичными требованиями к загружаемым картинкам.
— Дайте возможность загрузить файл перетаскиванием, вставить из буфера обмена.
— Поддерживайте загрузку сразу нескольких файлов.

https://designpub.ru/ed64e2e367b4

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

1. Больше времени тратьте на самообразование, а не заказы. Если человек что-то уже делал, это не значит, что он делал это хорошо. Чем больше времени вы тратите на добывание денег, тем дольше будет путь наверх.

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

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

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

4. Обращайтесь в студии, в которых мечтаете работать. Многие из них готовы к удалённому сотрудничеству.

https://awdee.ru/to-manhattan-from-siberia/

Дизайнер Лили написала про 12 типов тёмных паттернов.

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

2. Заставить испытывать вину или стыд. 2 кнопки: «Скачать буклет о здоровом питании» и «Нет, спасибо, мне плевать на своё здоровье».

3. Замаскировать рекламный баннер. На баннере может быть изображено содержимое или элементы навигации, которые ожидает увидеть пользователь.

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

5. Собирать контакты друзей и спамить им от вашего лица. Как LinkedIn.

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

7. Затруднять сравнение цен. Например, одни и те же яблоки в упаковках и на развес.

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

9. Упрощать пользователям желательные (для вас) действия и затруднять нежелательные. Попробуйте удалить свой профиль на Фейсбуке.

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

Запрещено в Великобритании:

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

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

https://vc.ru/design/76845

Илья Александров написал о дизайне предсерийного прототипа «Симкомата Х».

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

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

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

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

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

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

https://vc.ru/design/80772

Михаил Озорнин написал о выравнивании данных в таблице. Это не пересказ Мильчина, правила основаны на опыте Михаила.

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

2. Числа — по правому краю. Числами считаем то, что имеет смысл сравнивать друг с другом. Инвентарные номера, индексы, номера паспортов, IP-адреса — не считаем числами.

3. Диапазоны — по разделителю. Примеры пар чисел, написанных через разделитель: 1…15, 1—15, 1 / 15, 1 из 15. Разделитель становится для них осью.

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

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

http://mikeozornin.ru/blog/all/how-to-align-data-in-table/

Рейчел Бергер написала о влиянии технологических компаний на дизайнерские портфолио.

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

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

Сами дизайнеры не считают это главной проблемой. Чтобы пополнять портфолио, надо делать проекты (1), которые хочется показать (2) в портфолио (3).

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

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

2. Непонятно, что дизайнер получит от пополнения портфолио. Работа у него и так есть.

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

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

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

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

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

[English] https://modus.medium.com/218bcbc11080

Анна Данилова написала о тире. То, что мы обычно называем просто «тире», — это длинное тире.

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

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

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

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

Короткое тире (En dash) в современном русскоязычном наборе чаще всего используется для обозначения числовых диапазонов, например 1990–1998. В текстах на английском короткое тире используется в любом диапазоне, даже если он набирается словами: October–November. Короткое тире в таких ситуациях не отбивается пробелами.

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

https://type.today/ru/journal/dash

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

Индустрия — это экосистема. Большинство проектов реализуется несколькими компаниями, командами и отдельными специалистами в симбиозе. Клиенты обращаются в компанию, которая нанимает себе в помощь продакшн для разработки и т. п.

Типовая производительность в час — полная профанация. Точная предварительная оценка проекта невозможна в принципе. Всё зависит от конкретного проекта и конкретного специалиста.

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

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

Типы исполнителей:
1. Фармацевт (самый распространённый) — классический аутсорсинг. Клиент приходит со сформулированной задачей, исполнитель через некоторое время выдаёт результат.
2. Сиделка — агентства. Исполнитель интенсивно общается с клиентом, работа выстроена вокруг долговременных целей клиента.
3. Нейрохирург — системные интеграторы и технологические исследовательские центры. Похоже на фармацевта, но часто сутью задачи является выяснение, в чём именно заключается проблема клиента и поиск её решения. У задач — преимущественно технологический характер.
4. Психотерапевт — продюсеры ИТ-проектов. Клиент обозначает проблемы в бизнесе или возможные точки развития, а исполнитель помогает подобрать наиболее удачный способ решения.

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

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

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

https://mityakin.ru/paranoid-method-book-1

Адам Сильвер написал о всплывающих подсказках (tooltip).

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

Проблемы:
1. Пользователи не всегда замечают, что подсказки есть.
2. Пользователь должен что-то сделать, чтобы получить подсказку. Плохо, если в ней находятся, например, требования к паролю. Скорее всего, пользователю придётся их посмотреть.
3. Подсказки могут частично закрывать содержимое и элементы интерфейса. Чтобы заполнить поле, пользователю придётся запомнить текст подсказки.
4. Подсказки могут обрезаться на маленьких экранах.
5. Элементом, с которым пользователь взаимодействует для отображения подсказки, может быть иконка без подписи. В этом случае не всегда бывает понятно, как указать на этот элемент при голосовом взаимодействии с интерфейсом. «Нажми на колокол, нажми на уведомления…»
6. Отображение подсказки при наведении курсора — не самый удобный способ взаимодействия: курсора нет на тачскринах, ховер может быть отключен, сложно прицелиться, пользователь может навести курсор случайно, нельзя взаимодействовать с текстом подсказки (например, скопировать).

Решения:
1. Переделайте дизайн. Если для работы с интерфейсом пользователю нужны подсказки, это плохой интерфейс.
2. Подпишите иконки или замените их на текстовые ссылки.
3. Сделайте важные пояснения видимыми по умолчанию.
4. Для подсказок используйте inline toggle, который активируется кликом и не скрывает содержимое с элементами управления.

https://ux.pub/problemy-s-podskazkami-tooltips-kak-ih-razreshit/

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

1. Люди не читают, а сканируют. Дробите текст, выделяйте ключевые слова.
2. Создавайте явную визуальную иерархию. Делайте заметнее более важные объекты, группируйте связанные.
3. Не изобретайте колесо. Придерживайтесь сложившихся сценариев взаимодействия. Предлагая новое решение, прикиньте, во сколько (времени и усилий) обойдётся его внедрение.
4. Убирайте инструкции, интерфейс должен быть понятен без них. Если без инструкций не обойтись, смотрите пункт 1.
5. Учитывайте, что люди не знают, как работает ваш продукт, и не хотят разбираться.
6. Людям не так уж важны едва уловимые детали и эффекты в ваших продуктах. Убедитесь, что пользовательский сценарий полностью проработан, и полируйте дизайн после этого.
7. Не путайте фокус-группы и юзабилити-тесты. Первое — обмен мнениями и групповое обсуждение (например, продукта). Второе — наблюдение за человеком, который использует продукт.
8. Помните, что люди не похожи на вас. Принимая решения, не концентрируйтесь только на личных ощущениях.
9. Учитесь задавать правильные вопросы.
10. Пользователь не должен думать «где я», «с чего мне начать», «куда делось …», «что здесь самое важное», «почему они так назвали это», «это реклама или часть сайта?». Это отвлекает его от более важных вопросов: «Зачем я здесь» и «Что мне надо сделать».

В переводной статье почему-то нет ссылки на оригинал и даже его названия, так что стоит сослаться здесь:
— Перевод: https://usabilitylab.ru/blog/10-melkih-oshibok-v-dizajne-kotorye-my-po-prezhnemu-sovershaem/
— Оригинал: https://uxplanet.org/1cd5f60bc708

Наталья Стурза рассказала, когда продуктам полезны UX-исследования:

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

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

3. Улучшить то, что работает. Клиенты банка заполняли юридически значимое поле «Назначение платежа» всякой белибердой. Юзабилити-тесты показали, что люди считают поле второстепенным и заполняют только затем, чтобы кнопка платежа активировалась. В итоге в плейсхолдере поля показали пример, и таких ситуаций стало на 30% меньше.

4. Сравнить между собой конкурирующие продукты или отдельные фичи.

5. Понять, сколько потенциальные клиенты готовы платить.

6. Найти ошибку в интерфейсе.

Исследования не пригодятся:

1. Сервисам про фан вроде MSQRD и сервисам-витаминкам вроде приложений для медитации. У них сложно выделить пользовательскую потребность или проблему.

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

https://vc.ru/design/86942

Игорь Штанг рассказал о вёрстке иллюстраций.

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

02:27 — Неоднородность пустого листа;
03:22 — Верх-низ, право-лево, центр-периферия;
06:09 — Кручу машинку на формате;
13:32 — Кадрирование;
17:26 — Сюжетная и композиционная динамика;
21:38 — Реклама Фольксвагена Жука 1960-х;
28:13 — Удачное и неудачное кадрирование;
32:20 — С полями или без;
35:47 — Ракурс.

Смотреть лучше на скорости 1,25 или 1,5.

https://www.youtube.com/watch?v=4DxJ84yfoh4

В Usethics написали о том, как объединить подход персонажей и Jobs to be done.

JTBD описывает потребности пользователя по формуле: когда X, я хочу Y, чтобы Z. «Когда я не знаю, как добраться до места (X), я хочу быстро узнать направление (Y), чтобы прийти, куда нужно (Z).

Во подходе персонажей первое место занимает персонаж: как Х, я хочу Y, чтобы Z. «Как турист (X), я хочу быстро узнать направление (Y), чтобы прийти, куда нужно (Z)». Персонажи рассказывают о пользователях продукта, а «работы» сообщают об их ключевых целях.

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

У приложения-будильника ключевая работа — проснуться и встать вовремя. Используя JTBD, при редизайне мы не фиксируемся на конкретном решении в виде будильника. Человек может попросить другого человека разбудить или лечь спать заранее, чтобы проснуться самостоятельно и т.п.

Объединённый подход:

1. Выделяем типы пользователей. Думаем, какие индивидуальные особенности могут повлиять на их опыт выполнения работы (базовые шкалы свойств персонажей). Например: соседство с другими в спальне. Выдвигаем гипотезы о персонажах, но не наделяем их социально-демографическими характеристиками.

2. Проводим интервью, где оцениваем участников с точки зрения выделенных свойств, узнаём контекст, делим работу на составляющие («подработы»). Например: Подготовка ко сну → Планирование подъёма утром → Засыпание → Сон → Пробуждение → Подъём. Это не обязательно должна быть последовательность.

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

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

5. Составляем карту пользовательского опыта для каждого персонажа. В ней могут быть слои опыта: цели/потребности, опасения, действия, барьеры, инструменты, эмоции.

6. Profit (выявляем инсайты о проектируемом продукте).

https://medium.com/usethics-doc/b35d4174cea3

Эмилия Городовых рассказала о применении JTBD в сложном продукте.

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

Решили использовать JTBD из-за проблемы: продукт менялся в основном с подачи крупных клиентов, т.к. их требования легко превращались в бизнес-метрики. Требования мелких клиентов просачивались в продукт только вместе с результатами внутренних юзабилити-тестов.

Термин «работа» заменили на «задачу», чтобы было проще разговаривать с клиентами. Они плохо понимали вопрос: «Для какой работы вы нанимаете Диадок?»

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

Оказалось сложно работать по формуле «Контекст — Мотив — Результат», решили её перевернуть и начинать с результата.

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

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

1. Подготовка. Получить список документов для подписания. Выявленная проблема связана с этой подзадачей, т.к. не все пользователи знали про расширенный поиск и как работают его поля.
2. Выполнение. Проверить правильность документов и подписать их.
3. Отслеживание. Понять, все ли документы подписаны.
4. Завершение. Удостовериться, что компания получила все деньги вовремя. Если пришли не все деньги, понять, почему.

Ранжировали подзадачи по критериям: а) важность, б) доволен ли сейчас клиент, работающий над подзадачей. То, что важно и работает, надо не сломать. Что важно и не работает, надо починить. Остальное — нишевые подзадачи.

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

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

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

Эдвард Скотт написал о сравнении товаров в интернет-магазине.

Прежде, чем добавить эту функцию:

1. Проверьте, что у вас есть данные о параметрах товаров и что они структурированы, то есть, например, размеры не указаны то в сантиметрах, то в миллиметрах.

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

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

Если вы уже добавили:

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

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

3. Дайте легко перейти к сравнению выбранных товаров. Например, отобразите панель с кнопкой «Сравнить выбранные товары» и миниатюрами этих товаров, прикреплённую к нижней или верхней границе окна браузера.

https://ux.pub/ux-rekomendatsii-po-uluchsheniyu-instrumenta-sravnenie-tovarov/

Опубликованы записи докладов с Design Prosmotr 2019 (март, апрель).

1. Артур Арсёнов, Looi — Темная сторона продуктового дизайна
youtube.com/watch?v=B3oq4VDYbMA

2. Ноу Нейм, UX Live — UX 2077
youtube.com/watch?v=hfNN02_VYH8

3. Владимир Шрейдер, Glitché — Glitché. Ошибки поколения
youtube.com/watch?v=3Ft3cNaYTtU

4. Максим Ильяхов, Главред — Ваша последняя лекция про текст
youtube.com/watch?v=_jwKQ6ZCeAI

5. Роман Горбачёв, Логомашина — 10 инсайтов из 10 000 звонков
youtube.com/watch?v=B-zXiApNzbI

6. Александр Загорский, BBDO Branding — Я дизайнер. Зачем я это делаю?
youtube.com/watch?v=SoJGlftony0

7. Николай Хлопков, Whitemark — Бизнес и творчество в балансе
youtube.com/watch?v=o_CsjZqgun8

8. Юрий Ветров, Mail.Ru Group — Дайджест продуктового дизайна
youtube.com/watch?v=_bMlwh4xgdY

9. Игорь Штанг, Типографика и верстка — Верстка иллюстраций (было недавно в UX Notes)
youtube.com/watch?v=4DxJ84yfoh4

10. Вениамин Векк, М18 — Смотреть, ворчать и умнеть
youtube.com/watch?v=YXNp_F6XmYc

В одном альбоме ВК: vk.com/videos-50773057?section=album_33

Игорь Штанг написал об использовании буллита как маркера в списке.

До 1990-х годов в русской типографике не было буллитов. Они пришли из американского набора с программами вроде Ворда и Поверпоинта. По умолчанию у последнего были такие настройки, с которыми не ставить буллиты было труднее, чем ставить.

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

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

Если надо использовать буллит:
1. Искусственно уменьшить кружок в полтора-два раза. Так он не будет жирнить. В некоторых шрифтах символ сам по себе небольшой.
2. Сделать буллит цветным или серым.
3. Оставить как есть или даже увеличить, но поддержать другими жирными элементами. Смотрите пример из книги Ласло Мохой-Надя «Живопись. Фотография. Кино», 1927.

https://nobelfaik.livejournal.com/199470.html

Дима Хими написал о неправильном примере Job story в статье Usethics про объединение подхода персонажей и Jobs to be done. (Было недавно в UX Notes.)

Из-за такого примера может возникнуть ощущение, что JTBD не закрывает все аспекты. Это может вызвать необоснованные претензии к подходу.

«Когда я не знаю, как добраться до места (X), я хочу быстро узнать направление (Y), чтобы прийти, куда нужно (Z)» — неправильная Job story, так как решение зеркалирует проблему и содержит в себе точное её решение. Мы сразу представляем себе навигатор.

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

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

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

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

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

— Пост Димы: facebook.com/dimahimi/posts/2416057165179001
— Статья Usethics: t.me/uxnotes/505