Страх и ненависть в продукте и агентстве

Где дизайнерам лучше живётся — в продукте или в агентстве?
Где эффективнее набираться опыта и зарабатывать?

Рассказываем про особенности работы как отдельно, так и коллаборации продукта и агентства

Слушаем!
Яндекс.Музыка
VK
Apple Podcasts

#soft_skills

Как забрать ответственность за дизайн

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

Вас могут встретить с распростёртыми объятиями:
❤️ С непониманием, зачем вообще нужен дизайнер. Без дизайнера хорошо жили, а теперь придётся натягивать непродуманные макеты на продукт
❤️ С кучей «не интуитивно понятно» и миллионом идей по UX
❤️ С желанием голосовать за дизайн

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

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

Что можно сделать?

➡️ В первую рабочую неделю собрать с команды ожидания и опасения. Подумать, насколько опасения могут оправдаться и как это можно починить.
➡️ Сделать свою работу прозрачной: рассказать команде о своём процессе работы, привлекать команду на юзабилити-тестирования, на дейликах говорить о сделанных задачах чётко и подробно.
➡️ Составить командные соглашения по дизайну: о чём не надо договариваться каждый раз, как решать споры, как проводить авторский надзор, порядок внесения идей от команды.
➡️ Не опрокидывать идеи команды: часто у команды появляются отличные идеи по продукту. Если идея не самая хорошая, то рассказывать, почему так не будет, обучая команду. Если идея вам не нравится, но вы не можете объяснить, почему, то пробовать приземлить её и развить.
➡️ Не соглашаться на голосование за дизайн: таким образом количество голосов может влиять на качество интерфейса и ваша экспертиза будет обесценена.
➡️ Погружаться в предметную область, изучать пользователей и их задачи. Узнать о продукте и окружающей его мире как можно больше и обернуть знания в схемы и фреймворки.
➡️ Предлагать идеи, показывать команде макеты, рассказывать о заложенной логике и обрабатывать обратную связь.
➡️ Показывать экспертизу и делиться ей. Если вам кажется, что никакой экспертизы у вас нет, то слушать наш подкаст и делиться знаниями с командой :)

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

#soft_skills

Тестовое иии ваааайтборд!

Вы просили и мы сделали!
➡️ Чего ждать от нанимающих при проверке тестовых?
➡️ Как проходят и оцениваются вайтборды?

Все наши секреты в очередном эпизоде

Слушаем!
Яндекс.Музыка
VK
Apple Podcasts

#soft_skills

Летние каникулы

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

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

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

Мы тоже решили немного отдохнуть и не красть у вас ни лучика этого лета. Мы вернёмся в сентябре со своими любимыми зубодробительными темами: Метод Персон, JTBD, OOUX и многое другое.

До встречи в сентябре! ❤️

Персоны... Всему голова?

Мы отдохнули, набрались сил. Пришло время их тратить!) Начинаем наш второй сезон ✨

Метод персон — универсальный фреймворк или очередной дедовый пережиток? Рассказываем, как всегда на пальцах:
➖ Что это, как создавать
➖ Когда использовать и когда нет
➖ Чем можно заменить

Что где
00:00 Приветствие
03:00 Что такое персоны и зачем они нужны
10:50 Из чего состоят персоны
15:06 С чем путают персоны
17:45 Типы персон
26:00 Как делать персон
36:40 «А можно попроще?»
41:06 «Персоны не работают»
54:50 Заключение

Слушаем!
Яндекс.Музыка
VK
Apple Podcasts

Полезные материалы:
1⃣ Vanilla Thunder «Ещё одна статья о персонах»
2⃣ Алан Купер «Интерфейс», третий параграф

#ux_frameworks

Давайте пошатаем наше понимание элементов интерфейса

Вот, к примеру, табы. Вроде бы понятный элемент. Интуитивно понятный. Переключай себе вкладки, работай с тем, что они в себе прячут. Но! У табов есть своя история, варианты использования, особенности и даже брат: аккордеон! Давайте присмотримся.

Почему они выглядят так?

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

Из чего состоят табы? Без чего табы — не табы?

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

🚫 Без этих составляющих табы превращаются в заголовки, выделенный текст — что угодно, но не табы.

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

Для чего табы используют, а для чего — нет?

Можно и полезно использовать для навигации и сегментации контента на странице: в открытом по умолчанию табе самое важное. Если табов много, можно уводить их в карусель или сворачивать в таб “Ещё”. Не рекомендуем использовать во всех остальных случаях: как фильтры, часть формы ввода (вместо чипс, например)

Сколько табов за раз лучше ставить в линию — есть ли ограничения? Можно разместить табы в несколько линий?

Минимум два. Максимума нет, но мы стремимся делать не слишком много табов. Сколько это — не слишком много? Определяет контекст, у нас в среднем эффективно показывают себя 3-7 табов, остальные свёрнуты в “ещё”. Если пользователь выбирает вариант из “ещё”, он подменяет таб перед “ещё”.

🚫 В две и более линий ставить табы не стоит — они будут занимать место на экране и усложнять выбор между собой.

Показывать задизейбленный таб — моветон?

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

Можно ли заменить табы аккордеоном?

Можно! Но не всегда. Он тоже сворачивает контент, работает как картотека, более гибко работает с длинными метками. В мобилке встречается чаще, т.к. разворачивается по вертикали, а не по горизонтали, как табы.

🚫 Он не так хорош для навигации по приложению и не может включать в себя сильно отличающийся контент, в отличие от табов.

Вот так табы из бездушных “каких-то там” превращаются в хороших ребят с прабабкой, братом и своими ништяками. Держите клёвую статью NNG о них.

#ux_frameworks #articles

JTBD: великий и прекрасный

Очередной модный фреймворк или... Да ладно, вроде бы уже все согласны, что это крутой и всемирно признанный инструмент.

Однако, с ним не всё ясно:
➖ Что за тёрки между эмоциональным и функциональным видами?
➖ Правда ли Job Story почти тоже самое, что и User Story?
➖ А при чём тут проектировщики? Это же инструмент для оунеров...

Что где
00:00 Приветствие
02:48 Что такое Jobs-to-be-Done
09:50 Формула Job Story
19:10 Формула Job Statement
22:30 Джон стори и юзер стори
31:28 Как собирать инфу для JTBD
35:20 Где можно использования JTBD
43:30 «JTBD не работает»
55:00 Заключение

Разрушайте мифы вместе с нами в этом эпизоде!
Яндекс.Музыка
VK
Apple Podcasts

Полезный материал, который обещали в эпизоде:
Канвас Тони Ульвика

#articles

Ещё раз про «Не интуитивно понятно»

Посолим наши раны. Многие из вас уже встречались с ситуациями, когда кто-то говорит, что интерфейс не интуитивно понятный. А если нет, то обязательно встретитесь, это мы вам гарантируем! Как на это реагировать? Тренироваться в злословии?

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

Для команды разработки
Чаще всего люди отвечают, что лично им непонятно, как что-то работает

➡️ Расскажите, в чем разница между ментальными моделями пользователя и говорящего. Объясните на примерах, чтобы не показаться невыносимой всезнайкой, бросающейся умными словами :) То, что понятно пользователю, может быть не понятно команде. И наоборот! Вроде бы очевидная и абсолютно понятная вещь. Однако, люди склонны подменять опыт пользователя своим. Нинада так.

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

➡️ Чтобы команда поняла пользователя, сделайте персон. Нет времени на персон? Предложите А/Б-тесты и метрики. На это тоже времени нет? Зовите команду на исследования слушателями. Познакомьте их.


Для пользователей
Cтоит выяснять, что смущает КОН-КРЕТ-НО. Мы собрали для вас частые причины «неинтуитивности»

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

➡️ Революционный дизайн. Даже если новый дизайн является прорывом, в первое время он может пугать пользователя

➡️ Интерфейс перегружен. Избыток информации, акценты неверные или их слишком много

➡️ Наоборот, интерфейс слишком лаконичный. Мало афордансов, нет акцентов, подсказок

➡️ Интерфейс сделан не по по ментальной модели, а по модели реализации, то есть содержит в себе непонятные пользователю элементы и текст (зато этот интерфейс будет идеален для понимания команды))

Как вы обычно реагируете на эти слова? Напишите в комментариях!)

#articles

ООUX — тот самый мост между исследованиями и макетами

Ещё один артефакт дизайнерской аналитики. Если вы хотите задать вопрос «А макеты-то когда рисовать?», то обещаем: после этого фреймворка макеты потекут рекой.

Да какие... учитывающие особенности предметной области и восприятия пользователей! Ну кайф же ✨

Что где
00:00 Приветствие
04:20 Что такое OOUX и чем он полезен
12:30 Как готовить OOUX
18:55 Подводные камни и типичные ошибки
34:48 Варианты использования OOUX
49:56 «OOUX не работает, а можно попроще?»
01:00:26 Заключение

Слушаем!
Яндекс.Музыка
VK
Apple Podcasts

#articles

Чекбоксы, радио, чипсы, сегмент-контрол

Все мы знаем, что
👍 Пользователь должен выбрать что-то одно из группы? Ставь радио-кнопки
👍 Пользователю нужен мультивыбор? Ставь чекбоксы

Делов-то! Но почему тогда
🤔 Мы привыкли использовать чекбокс для соглашения с правилами и политиками? Он же один)
🤔 Радио-кнопки не дают отменить выбор. Нет права на ошибку?
🤔 Группа радио-кнопок никогда не должна отмечатья как обязательное поле?

И ещё вдогоночку
🤔 Что это у нас за новый-старый зверь сегмент-контрол? Это что, замена радиокнопкам? Или это элемент навигации?
🤔 А чипсы тоже элемент навигации или это ещё одна замена.. Чекбоксам? Радиокнопкам? Шта?)

Давайте разбираться.

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

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

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

Чипсы
Тоже не элемент навигации. Но всё равно это молодец, который и на дуде игрец: может заменить как группу чекбоксов, так и группу радио-кнопок.

А как вы используете эти элементы? Приглашаем обсуждать и спорить в комменты)

Метрики

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

Гидом будет наш гость, Андрей Одокиенко, автор канала Design Twist.
Держите бонусом исследование Андрея о работе с метриками среди дизайнеров в продукте и студии

Что где
00:00 Приветствие
02:55 Что такое метрики
16:08 Как работать с воронками
24:35 Экономические и продуктовые метрики
37:11 Интерфейсные метрики
47:42 Как встроить метрики в рабочий процесс
01:01:10 «Метрики не работают»
01:12:00 Заключение

Слушаем!
Яндекс.Музыка
VK
Apple Podcasts

#articles #ux_frameworks

Элементы интерфейса, которыми «никто не пользуется»

Вдруг вы, так же как и мы, слышали в своей практике что-то такое:

➡️ Если вам приходится делать тур и или онбординг — это признак низкого юзабилити. Интуитивно понятный интерфейс в таких костылях не нуждается! Люди всё равно их пропускают в 99% случаев!

➡️ Добавлять вопросики с подсказками нет смысла. Люди не замечают и читают вопросики. Лучше разместите подсказку сразу на форме.

Мы даже как-то натыкались на исследование о том, что вопросики НУНИКТОНЕЧИТАИТ.

Но тогда кто и зачем их использует? Глупенькие дизайнеры, чтобы побесить лишними кликами ленивых пользователей?) Или это авторы высказываний выше — дураки? Штош, давайте жить дружно. Никто тут не дурак.

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

Подсказки
Пользователи правда не читают подсказки. Но! Только когда они всё понимают или ДУМАЮТ, что понимают. В момент, когда к человеку приходит осознание, что понятно не всё — он начинает искать подсказки намеренно. Чаще всего, это происходит в профессиональных и сложных продуктах. Можно парировать, мол «ну просто проектировать надо так, чтобы было понятно». Принимается, если тот, кто это говорит, может предоставить вариант дизайна сложной системы, которую поймёт не слишком погруженный пользователь. Таких всегда хватает. Вот прям с вариантами использования протоколов безопасности, типов подключения к серверам, выбора домена n-ного уровня... Когда продукт решает вопрос для новичка в сложной сфере, иногда приходится объяснять каждое поле.

Снова все правы. Соблюдаем баланс! ✨

#articles

Проектный и продуктовый майндсеты

Вы всё ещё используете проектный подход?! Ну и молодцы!
Продуктовый подход? Тоже молодцы!

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

Что где
00:00 Приветствие
04:34 Что такое продуктовый и проектный майндсет
14:30 Так продукт мы или проект?
26:42 Когда произошло изменение подхода
33:55 Фреймворки продуктового майндсета
54:14 Боль перестройки дизайн-процесса
01:16:32 Как уберечь себя от негативных последствий
01:21:30 Заключение

Слушаем!
Яндекс.Музыка
VK
Apple Podcasts

Бонус: Димина статья про 10 увечий на пути от проекта к продукту

#articles

Заходят Скелетон, Лоадер и Прогресс-бар в бар...

Давайте поиграем. Мы задаём вопрос, вы отвечаете про себя, а потом открываете скрытый текст. Если не согласны — поспорьте с нами!)

Итак!

1⃣ Какой из этих трёх элементов больше всего подходит под загрузку более 10 секунд?

Прогресс-бар
Особенно когда он привязан к процессам загрузки, а не просто быстро пробегает до 99% и останавливается, издевательски занеся ногу над порогом.

2⃣ Какой из элементов лучше показывает загрузку всей страницы разом?

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

3⃣ Какой из элементов более универсален?

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

Чтоб не быть голословными, делимся видосом от NNG по этой теме

#articles

Сценарии

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

Мы думаем, что есть. В этом эпизоде расскажем:
➖ Почему нельзя проектировать только хеппи флоу и что тогда ещё проектировать
➖ Зачем носить шапку пессимиста и придумывать за пользователя ошибки

И вообще... Упс, что-то пошло не так :)

Что где
00:00 Приветствие
05:30 Что такое сценарии и зачем они нужны
17:55 Какие сценарии бывают
24:10 Happy flow
32:46 Альтернативные сценарии
35:34 Ошибочные сценарии
41:10 «Намеренные и ненамеренные» ошибки
46:05 Ошибки на мостах выполнения и оценки
51:37 Технические ошибки
59:32 «Сценарии не работают»
01:06:34 Заключение

Слушаем!
Яндекс.Музыка
VK
Apple Podcasts

#articles

Конфирм в виде модального окна — зло?

Мы стремимся защитить пользователя от потери данных. Когда он что-то удаляет, мы обязательно спрашиваем, уверен ли он в своём намерении.

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

Этот пост всё опять испортит. И что вы нам сделаете.

Что если мы скажем, что модалка-конфирм — неэффективна?
Думаем, многие из нас узнают себя в сценарии: удаляешь что-то, тебя как всегда бесячая машина спрашивает, а не дурак ли ты, вдруг дурак, проверь. Ты говоришь, да удали уже, попросили же. А через секунду доходит, что удалил не то. Бьёшь себя по лбу, соглашаешься с машиной, что ты дурак... Но удалённое уже кануло в лету, вместе с твоей самооценкой.

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

Модалка-конфирм в какой-то момент входит в привычку и человек начинает работать с ней машинально, не подключая медленную систему. Чтобы действительно обезопасить пользователя от неверного действия, надо «разбудить» его, чтобы он осознал, что вот-вот произойдёт. Для этого отлично срабатывает оповещение об исполнении задачи. Удалил? Удалено, но ты можешь вернуть файл ещё 5 секунд. Например, это можно офрмить в виде снек-баров. Или тостов, кому как привычнее.

И эт не мы придумали.
➡️ Об этом можно прочитать у Раскина в книге «Интерфейс», всем рекомендуем.
➡️ А про быстрые и медленные системы мышления рассказал Канеман в книге «Думай медленно... Решай быстро»

Так что да, конфирм в виде модального окна — зло. Такие дела

#articles

Информационная архитектура

Царица UX, которая не терпит равнодушия со стороны дизайнеров. Может одарить приложение успехом в юзабилити, а может ежедневно карать вас и пользователей, если её обидеть. В общем, настоящая женщина.

🔗 Библия этой серии — «Информационная архитектура в Интернете» (П.Морвиль и Л.Розенфельд)
🔗 Канал Хуикс — кладезь дизайн-аргументации

Что где
00:00 Приветствие
01:04 Почему мы говорим про информационную архитектуру
14:12 Что такое информационная архитектура
23:10 Процесс поиска информации
29:20 «Информационная архитектура не нужна»
34:42 Из чего состоит информационная архитектура — организация
42:28 Маркировка
49:38 Навигация
55:24 Поиск
59:12 Где информационная архитектура реально не нужна
01:02:30 Как готовить информационную архитектуру
01:17:32 «Информационная архитектура не работает»
01:29:42 Заключение

Слушаем!
Яндекс.Музыка
VK
Apple Podcasts

Конец года, конец сезона

Если вы:
➡️ Слушаете по сей день наш подкаст и читаете статьи
➡️ Дожили до конца этого года и не свихнулись...
То вы большие молодцы!

Мы очень рады, что дизайнеров, которые не боятся сложностей в UX, так много!

Мы завершаем сезон про проектирование. Берём паузу, чтобы украсить дом, нарезать салаты, уничтожить вагон мандаринов... Присоединяйтесь к этим интересным занятиям)

Мы вернёмся в новом году с сезоном про лидерство. Расскажем, почему стоит и НЕ стоит идти по этому пути, как забирать лидерство за дизайн (но не всё) и много, много чего ещё. Также позовём гостей, которых многие из вас знают. Будет полезно!)

С наступающим!