В последнее время всё чаще и чаще возникает вопрос о доступности, если раньше скрытиеoutlineдля элементов страницы было общим правилом, то теперь хороший сайт должен иметь outline у элементов, как минимум:focus-visible.Основная проблемаoutline- это их стилизирование.

Я пришел к своему решению, которое изложено в этой статье.

Большой gif

Работая над своим pet проектом мне нужно было сделать один и тот же стиль обводки (при наведении и фокусе) для элементов визуализаций и всех фокусируемых элементов DOM.

Моё решение

Вставляемdivповерх всего остального контента вdocument.body, и отключаем ему обработку событий черезpointer-events: none, растягиваем в размер документа,z-indexдолжен быть больше всех остальных на странице.

Добавляем еще 4-edivс абсолютными позициями в ранее добавленный родительский:

их стили (scss):

Добавляем подписку на события дляdocument:pointerenter,pointerleave,focus,blur:

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

В функциях слушателей фильтруем все события поtabIndex > -1уevent.target. При этом также проверяем что у ссылок естьhref, и кроме того что у элементов нет атрибутаdisabled. Когда происходитblurможет оказаться, что элемент оказался в контейнере, который тоже может иметь фокус (тут конечно можно задаться вопросом семантики, но такое бывает почему вbuttonнаходитсяa):

В методеshowполучаем размерыtargetс помощьюgetBoundingClientRect. А затем перемещаем, наши 4-ediv, каждый в свой угол:

Собственно, всё!

Описанный выше код вы можете найти здесь.

Заключение

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

Кроме того,overflow: hiddenне влияет на нашoutline, но иногда нам нужно следить за формой элемента и размерами (к примеру ResizeObserver) , поэтому вы можете улучшить этот подход, все в ваших руках.

Спасибо за прочтение!

Если вам нужна дополнительная информация, дайте мне знать об этом DMartzub.online.

P.S.: английская версия моей статьи здесь

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

Возможности человеческой памяти ограничены

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

У человека два вида памяти.

Первый рабочая память: кратковременное хранилище небольшого количества информации.

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

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

Рабочая память малоемкая и неустойчивая. Специалист по когнитивной психологии Джордж Миллер в 1956г. в книге о волшебном числе 7 предположил, что средний человек может удерживать в краткосрочной памяти около 7объектов (плюс-минус 2).

Если дизайн разработан таким образом, что пользователю в рабочей памяти требуется в течение более чем 7секунд держать более 3объектов или 1объект в течение более чем 70секунд, то будут появляться ошибки: информация в рабочей памяти очень легко теряется.

Если объекты в рабочей памяти не группируются и не повторяются, они исчезнут из фокуса внимания. Исчезновение объектов из рабочей памяти это забывание: например, вы пошли за чем-то в другую комнату, но, оказавшись на месте, не можете вспомнить, зачем туда шли.

У долговременной памяти множество слабых мест и она ненадежна. Память этого вида во многом отличается от рабочей. Объекты в долговременной памяти хранятся в мозгу, распределенные по многим его участкам. Хранящаяся в долговременной памяти информация не исчезает, но постепенно затухает, теряя силу. (Джонсон, 2014; подробнее в книге.)

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

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

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

Факторы, влияющие на работу памяти

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

Перечислю некоторые факторы, которые влияют на рабочую память:

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

• Сходство и путаница. Если объекты похожи, их можно легко объединить в одну порцию.

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

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

• Прерывание. Прерывание мешает вносить информацию в рабочую память особенно когда внимание нарушается во время работы с информацией.

Факторы, влияющие на получение информации из долговременной памяти:

• Сила объектов в долговременной памяти. Сила определяется востребованностью и актуальностью информации. Востребованность это то, как часто информация используется или извлекается из долговременной памяти. Актуальность определяется тем, как давно вы извлекали эту информацию из долговременной памяти последний раз.

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

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

Подходы в дизайне интерфейса, облегчающие работу памяти

Мы уже выяснили, что рабочая память хранит мало и недолго, а у долговременной памяти много слабых мест и на первых этапах запоминания она ненадежна. Дизайнер должен помочь пользователю запомнить важную информацию до момента, когда она понадобится. Нельзя требовать запоминать состояние системы или выполненное действие. Вот некоторые подходы, которые помогут снизить нагрузку на рабочую память пользователей (Lee, Wickens, Liu, Boyle, 2017; подробнее в книге):

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

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

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

• Буквы вместо цифр. Обычно буквы человеку запомнить проще, чем цифры. Поэтому, например, рабочий номер телефона лучше записывать не как 467-968-2378, а как 467-YOU-BEST.

• Снижение путаницы в рабочей памяти. Чтобы снизить путаницу, можно обеспечить пространственное разделение. Например, при проектировании интерфейса его можно разбить на части таким образом мы даем мозгу зацепку для различения сигналов и снижения путаницы между объектами.

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

Чтобы дизайн помогал работе долговременной памяти, нужно в первую очередь избегать разработки систем, которые повышают нагрузку на память этого вида. Для этого можно применять следующие подходы (Lee, Wickens, Liu, Boyle, 2017; подробнее в книге) как вы увидите, именно так работают многие интерактивные системы.

• Поощряйте пользователей использовать информацию регулярно. Частое воспоминание повышает силу информации в долговременной памяти.

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

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

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

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

• Единообразная работа в рамках системы и с другими приложениями. Чем единообразнее работа разных функций и действия с объектами разных типов, тем меньше пользователю нужно запоминать. В интерфейсе со множеством исключений и низким уровнем единообразия между функциями и объектами различных типов пользователю приходится хранить в долговременной памяти особенности каждой функции и каждого типа объектов, а также правильный контекст использования. Необходимость запоминания большого количества информации затрудняет изучение таких интерфейсов. (Джонсон, 2014; подробнее в книге.)

Дизайн должен соответствовать знакомой пользователю ментальной и концептуальной модели. Простой пример: круглые переключатели позволяют выбрать один вариант, флажки в квадрате несколько. Источник https://www.justinmind.com/blog/mental-models/

Литература:

John D Lee, Christopher D. Wickens, Yili Liu, Linda Ng Boyle (2017). Designing for People: An Introduction to Human Factors Engineering 3rd Edition.

Джефф Джонсон (2014). Умный дизайн. Простые приемы разработки пользовательских интерфейсов.

О переводчике

Перевод статьи выполнен в Alconost.

Alconost занимаетсялокализацией игрприложений и сайтовна 70 языков. Переводчики-носители языка, лингвистическое тестирование, облачная платформа с API, непрерывная локализация, менеджеры проектов 24/7, любые форматы строковых ресурсов.

Мы также делаемрекламные и обучающие видеоролики для сайтов, продающие, имиджевые, рекламные, обучающие, тизеры, эксплейнеры, трейлеры для Google Play и App Store.

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

Всем привет! Меня зовут Игорь, я ведущий Продуктовый дизайнер в ВТБ.

Что это за сообщество такое, для чего оно, и кому будет полезно! Начну с самого начала, отправил заявку на официальном сайте Figma, предоставил все материалы которые были необходимы для рассмотрения моей заявки вступить в сообщество и быть организатором(представителем) Figma сообщества в России. Буквально 2-3 недели и мою заявку рассмотрели, прислав письмо с поздравлениями.

Сразу после вступления в сообщество, необходимо было сделать под требования Фигмы логотип сообщества Friends of Figma Moscow и всевозможное оформление социальных сетей, подготовка графических баннеров по гайдам Figma.

Кому будет полезно:

Молодым специалистам которые только начинают свою карьеру в дизайне;

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

Разработчикам которым интересно разрабатывать плагины для Фигмы;

Владельцам продукта - которые хотят понимать дизайнеров в проекции интерфейсов и дизайна;

Всем желающим!!!

Цели сообщества

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

Что на данный момент уже сделано

готов список спикеров на первые мероприятия

составлена программа и темы на первые мероприятия

техническая часть проработана на треть

идут переговоры по форматам мероприятий

Когда? Где? Во сколько?

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

Социальные сети:

facebook.com/fofmoscow

t.me/fof_moscow

instagram.com/fofmoscow

Есть желание делиться опытом?

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

Всем спасибо кто уже вступил в сообщество, и тем кто вступит в будущем!!!!!

Надеюсь администрация не удалит этот пост))))

Меня зовут Илона, я Senior Experience Designer в EPAM. Работа для меня удачно совпадает с хоббив EPAM я проектирую интерфейсы для зарубежных заказчиков, читаю лекции для сотрудников и студентов лабы, менторю дизайнеров. В свободное время преподаю проектирование интерфейсов в магистратуре Университета ИТМО и ведуТелеграм-канал о UX-дизайне.

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

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

Проект и дизайн-команда

Проект, на котором мы работаем крупная e-commerce платформа с большой командой (80+ разработчиков, менеджеров, аналитиков, тестировщиков) и быстро меняющимися требованиями. На таком крупном проекте логично образовалась дизайн-команда из 4 ролей:

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

• UI-дизайнер (в EPAM эта роль также именуется Visual-дизайнер), который отвечает за то, чтобы интерфейс был красивым, эстетичным, хорошо смотрелся на разных разрешениях, соответствовал концепции бренда и возможностям разработки.

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

• Team Lead, который налаживает процессы и решает оргвопросы, обеспечивает команде комфортные условия работы и также занимается UX-дизайном.

Процессы в проекте построены вокруг Scrum: планирование спринта с оценкой задач, двухнедельный спринт, ревью и ретроспектива. Задачи команда оценивала в часах: сколько по времени успеваем столько и берём в следующий спринт. Звучит просто, но оценка в часах вызывала большие трудности у дизайн-команды.

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

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

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

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

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

Вот некоторые цитаты из ретроспектив, которые мы проводили внутри дизайн-команды:

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

Относительная оценка сложности

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

Согласно Scrum, для оценки задач используется абстрактная единица Story point. В одной команде ею могут измеряться часы, в другой дни, в третьей что-то ещё. Кому как удобно.

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

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

В нашем случае оценка сложности в Story points оказалась гораздо эффективнее, чем оценка часов, потому что:

• Оценка сложности помогает сконцентрироваться на создании ценности, а не погоне за временем. Мы перестали пытаться успеть хоть что-то в заявленные сроки.

• Проще включить обсуждения, подтверждения и брейнштормы в итоговую оценку.

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

• Исключаются обсуждения в формате Я бы сделал эту работу быстрее.

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

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

Параметры сложности

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

1. Зависимости от других людей

2. Навыки дизайнера

3. Количество коммуникации в рамках задачи

4. Согласованность нового дизайн-решения с уже существующими

_{*хотя параметры описывают работу дизайнера, я думаю, они будут актуальны и для других специалистов.}

Для каждого параметра я подобрала шкалы от 1 до 4. Например, оценка параметра Зависимость (Dependency) выглядит так:

1 (нет сложности) никто кроме дизайнера не вовлечён в работу, нет зависимости от других людей;

2 (низкая сложность) 1 человек вовлечён и немного работы с стороны;

3 (средняя сложность) 2-3 человека и/или много работы со стороны;

4 (высокая сложность) более 3 человек и/или невозможно определить количество работы со стороны.

Подробные шкалы по всем четырём параметрам сложности можно найти в моём докладе для конференции Design Z Day:

Как понять, что сложно, а что нет

Всё познается в сравнении.

Если время можно определить конкретно (например, два часа), то с оценкой сложности возникают проблемы. Что значит сложно? Где грань между сложно и очень сложно?

Секрет относительная оценка. Задачи оцениваются не в вакууме, а относительно друг друга, в сравнении.

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

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

Процесс сравнения всегда основан на опыте конкретной команды. Поэтому оценки каждой команды уникальны.

Как наша команда начала использовать относительную оценку сложности

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

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

Из прошлого спринта, который мы оценивали в часах, взяли 3 задачи. Мы их уже выполнили, поэтому всё про них знали. Для каждой задачи мы последовательно прошлись по 4 параметрам сложности (зависимости, навыки, коммуникация, согласованность) и дали новые оценки в относительных Story Points. Это было непросто, мы долго обсуждали каждую оценку и приходили к единой цифре. Вот что у нас получилось:

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

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

Результаты перехода на относительную оценку сложности

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

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

Важные результаты для нашей дизайн-команды:

• прозрачность задач;

• более точные оценки с меньшими усилиями;

• команда дизайнеров понимает, что мы должны знать перед выполнением задачи;

• лучшая декомпозиция задач;

• учитывается вся работа, включая согласования, генерацию идей и обсуждения;

• мы постоянно сравниваем задачи и видим общую картину.

Как итог, меньше стрессов, переутомления и неприятных сюрпризов.

Больше о проектировании интерфейсов и UX можно почитать в моём телеграм-канале Поясни за UX.

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

На периферии

В конце марта один из резидентов Hacker News высказал мнение о том, что проектировщики интерфейсов цифровых продуктов Эппл не уделяют должного внимания визуальной составляющей музыкальных альбомов и других типов аудиоконтента. Он привел в качестве иллюстрации своих доводов внешний вид экранов музыкального приложения компании на iPod Touch 2012 года и iPhone SE 2016-го. Последний предлагает слушателям уменьшенный вариант обложки не растягивает ее на весь экран, как на iPod Touch. Поэтому рассмотреть детали иллюстрации становится сложнее, а на паузе изображение становится еще меньше.

Разница размеров обложки на локскрине устройств намного заметнее на Touch она занимает чуть ли не всю ширину экрана, а на iPhone лишь небольшую его часть в виде пиктограммы внутри виджета с управляющими элементами плеера музыкального приложения. При этом прочитать полное имя исполнителя и запущенного трека сразу невозможно места рядом с уменьшенной обложкой не хватает и для них. Автор заметки задает эти вопросы аудитории и вспоминает так называемый Cover Flow, который в Эппл представили вместе с очередной версией iTunes в 2006 году, а на iPhone и iPod nano выпустили в 2007-м. Кстати, тогда обложки тоже растягивали практически на всю ширину экрана устройств, а при просмотре в режиме Cover Flow они становись еще и интерактивными по тапу открывали список треков альбома.

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

Дошло до того, что в ряде случаев на кавере не было ничего кроме текста с названием альбома и однотонного фона. Об этой проблеме тогда высказывался арт-директор Warner Brothers Records, представители других крупных лейблов, ряд известных музыкантов и дизайнеров. Однако, как мы видим по примеру, от которого мы оттолкнулись в начале материала, на стороне музыкальных платформ эти вопросы и предостережения просто-напросто проигнорировали. Да и качество обложек к тому моменту уже не позволяло в один миг вернуть к ним прежнее внимание.

Попытка все исправить

В конце прошлого года Эппл представили новую возможность для авторов, исполнителей и подписчиков своего музыкального сервиса анимированные обложки для отдельных композиций и альбомов. Ранее команда Эппл мьюзик экспериментировала с подобными решениями для плейлистов, но с очередным обновлением iOS распространила эту практику и на полноценные релизы. Пока гифки заметили на одиннадцатом студийнике Pearl Jam под названием Gigaton, и пластинке Detroit 2 рэп-исполнителя Big Sean. Изучить их могут обладатели устройств с iOS и iPadOS 14.3 и выше, плюс macOS Big Sur, начиная с версии 11.1.

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

Дополнительное чтение в нашем Мире Hi-Fi:

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

• Стриминговые сервисы хотели бы найти новые подходы в работе с музыкой

• Плейлистификация захватила умы паблишеров музыки и подкастов

• Стриминг становится основным источником дохода музыкантов

• Индустрия подкастов все больше походит на стриминг сериалов и фильмов

Что еще у нас есть в блоге на Хабре:

• Напольники до 60 тысяч три пары акустики от Klipsch, ELAC и Monitor Audio

• Комплект с устройствами для звукозаписи обсуждаем возможности и альтернативы

• Два продвинутых пэка устройств для любительской звукозаписи как они выглядят

Усталость от принятия решений это популярный термин, описывающий случаи, когда человек за определенное время принимает слишком много решений. Исследования показывают, что причина этого явления в исчерпании когнитивных ресурсов именно поэтому после 30минут поисков на Нетфликсе чего-то нового вы в итоге смотрите давно знакомый Офис: ваша способность принимать решения снизилась, и мозг сдался (хотя это и неплохое шоу).

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

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

В этой статье рассматриваются шесть способов снизить когнитивную нагрузку в UX-проекте.

1. Чем реже нужно делать выбор, тем лучше

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

Если у пользователя слишком много вариантов выбора, он легко сбивается с толку и раздражается. У продукта могут быть все необходимые функции, но если интерфейс чересчур запутан из-за чрезмерного количества возможностей, он становится неудобным. В опубликованном в журнале Journal of Personality and Social Psychology исследовании говорится, что такая ситуация часто вызывает паралич принятия решений и раздражение. [1]

В погоне за повышением числа начальных (или повторных) продаж компании могут включать в свои продукты слишком много (или слишком мало) функций. Используя модель, предложенную в Harvard Business Review, можно найти золотую середину в зависимости от желаемого результата.

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

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

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

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

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

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

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

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

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

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

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

Ответ прост: нужно дать возможность легко вернуться туда, откуда пользователь начал.

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

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

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

При разработке пути пользователей я использую следующие рекомендации:

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

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

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

• Не показывайте сообщение на всю страницу укажите, в каких полях ошибка.

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

3. Визуальные подсказки для навигации

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

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

Правильно подобранное количество визуальных подсказок:

• Упрощает обзор и чтение страницы.

• Улучшает визуальную иерархию.

• Улучшает навигацию по странице.

• Существенно повышает коэффициент конверсии.

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

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

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

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

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

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

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

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

Согласованная цветовая схема.

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

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

Повторение в шаблонах проектирования и условностях.

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

• вашим продуктом станет удобно пользоваться, потому что в нем не будет ничего нового (это снижает когнитивную нагрузку);

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

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

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

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

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

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

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

5. Делайте интерфейс для пользователей, а не для себя или своей компании

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

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

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

При этом можно задавать такие вопросы:

• Что больше всего понравилось в нашем последнем продукте?

• Как бы вы отнеслись к изменению функции X?

Некоторые полученные в результате такого опроса идеи могут вас удивить и даже изменить направление развития прототипа.

Есть несколько методов исследования UX, которые помогут держать пользователей в центре внимания:

• Надлежащее исследование рынка.

• Использование персонажей пользовательских ролей.

• Макеты и прототипы для получения быстрой обратной связи.

• Регулярное общение с собственной службой поддержки.

И этот список, конечно, далеко не полный

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

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

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

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

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

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

Заключение

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

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

Помогли ли вам приведенные в статье советы? Расскажите в комментариях ниже или напишите мне на почту alexander@radahl.no.

О переводчике

Перевод статьи выполнен в Alconost.

Alconost занимается локализацией игр, приложений и сайтов на 70 языков. Переводчики-носители языка, лингвистическое тестирование, облачная платформа с API, непрерывная локализация, менеджеры проектов 24/7, любые форматы строковых ресурсов.

Мы также делаем рекламные и обучающие видеоролики для сайтов, продающие, имиджевые, рекламные, обучающие, тизеры, эксплейнеры, трейлеры для Google Play и App Store.

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

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

Дисклеймер о Госуслугах

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

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

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

Дисклеймер об авторе

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

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

Сейчас

Если кто-то не заходит в Госуслуги каждый день, то напоминаю, как они выглядят сейчас:

Исправляем главный экран

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

Четыре кнопки оплаты

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

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

• сделаем так, чтобы кнопки стало видно сразу

• не будет вводить заблуждение пользователя - заменим иконку штрих-кода на QR-код, ведь именно его надо искать на квитанции

• статус "Не найдено" - это ошибка, сервер не смог найти информацию, или у меня нет долгов? Заменим на "Отсутствуют"

• если в какой-то категории у нас есть задолженность, то сразу отобразим количество штрафов и их общую сумму

Уведомления

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

Сделаем колокольчик, отображающих непрочитанные уведомления.

Услуги

Основная часть и смысл приложения - услуги (запись на посещения, получение справок, запрос информации и т.д).

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

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

Также уберем выбор региона на этом этапе. От выбора местоположения зависит функционирование только некоторых услуг - паспорт гражданина РФ он и во Владивостоке паспорт.

FAQ

На скидку в факе 13 разделов в среднем по 10 вопрос-ответ в каждом. И этот раздел действительно старались сделать удобным, когда он начал разрастаться - добавили ссылки, заголовки, свернули ответы.

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

Решение - заменяем все вопросы на умный поиск с подсказками. Умный - потому что неплохо было бы хранить синонимы и искать не только по точному совпадению. Это же не поисковик по всему интернету, на 130 вопросов можно такую систему.

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

Новости

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

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

Исправляем список услуг

А тут все коротко. На сайте так много услуг, что единственный способ предоставит к ним удобный доступ с мобильного устройства - действительно умный поиск.

Предлагаю выводить группы услуг, а в описание перечислять подгруппы. Сейчас почти так и есть, только не понимаю отрицания существования списков.

Итого

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

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

На правах....

dendolg.ru - сайт-портфолио-визитка, контакты для сотрудничества

t.me/dolgopolovd - личный блог, в котором подмечаю хороший и высказываю идеи по поводу плохого промышленного и цифрового дизайна. а иногда размышляю о программировании и прочей философии

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

Интродакшн

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

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

Проблема, которую мы решали

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

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

Небольшое отступление про компанию и команду

Kolesa Group продуктовая IT-компания, основанная в Казахстане. Мы создаем и развиваем классифайды сервисы для публикации объявлений для людей и компаний в Казахстане и Узбекистане.

У нас 4 основных продукта:

• Kolesa.kz классифайд в категории Авто с MAU в 5 млн пользователей. Это 32 % всех интернет-пользователей в стране.

• Krisha.kz классифайд в категории Недвижимость с MAU 3.5 млн пользователей. Это 23 % всех казахстанских интернет-пользователей.

• Market.kz классифайд для всех категорий товаров и услуг. Ежемесячная аудитория более 2 млн человек.

• Avtoelon.uz автоклассифайд в Узбекистане. MAU 2 млн пользователей.

Процесс

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

Шаг 1. Рисерч и поиск референсов

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

Вот подборка ресурсов, где собраны референсы от других команд:

• https://principles.design/

• https://www.designprinciplesftw.com

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

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

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

В опроснике были вот такие открытые вопросы:

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

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

3. Приведите примеры продуктов и процессов разработки в командах, которые вас вдохновляют, и опишите, чем именно они вас вдохновляют.

Кроме внутреннего опроса, мы собрали распространенные проблемы в продуктах из базы службы заботы о пользователях (звонки, письма, отзывы в app-маркетах). Это помогло сегментировать проблемы, например, технического или интерфейсного характера.

Шаг 3. Подготовка к шторму

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

На доске подготовили такие штуки:

• Вытащили примеры принципов некоторых дизайн-команд, которые покрывали наши проблемы.

• Вытащили результаты опросов.

• Подготовили площадку для боя. В этой области будет проходить брейншторм. У нас это проходило в Miro.

Шаг 4. Собственно брейншторм

Сам брейншторм был строго ограничен по времени и разделен на этапы. Прежде всего мы обсудили 3 главных вопроса:

• Почему мы создаем принципы?

• Для кого мы их создаем?

• Как те, для кого они будут сделаны, смогут их использовать?

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

1. Сначала каждый участник писал на стикерах ПЛОХИЕ реализации и характеристики интерфейса или пользовательских качеств в продуктах. Ставили таймер на 10 минут.

2. Затем рядом с каждой плохой реализацией каждый участник должен написать решение проблемы, чтобы ПЛОХОЕ стало ХОРОШИМ 20 минут.

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

4. В итоге у нас вышло несколько категорий, которые мы тоже объединили в сегменты:

A) человекоориентированность, прозрачность и честность в продуктах;

B) осознанность в проектировании, консистентность, качество продукта, эстетичность;

C) контроль состояния, понятная коммуникация, простота и очевидность;

D) командность.

5. Затем каждый участник отдал голос наиболее важным, на его взгляд, категориям 3 минуты.

6. После мы разложили варианты, набравшие наибольшее количество голосов, по пирамиде дизайн-принципов.

Что осталось?

1. Осталось придумать названия для принципов и их описания. Нам важно, чтобы названия были запоминающимися и их описания развернуто объясняли суть.

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

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

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

Вот что у нас получилось:

[Сначала люди]

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

[Сознательный подход]

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

[Очевидность]

Наши интерфейсы и внешние коммуникации едины, понятно объясняют, на каком шаге находится человек сейчас, и помогают, если что-то пойдёт не так.

[Коллаборация]

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

[Инновации]

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

Корабль поплыл

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

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

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

Заметить эффективный рост качества продукта только от внедрения таких принципов сразу невозможно, пока мы только следим за показателями NPS и внешним feedback loop (звонки, письма, отзывы в app-маркетах).

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

Читайте в статье: что такое диалоговый UX/UI и какего создавать, а также полезные лайфхаки при проектировании сценария длячат-бота.

В марте 2021 годааналитики Voicebot провели опрос300 маркетологов и узнали, что они думают про голосовых помощников. Оказалось, что более 60% специалистов уверены в пользе голосовых ассистентов длямаркетинга. Виртуальные помощники и чат-боты больше не новинка и не пустой повод дляхайпав новостях. Бизнесактивно использует разговорные технологии дляэффективной коммуникации спользователями, дляпрямых продаж и создания прочных связей сбудущими и настоящими клиентами. И мы в Just AI уверены, что в будущем эта тенденция будет толькорасти.

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

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

Для новичков. Что такое диалоговый UX и в чем его отличие отдиалогового UI?

Начнем спростого: UX это user experience или опыт, который получает пользователь в ходе его взаимодействия синтерфейсом сервиса, продукта или услуги. UI это user interface, пользовательский интерфейсили то, что мы привыкли называть дизайном.

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

А диалоговый UI это интерфейсы, которые позволяют взаимодействовать между пользователем и системой. Элементом диалога может стать голосовой или текстовый ввод и вывод информации, а также модальное окно на сайте, поп-ап в приложении и т. п.

В рамках диалогового UI мы рассматриваем два условных типа интерфейсов: голосовой и разговорный. Кажется, что это синонимы, но не все такпросто. Под разговорным интерфейсом или Conversational User Interface (CUI) подразумеваются все интерфейсы, скоторыми можно общаться на естественном языке кактекстом, таки голосом.

Соответственно, в понятие CUI входит Voice User Interface (VUI) или голосовой интерфейс. Он предполагает взаимодействие сустройством спомощью голоса.

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

Закрепим. Итак, Алиса в Яндекс.Станции это VUI, а в смартфоне, где сней можно говорить голосом и чатиться CUI. А все вместе это диалоговый UI.

Кто создает диалоговый UX и UI при проектировании чат-ботов

Созданием диалогового UХ и UI занимается отдельный специалист. Он разрабатывает диалоговый пользовательский интерфейс, продумывая пользовательский опыт.В Just AI мы называем такого специалиста дизайнер разговорных интерфейсов.

Но в русском языке точный термин до сих пор не закрепился. Поэтому можно встретить разные переводы. Так, на HH.ru мы встретили 17 разных названий вакансий: дизайнер диалогов, диалоговый редактор, digital-лингвист, voice UX designer, диалог-дизайнер, сценарист чат-бота и такдалее. Подробности о нашем исследовании смотрите в вебинаре Создатели разговорных интерфейсов: кто они и чем занимаются?. На нем мы рассказали, каксделать так, чтобы специалисты и компании нашли друг друга.

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

Для продвинутых. Какразработать диалоговый UX/UI

Шаг 1. Узнайте, подходит ли разговорный интерфейсдляваших задач.

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

Чек-лист диалогового UX/UI

• Ваш вопросможно решить только при участии человека.

• В качестве формата диалога подойдет вопрос-ответ без дополнительных уточнений.

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

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

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

• Задачу можно выполнить, одновременно делая другие дела.

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

• Пользователю комфортно говорить или писать о теме задачи.

Обратите внимание, что голосовой интерфейсможет не подойти в следующих ситуациях и пространствах:

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

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

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

• В случаях, когда речь идет о чем-то личном. Если в переписке счат-ботом необходимо сообщить персональные данные или личные сведения, то голосовой интерфейсдлятакого не подойдет.

Шаг 2. Узнайте все о пользователе

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

Чтобы составить пользовательскую персону, дляначала ответьте длясебя на вопросы:

• Кто ваши пользователи?

• Что хотят сделать? Какую проблему хотят решить?

• Какони делают это сейчас?

• Какие слова или фразы они используют, говоря о задаче?

• Каков контекст, обстоятельства этих задач или проблем пользователей?

Продумайте tone of voice то, какую речь будет использовать ботили ассистент при общении спользователем. Если это чат-бот, какон обращается кклиенту на ты или на вы? Использует ли он профессиональные термины? Умеет ли общаться на отвлеченные темы и шутить,какботКвик?

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

Чтобы найти tone of voice, поизучайте ресурсы, на которых сидят пользователи это могут быть Известия, Ревдинский рабочий, Одноклассники, ВКонтакте и такдалее.

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

Ирина Степанова, аналитикразговорных интерфейсов отдела лингвистики в компании Just AI

Сравните сами, какможет отличаться Tone of Voice в сообщениях отразных компаний:

1. Привет, Иван! Посмотри новые тарифы на сайте в разделе Цены! Мы подготовили длятебя классные предложения!

2. Здравствуйте, Иван Иванович. Просим обратить внимание, что с1.06.2021 обновляются Тарифы. Актуальная информация находится в соответствующем разделе.

При создании диалогов обязательно используйтемаксимы Грайса. Это правила ведения разговора, которые подчиняются принципу кооперации, введенному философом Гербертом Полом Грайсом. Они актуальны и дляголосового ассистента сискусственным интеллектом, и дляпростого бота в Facebook Messenger.

Четыре максимы помогают сделать диалог бота спользователем наиболее человечным и эффективным.

Максима качества информации:

• не говори того, что считаешь ложным;

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

Максима количества информации:

• изложи не меньше информации, чем требуется;

• изложи не больше информации, чем требуется.

Максима релевантности:

• не отходи оттемы.

Максима ясности:

• будь последовательным:

• избегай неясности;

• избегай двусмысленности;

• будь краток;

• будь систематичен.

В кратком изложении они описаны на картинке.

Шаг 3. Спроектируйте диалог

Создание сценария чат-бота стоит начать со схемы диалога в голосовом или текстовом каналах (Voice Flow или Chat Flow). Это диаграмма, которая показывает пути, через которые может идти диалог.

Для начала пропишите happy path или счастливый путь идеальный диалог пользователя сботом отначала и до конца. А затем продумайте ответвления, которые могут возникнуть на этом пути: сложности, дополнительные вопросы, уточнения.

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

Шаг 4. Пропишите текстовый сценарий

Чтобы выполнить этотшаг, берите за основу путь пользователя и выбранный tone of voice. Готовые кусочки диалогов потом пойдут в код и превратятся в реальные реплики бота или ассистента.

Шаг 5. Сборка прототипа диалога

Итак, вы узнали самое важное про диалоговый UX и UI, изучили задачу и аудиторию, а также подготовили сценарий. После этого нужно заняться UX-проектированием диалога и собрать его прототип. Это поможет узнать, кактекст будет восприниматься в мессенджере, проверить навигацию и протестировать гипотезы. Такой работой обычной занимается дизайнер-проектировщик UX-дизайнер, специализирующийся на разговорных интерфейсах.

UX-дизайнер не просто рисует красивые кнопки. Он проектирует эмоциональный и чувственный опыт. Неважно приятный, неприятный, напряженный Эти оттенки зависят отпоставленной задачи, а UX-дизайнер спроектирует то, что необходимо.

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

Екатерина Юлина, Head of Product UX, Just AI

Чтобы узнать, какими будут дальнейшие шаги и увидеть практикум сборки прототипа диалога, посмотрите наш вебинар Дизайн голосовых интерфейсов: как, что, где и главное, зачем?. Специалисты Just AI рассказали и показали, каксоздают UX и UI при проектировании чат-бота HR дляпроизводственной компании, а также поделились практическими советами.

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

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

Файл с примерами:тут

Мануал:тут

Поле с Auto Layout теперь выглядит так:

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

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

Новые настройки по ресайзам компонентов:

Уже завтра (20 ноября) Фигма проводит разбор Фичи и использование нового Auto Layout Регистрация на мероприятие от Фигмы тут

Компульсивные траты это покупки "на эмоциях", которые в определенных случаях могут привести к серьезным финансовым трудностям.Опросболее 5000 человек с ментальными расстройствами показал, что 93% из них тратят больше в периоды обострения болезни. Например, люди с биполярным расстройством склонны тратить значительно больше во время маниакальной фазы, в результате чего у них накапливается огромный долг.Как банковские приложения могут помочь уязвимым клиентам избежать таких ситуаций.

Исследование

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

Добавление positive friction

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

Сначала пользователь включает функцию в настройках и устанавливает лимит.

Затем выбирает магазины, в которых он склонен слишком много тратить. Я выбрала магазины, а не категории, потому что на платформах e-comm, таких как Amazon или eBay, банки не могут определить, к какой категории относится покупка.

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

Выводы

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

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

Синопсис

Абзац для тех, кто хочет без "лишней воды" получить реальный отзыв студента Яндекс.Практикума. Курс "Дизайнер интерфейсов". Длительность семь месяцев. До оплаты есть возможность пройти часть учебника. Оплатить можно частями или сразу. Язык изложения материала доступный для любого возраста. Даже если Вам пятьдесят Вы сможете осилить курс. И это факт, так как со мной учатся взрослые люди. В учебнике есть задания, которые необходимо выполнять, чтобы закреплять материал и понимать следующие темы. Обучение проходит спринтами. У Вас есть время для чтения учебника и выполнения заданий. Задания бывают двух типов. Мини-проекты и обычные задания. В учебнике нет возможности читать хаотично. Материал подаётся в строгой последовательности. Некоторые задания необходимо выполнять чтобы перейти к следующему параграфу. Задания со звездочкой необязательны к выполнению, но желательны. В конце каждого спринта нужно выполнить финальный проект, который имеет два дедлайна. Мягкий и жесткий дедлайн. Если Вы сдаете проект до мягкого дедлайна и получаете обратную связь от ревьювера с замечаниями к проекту, у Вас есть две итерации на исправление замечаний. Так Ваш проект становится лучше и Вы больше понимаете и усваиваете. Если Вы не успели сдать проект до мягкого дедлайна, у Вас есть жесткий дедлайн. В этом случае отправляя работу на ревью, вы имеете одну попытку на исправление. Кто не справляется с дедлайнами, оправляется в академический отпуск. Такие студенты среди нас были. Причины разные загруженность человека, семейные проблемы, здоровье и прочие. Когда Вы знаете, что кто-то не смог продолжить обучение и ушел в академ, Ваша мотивация повышается. Кроме учебника с заданиями и проектами, которые могут стать основой для Вашего портфолио, особое значение в обучении занимает обратная связь и социальная активность среди таких же как Вы. Для общения используется площадка slack.com. Для каждого потока учащихся свой куратор, преподаватели и наставники. Согласно правилам, Вы можете задавать вопросы в личных сообщениях, в специальных тематических каналах. Отвечают быстро, без задержек, согласно установленному регламенту. Здесь же проходит общение всех студентов. Весь поток поделен на группы. У каждой группы своё название. За каждой группой закреплен свой наставник и преподаватель. По общим вопросам обращаться нужно к куратору. Наставник проводит вебинары в которых предусматривается разъяснение непонятных тем. Главное, что всё проходит в режиме диалога всех участников вебинара. Это очень мотивирует. Можно общаться по видеосвязи или писать в чате. Некоторые вебинары посвящены разборам выполненных студентами работ. Есть вебинары которые ведут приглашённые дизайнеры. Если что-то непонятно в учебнике или во время выполнения проектов, нужно смело задавать вопрос преподавателю. Он в своем сообщении может объяснить тему или вступит в диалог если остался непонятный материал. Кроме общения slack используется для обмена ссылками на интересные и полезные ресурсы. В частности, UX, UI, типографика и смежные направления. Очень важным, с моей точки зрения, является самоорганизация и мотивация. Учебника достаточно для понимания предмета и формирования навыков для будущей работы. И всё-таки, эта система совершенна только при участии самого студента. Каждый человек уникален и скорость понимания и способности индивидуальны. Поэтому необходимо обращаться к внешним учебным материалам. Yandex, Google и другие поисковые системы содержат множество ссылок на полезные для ознакомления источники дизайнерской мудрости. Youtube с бесплатными уроками инструментария UX / UI дизайнера, профессиональная литература, чаты дизайнеров, где можно спросить и получить много полезной информации по профессии, просто необходимы. Курс от Яндекс.Практикум плюс личное дополнительное самообразование по профилю в совокупности дают очень и очень заметный результат.

Абзац, необязательный к прочтению

Я на протяжении двух лет следил за развитием событий в сфере онлайн-образования. Хотелось не ошибиться, сделать правильный выбор. Просмотрев хвалебно-зазывательные вебинары множества школ, решил что Яндекс.Практикум имеет больше плюсов. Во-первых, имя которое у будущих работодателей на слуху. Во-вторых, уверенность в том, что компания Яндекс нанимает лучших специалистов и методистов в сфере образования по конкретному направлению. В-третьих, сертификат от Яндекс.Практикума. Направление "Дизайнер интерфейсов" востребованное. Настоящих специалистов в этой области не много. А значит, есть возможность окончить данный курс и устроиться на работу в качестве UX/UI дизайнера. Меня лично интересуют финансовый сектор. Хотелось бы работать дизайнером интерфейсов в Альфе, в Сбере, в Тинькофф. Закончив обучение, я постараюсь написать о своих результатах. :) Интересно ведь, станет ли мечта реальностью?

Хотелось бы работать дизайнером интерфейсов в Альфе, в Сбере, в Тинькофф.

Когда я узнал про новый курс от Яндекс.Практикум, то готов был стать первым студентом. Однако по личным причинам задержался и попал только во второй набор. Я не жалею. Уверен, что судьба не зря так распорядилась. Среди второго набора много студентов находятся в ежедневном, ежечасном контакте вне образовательной площадки. Мы постоянно общаемся на темы дизайна, UX и за четыре месяца стали очень близкими друзьями. Я надеюсь мы продолжим общение и после обучения. Наше общение и обсуждение проектов из учебника, обмен решениями и критика друг друга делает что-то магическое. Будто в естественных условиях формируется команда специалистов одного профиля. :) Меня это радует и мотивирует.

Абзац про то как Яндекс.Практикум трансформировал моё сознание

Почему именно такое ощущение? Имея за плечами большой опыт в сфере графического дизайна, я сформировал личное отношение к времени, к работе, к периодам "выгорания", к застоям. В моём случае обучение в Яндекс.Практикуме совершает rebirth сознания. Я задумался над многими моментами в своей основной профессии. Переход в онлайн-среду предполагает скорый темп жизни, быть всегда в курсе трендов, уметь гасить состояние "творческой лени" ради результата. Раньше ограничения в виде спринтов с дедлайнами, принятых во многих компаниях, как режим работы, меня смешили и возмущали! Как можно делать творчество, находясь в рамках? :) Ибо любой дизайн это творчество. Но сейчас, я изменил своё мнение, я понимаю, что эти рамки нужны, они необходимы. Моя проблема личного характера, это взгляд на материал для вэба через призму мировоззрения графического дизайнера. :) Вроде монитор, экран, тот же лист бумаги, но это не так К тому же графика в моём случае это рождение статики через динамику. А работа в сфере дизайна интерфейсов предполагает динамику и только её. Причём связь каждого участка изображения, форма и место расположения активных зон экрана накладывает особую логику на процесс создания дизайна. Я это начал осознавать только благодаря учёбе. Моё незнание элементарных вещей в дизайне заполняется кирпичиками знаний из дизайна интерфейсов. А самое главное, это осознание связей блоков интерфейсного мира. Это на уровне интуиции и постоянного процесса мышления. Теперь это происходит автоматически вторым потоком. Я могу идти, ездить, есть, смотреть ТВ или делать любую другую работу, но мой поток мыслей о приложении или взаимодействии элементов экрана идет параллельно человеческой жизни.

Я очень много времени посвящаю курсу. Точнее даже не чтению и выполнению заданий, а рассуждению на пройденную тему. А затем я люблю углубляться в тему, читая статьи из интернета или проводя часы в Youtube, просматривая вебинары посвященные пройденному или ролики о новых трюках в Figma. Да, Figma заменила мне теперь и Люстру и Шоп. Вот уже четыре месяца я работаю в обычном браузере только на Figma. Дело не в удобстве. Мне захотелось отказаться от моих обычных инструментов чтобы привыкнуть к новой среде. У меня получилось. Появилась скорость, работа с горячими клавишами упростила процесс. Проекты которые нам дают в Яндекс.Практикуме обеспечивают развитие творческого потенциала. Один из проектов, который перевернул мой аналитический ум, ставил задачу усовершенствовать часть флоу реально существующей программы. Вместо выполнения поставленной задачи, я умудрился увлечься полным флоу, разложить весь сценарий со всеми дополнительными в огромнейшую схему взаимодействия. Когда я окончил работу, мне было совершенно очевидно, где я могу что-то изменить не повреждая другие блоки взаимодействий. И именно после этого задания, я понял, что потратив много времени, я отошел от задания. Меня это отрезвило. Ведь конечная цель любой работы придерживаться выполнения поставленной задачи. И тут дилемма. Хочется знать как работает приложение чтобы сделать его лучше. А нужно сделать лучше только в рамках некоторого блока. :) В следующем проекте я уже учитывал свою особенность перерабатывать и следую плану разработки. :) Эти же задания вызвали у меня много вопросов в отношении расположения активных элементов. Подняв эту тему в одном из чатов, я получил ответ отсылающий меня на исследования каких-либо учёных умов в области человек-машина. Я задумался над пользовательским опытом ещё до создания MVP. То есть понял, что для меня критично знать зоны активной деятельности на экране, обоснованные научными исследованиями и практикой использования. Мы рисуем эту кнопочку в этом углу не просто так. Так диктует пользовательский опыт. При этом в данном конкретном сегменте нового приложения этого опыта может не быть. Его нужно получить или предположить, каким он может быть. Удобство управления не в плоскости одного экрана, а в сценарии и последовательности взаимодействий, чтобы получать максимально короткие цепочки связей для формирования результата и предоставления пользователю вот моя стезя. Здесь я и хочу себя применить.

UI это бусы на нитях UX.

В этой структурности и порядке есть красота и польза для людей которые будут потреблять конечный продукт. UI это бусы на нитях UX. Каким бы значительным не был UX, UI это часть мира пользователя. Лояльность пользователя определяется не только удобством смыслового содержания действий, но и красотой и пониманием интерфейса. Поэтому UI также необходимо осмыслять и давать оценку его применимости основываясь на психологии человека, а также системы визуального и тактильного восприятия. К этим умозаключениям меня подтолкнула собственная цепочка действий - желание сменить профиль работы, курс "Дизайнер интерфейсов" от Яндекс.Практикум, общение в чатах UXUI дизайнеров. У меня складывается новое понимание системы взаимодействия под названием "Человек-машина", где интерфейс центр сознания обоих. Ведь человек это сознательное существо, и машина какую бы работу не выполняла, наделена свойствами, определяющими её сознание. Задача дизайнера интерфейсов создать модуль общения для обмена продуктом сознания обоих объектов. Мне кажется, что дизайнер интерфейсов или лучше сказать конструктор интерфейсов, это профессия будущего. И функциональные обязанности профессии шире во много раз, по сравнению с нынешним пониманием, ограничивающимся только вэб и мобильной разработкой.

P.S. Чтобы больше знать о пользовательском опыте создал сообщество UX в VK. Надеюсь наполнять его исследованиями в области интерфейсной науки.