uxtrends

Ну что, скучали? Последние недели были довольно насыщенными на работе, зато в эти выходные мне удалось сгонять в Берлин на UXcamp Europe. Хочу поделиться своими впечатлениями. UXcamp — это интернациональная конференция для UX экспертов. Концепция мероприятия построена вокруг идеи, что любой желающий может предложить свою тему. Все заявки собираются в начале дня и формируют расписание. Из плюсов: - Большое количество докладов, воркшопов и дискуссий на продуктовые и UX темы. - Интернациональная, профессиональная аудитория. - Отличная площадка для нетворкинга в непринужденной студенческой атмосфере (конференция проходит в здании Берлинского университета имени Гумбольдта). Из минусов: - Билеты бесплатные, но их количество ограничено. Мне не удалось получить билет в официальный день регистрации (они разошлись меньше чем за минуту), зато можно встать в очередь и получить билет, если кто-то откажется. В итоге я получил свой билет за 3 дня до старта мероприятия. - На каждый доклад отводится всего 45 минут. Поэтому некоторые доклады получаются немного поверхностными, но это ещё зависит от темы и спикера. - Параллельные доклады, из-за чего невозможно попасть на все интересные. В целом, UXcamp - отличное место для старта карьеры в западной компании, так как спонсоры часто ищут новых сотрудников и через доклады можно заявить о себе. Знаю ребят, которые таким образом нашли себе новую работу. Ну и конечно же оно стоит того ради выступлений крутых спикеров. Про некоторые инсайты напишу отдельной статьей!

Как работать с Figma в продуктовой команде  Недавно начал работу над новым проектом и столкнулся с полнейшим хаосом в файлах Figma. Предыдущий дизайнер покинул проект после нескольких лет работы, не оставив четкой документации. Как результат — несколько дней пришлось потратить на то, чтобы просто разобраться в структуре проекта. В связи с этим решил коротко написать о том, как можно улучшить работу в Figma если вы работаете в большой команде. В первую очередь, важно осознать, что макеты вы создаете не для себя или своего портфолио, а для вашей продуктовой команды. Поэтому при создании скринов следует подходить к этому процессу, как к созданию документации. В конечном итоге, вы же не хотите, чтобы вас постоянно беспокоили программисты или product-owner с вопросами о местонахождении актуальных макетов? Вот несколько советов, как можно упростить жизнь и себе и команде: 1) Логически структурируйте рабочее пространство в Figma Разделите файл на отдельные страницы для различных целей, чтобы любой сходу мог разобраться, где у вас что находится. Отдельные страницы Figma файла могут отображать agile процесс в вашей компании: Текущий спринт: тут находятся скрины над которыми программисты работают в текущем спринте. Артбордам можно дать имя тикета с ссылкой в Jira, Azure DevOps или что у вас там используют в компании... Так программисты по умолчанию будут знать где найти скрины к текущим задачам. Архив спринтов: тут законченные спринты с номером тикета и ссылкой в хронологическом порядке  Бэклог: концепты макетов для будущих спринтов  Актуальная версия продукта: текущая версия продукта по возможности в виде пошагового флоу со всеми взаимосвязями. Черновик: пространство для черновых вариантов и будущих концептов Лично мне такая модель структурирования помогает упорядочить макеты и обеспечить легкий доступ к необходимым данным для остальной команды. 2) Используйте пояснения Помогите участникам команды ориентироваться в ваших макетах. Подписывайте артборды и секции чтобы из надписи было понятно что там находится. Кроме того, можно добавить текстовые пояснения к вариантам элементов интерфейса и применению микро-интеракций. 3) Используйте единую библиотеку UI компонентов Часто над продуктом работает сразу несколько команд, поэтому целесообразно хранить UI компоненты отдельно от рабочего дизайна. У вас может быть сколько угодно рабочих файлов с дизайном продукта, но библиотека всегда будет единой. Так, вашим программистам будет гораздо проще отыскать актуальную версию того или иного UI элемента в библиотеке. Это обеспечит легкий доступ к актуальным элементам интерфейса для всех членов команды и сделает работу более последовательной. На этом все! А как вы организуете работу с командой в Figma?

Зачем тестировать юзабилити По опросу выходит, что почти половина не читала предыдущую статью, а многие не собирают метрики после пользовательских тестов 🤦‍♂️ Тут напрашивается вопрос – а зачем тогда вообще проводить юзабилити тесты? Возьмем конкретный пример для наглядности. Предположим, у нас есть интернет-магазин, и мы хотим улучшить его конверсию. Но прежде чем просто задизайнить что-то и передать разработчикам, нам нужно понять, где у пользователей возникают проблемы во взаимодействии. Предварительные исследования через интервью или пользовательские тесты помогут более четко охарактеризовать проблему.  Естественно необходимо обращать внимание на то, что делает и говорит пользователь во время теста. Можно конечно просто дать пользователям потыкать в прототип и спросить, “как оно?”, но это не даст вам конкретики. В конечном итоге вы получите много разрозненной и часто субъективной информации.  Именно в этом случае приходят на помощь метрики. Они показывают, где пользователи совершили больше всего ошибок, на какие этапы потратили больше всего времени. Кроме того они дают систематизированную обратную связь через опросы. В конечном итоге у вас будет конкретный план действий. Тестирование поможет выявить такие проблемы, как: 1. Проблемы при выполнении ключевого действия (выбор товара, оформление заказа, оплата) 2. Проблемы с эффективностью (затруднения в процессе поиска товара, длительное оформление заказа) 3. Удовлетворенность от взаимодействия (недостаточное описание товара, неудобство пользования итд) Опираясь на эти данные, можно принять более обоснованные решения. Например, если наши тесты показывают, что пользователи часто допускают ошибки при оформлении заказа и тратят много времени на этот процесс, это может быть показателем, что многие покупатели в реальной жизни просто не дойдут до завершения покупки. Поэтому, перед внедрением новых решений, всегда стоит проводить тестирование на пользователях и проверять, как изменяются прежние показатели (время на решение задачи, количество ошибок, завершенность ключевого действия, показатели удовлетворенности итд). Например, если мы решим внедрить новую функцию ускоренной оплаты или изменить макет страницы оформления заказа, мы можем провести тестирование на группе пользователей и сравнить результаты с предыдущими метриками. Если видим, что после изменений количество ошибок уменьшилось, время оформления заказа сократилось, то это будет явным индикатором того, что нововведения сработали. Особое внимание стоит уделить и презентации отчета о проведенном тесте. Об этом хочу написать отдельной статьей если наберем 20 🔥 под постом.

🚀14 материалов для взлета карьеры дизайнера Артур Кузьмин, Lead Product Designer. ex JetBrains, Avito. Делал проекты для ВТБ, Газпром, Росбанк, Хоум Банк выложил в открытый доступ уникальные материалы из курса про карьеру и скиллы Карьера: 1. Гайд по подготовке портфолио и резюме 2. Лечим резюме после карьерных консультантов. 3. 110 самых популярных вопросов на техническом собеседовании 4. Решение тестовых заданий от 3 компаний из бигтеха 5. 5 рычагов, как дизайнер может влиять на бизнес Дизайн: 6. Типографика: таблица сочетаний размеров текста 7. Киллер-гайд по отступам 8. Дополнение: отступы внутри плашек и рамок 9. Гайд: выравнивания + оптические компенсации 10. Управление вниманием: движение, воздух, напряжение 11. Принцип прямоугольника 12. Построение информационной архитектуры 13. Построение инфоархитектуры по тестовому крупного банка Бонус 14. Путь в продуктовый дизайн с 0 до 300к за 3 года Забирайте в шапке канала: https://t.me/+ZtNT8HrjIkUwOTAy

Как оценивать результаты пользовательских тестов: основные метрики . Ранее я уже рассказывал о проведении пользовательских тестов. Сегодня хочу более детально рассмотреть, какие показатели пользовательского опыта стоит учитывать во время тестирования. 1. Выполнение задачи  Насколько пользователю удалось решить поставленную задачу. Если пользователь справился полностью с поставленной задачей он получает 1 пункт. Если частично -  0.5 пункта. Если полностью провалил задачу - 0 пунктов.  Т.к понять, что считать частично решенной задачей довольно сложно, часто используется бинарный показатель (решенная задача - 1 пункт и не решенная - 0 пунктов) 2. Эффективность Для каждой задачи измеряем время выполнения. Чтобы упростить работу с данными, записываем замеры в секундах. 3. Удовлетворительность Насколько пользователь был удовлетворен взаимодействием с системой выполняя задание. Для оценки обычно используется слудующие градации: удовлетворен; скорее удовлетворен; отношусь нейтрально; скорее неудовлетворен; неудовлетворен; Данные собираются задавая прямой вопрос испытуемому после выполнения пользовательского теста. Таким образом каждое задание можно оценить по 5 бальной шкале. 4. Показатель ошибок Подсчитываем количество ошибок совершенных во время пользовательского теста. Ошибкой можно считать выбор неверных шагов в контексте задания, все что мешает пользователю достигнуть цели. Иногда имеет смысл замерять и субъективное восприятие пользователя: 5. Ощущаемая сложность Метрика помогает оценить, насколько легко или трудно пользователям удается выполнить определенные задачи в интерфейсе. Это может быть выражено числовой метрикой, шкалой от 1 до 5, где 1 означает минимальную трудность, а 5 – максимальную. Также важно проанализировать комментарии пользователей и выявить конкретные проблемы или неудобства, с которыми они столкнулись. 6. Ощущаемое время В дополнение к воспринимаемой трудности также, можно оценить субъективное воспринимаемое время при решении задачи. После прохождения теста спросить ползователя, сколько времени он потратил на решение задачи. Оценка также производится по 5 бальной шкале. Например, если, пользователи считают, что регистрация заняла слишком много времени, хотя по факту справились они довольно быстро, это может указывать, на перегруженность процесса. Данные собираются в таблицу как показано на примере под постом. В следующий раз разберу как анализировать полученные данные. Дайте знать если полезно!

Инструменты UX – Дневниковые исследования (Diary Study) Метод, при котором пользователи фиксируют свой опыт, взаимодействуя с продуктом или услугой, в течение определенного периода времени. При этом участники ведут дневник периодически записывая свои мысли, чувства и поведение связанные с изучаемым продуктом. Зачем проводить дневниковое исследование? Дневниковые исследования позволяют погрузиться в реальные сценарии использования и получить информацию, которую было бы трудно получить в условиях лабораторного исследования, через юзер-тесты или интервью. Таким образом можно более детально учесть контекстные и поведенческие факторы, такие как обстановка, время суток, шаблоны поведения, мотивация и привычки пользователя. Метод особенно полезен при разработке продуктов связанных с привычками пользователя или встроенных в его повседневную жизнь: умные гаджеты, медицина, питание, спорт… Процесс дневниковых исследований 1. Выбор участников Определите вашу целевую аудиторию и выберите участников, которые максимально соответствуют вашим пользователям. Чтобы мотивировать участников, заранее оговорите сумму и условия выплаты компенсации за участие в исследовании. 2. Определение задачи Сформулируйте конкретные задачи или сценарии, которые участники будут выполнять, используя ваш продукт или услугу. Заранее согласуйте как участники будут фиксировать свои мысли, ощущения и взаимодействия в дневниках. Существует несколько методов ведения дневников: Контекстная запись Участники фиксируют всю наиболее важную информацию в контексте применения продукта. В таких случаях участник записывает важные детали в виде текста, аудио или видео. Фрагментированная запись Эта двухэтапная методика обеспечивает фиксацию значимой информации в виде коротких письменных записей. Затем, в конце каждого дня или когда у участников есть время, они дополняют сделанные записи. В данном случае может применяться формуляры с вопросами или анкета. 3. Период наблюдения Установите период, в течение которого участники будут вести записи. Это может быть от нескольких дней до нескольких недель или месяцев, в зависимости от целей и характера продукта. Учитывайте, что дневниковые исследования требуют от участников времени и самоотдачи. Важно понимать, что не все будут одинаково вовлечены в процесс. Важно периодически взаимодействовать с участниками на протяжении всего исследования. 4. Анализ данных Анализ данных, полученных из дневников, представляет собой уникальную возможность погрузиться в мир пользователя. Важно учитывать не только сами записи, но и понять в каком контексте и как часто пользователь соприкасается с продуктом. Хотя проведение дневниковых исследований может занять больше времени и усилий, чем другие методы изучения пользователей, они предоставляют ценную информацию о поведении и опыте клиентов в реальном времени и естественной среде. Записи в дневниках часто раскрывают более глубокие и личные аспекты опыта пользователя, которые могут быть упущены в более формальных исследованиях. Как вам инструмент? Дайте знать в реакциях: ❤️ – буду применять 🤓 – уже использую 😐 – слишком сложно/не интересно

С праздником весны, дорогие дамы! Пусть каждый ваш день будет наполнен светом и вдохновением 🌼 Как раз по теме сегодняшнего дня команда Duo Sapiens выпустила большое исследование "28.3%" на тему гендерного неравенства в дизайн-среде. Статистически получается, что женщины активно учатся дизайну и всему, что с ним связано, у них достаточно таланта, но на высоких должностях они преуспевают реже, чем мужчины. Исследование пытается прояснить, как проявляется гендерное неравенство в сфере дизайна и где конкретно «ломается» карьера женщин. Ссылка на статью

Топ инструментов исследования с которыми я работаю Существует множество инструментов исследования, и новичку может быть непросто выбрать подходящий для конкретной задачи. Сегодня я хочу поделиться основными инструментами, которые использую в исследованиях, заодно расскажу про свой процесс. Хочу сразу отметить, что за последние годы моя работа в основном была связана с продуктами для экспертов (софт для производственных линий и AgriTech). Это либо создание нового продукта с нуля, либо адаптация существующего под новые требования. Независимо от своей специфики, каждое исследование, имеет две основные цели - понимание пользователей и бизнеса. Кто и с какой целью будет использовать продукт, и какая от этого выгода для бизнеса. Для лучшего понимания пользователя, наиболее простой и удобный метод - создание собирательного образа через персоны. Можно создать несколько персон, но важно сосредоточиться на основном пользователе, том, кто будет главным героем карты пути пользователя (CJM). При этом пользователю дается имя, у него есть хобби и прочие характеристики. По моему опыту, это важный шаг в проектировании помогающий команде синхронизироваться в понимании для кого в конечном итоге делается продукт.  Часто возникает вопрос - где брать данные для исследования? Большую часть инсайтов в начале проекта я получаю через интервью. Если опросить хотя бы 5 пользователей уже можно получить более четкое представление об их потребностях и предпочтениях. Если необходимо собрать информацию релевантную для бизнеса или любые количественные данные, то очень помогают опросы. Но из-за специфики продуктов бывает сложно и слишком затратно найти подходящую целевую аудиторию. Поэтому часто я использую результаты опросов из открытых источников. Поняв, кто пользователи и какую проблему они решают, анализируем, как они взаимодействуют с продуктом через карту пути пользователя. Выявляем слабые места и проблемы в текущем решении. Это можно делать на начальной стадии в FigJam или Miro совместно с продуктовой командой. Если продукт уже есть, то важно разобраться как он работает.  В сложных продуктах лично мне помогает визуальное структурирование информации с помощью ментальных карт. Когда созрело решение я составляю обновленную карту пути пользователя. На ее основе разрабатываются сценарии для конкретных задач, из которых затем создаются вайрфреймы. После этого можно сразу приступать к тестированию решения на пользователях. Для проверки решения я, предпочитаю модерируемое юзабилити-тестирование на click-dummy или прототипе. Огромный плюс, этого метода в том, что можно в живую наблюдать за действиями и реакциями респондентов и в дополнение к тестированию провести интервью. Ну а дальше весь процесс идет по следующему кругу итерации пока не будет доведен до уровня финальной готовности ) На этом все! А какие инструменты исследования используете вы?