Одна из наиболее востребованных и горячих тем, связанных с дизайном — это, конечно же, трудоустройство, портфолио, собеседования и все, что связано с профессиональной реализацией. На Youtube такие видео набирают просмотры даже на небольших каналах.
За год изучения вопроса и погружения в тематику посмотрел большое количество текстов и видео. Если все эти материалы сжать в одну эмоцию, то это однозначно будет «страдание». Дизайнеры страдают… Недавно попалось видео в котором молодая дизайнерка рассказывала трагическую и поучительную историю своего трудоустройства, сравнимую по накалу страстей ни много ни мало с самим Гамлетом. Фабула: заказчики дураки, а я в белом пальто стою красивая. Ну, и конечно, не обошлось без советов космического масштаба и космической же глупости…
Высокая конкуренция — это всегда стресс, но это не значит, что действовать нужно наугад в надежде, что в итоге количество перейдет в качество… может не перейти. Про графический дизайн не берусь судить, но в дизайне интерфейсов, UX/UI главная задача — сделать удобно, понятно и эстетично. Ровно эти же требования предъявляются и к хорошему портфолио т.е. умелый UX/UI дизайнер вынужден подходить к своему портфолио «юиксово», но к сожалению так бывает далеко не всегда.
Я задумал написать серию небольших статей в жанре «что такое хорошо и что такое плохо» в отношении портфолио UX/UI дизайнера. Надеюсь, эти скромные труды хотя бы немного снизят градус страданий от отказов и игнора со стороны потенциальных работодателей.
Связанные материалы
Эта статья предназначена двум категориям читателей:
рекрутерам, которые профессионально занимаются поиском UX/UI дизайнеров, продуктовых дизайнеров и иных специалистов, которые проектируют интерфейсы
дизайнерам интерфейсов, которые откликаются на вакансии, публикуемые первой категорией читателей
Эта статья для вас, если вы составляете вакансии / откликаетесь на вакансии в которых есть речевые обороты вроде этих:
«Уметь объяснять свои решения и вести новые фичи от дизайн-концепции до продакшена»
«Развивать дизайн-систему с учётом адаптивных и персонализированных сценариев»
«Cледить за консистентностью интерфейсов»
«Заниматься созданием концепций дизайна, прототипов, макетов, wireframes с учетом лучших практик пользовательского интерфейса (UI) и пользовательского опыта (UX)»
Все эти обороты и аналогичные им по смыслу подразумевают, что вы ищите / вы являетесь дизайнером, который понимает толк в проектировании, решает задачи бизнеса и пользователей, а не просто рисует макетики (возможно, божественной красоты!) в Figma.
Далее я опишу комплекс ошибок, нередко встречающихся в кейсах из портфолио UX/UI дизайнеров, которые показывают, что дизайнер не очень-то дружит с проектированием. Все эти ошибки носят системный характер и напрямую связаны с проектированием портфолио. И действительно, можно ли доверить проектирование интерфейса человеку, который не может как следует спроектировать кейсы в собственном портфолио?
Любой кейс стади имеет содержательное ядро, состоящее из трех компонент: задачи, решения и итога.
Задача описывает мотив всех дальнейших действий, отвечает на вопрос зачем вообще нужно было что-то делать?
Решение описывает конкретные действия, отвечает на вопрос что было сделано?
Итог описывает ощутимый результат, профиты, полученные в результате предпринятых действий.
В целом это довольно простая мысль, но можете ли вы сходу со 100% уверенностью утверждать, что в вашем портфолио с этим полный порядок? А если проверить?
Концепция ядра хороша тем, что через нее можно описать критические проблемы при проектировании кейс стади. Я выделяю два класса таких проблема:
Нарушение структуры ядра
Нарушение связей между частями ядра
Нарушение структуры ядра — это отсутствие хотя бы одного из компонентов. В общем и целом бывают случаи, когда отсутствует сразу несколько, но это тяжелый случай, его рассматривать не будем, чтобы забраковать кейс достаточно отсутствия хотя бы одного. Итак, имеем три структурные проблемы:
Отсутствует задача
Отсутствует решение
Отсутствует итог
Каждая из этих проблем указывает на вероятные сложности во взаимодействия с дизайнером. Сводная таблица «ошибка - проблема» приведена в конце статьи (см. вывод 2).
Рассмотрим по порядку каждую из проблем и соответствующий ей пример. В каждом пункте привожу ссылку на видео разбор кейса. Видео формат пригодится, если захотите разобраться в деталях и увидеть проблемы в контексте.
Если в кейсе отсутствует задача, то все, что в нем изложено не имеет особого смысла. Автор подобного кейса скорее всего в большинстве случаев действует инстинктивно, наугад. Добиться от него внятного ответа на вопрос «зачем ты это делал?» будет крайне затруднительно. Объяснить свои решения он вряд ли сможет.
Эта проблема встречалась в 20-ом эпизоде разборов кейс стади. Вот как автор описывал задачу кейса:
Los Angeles Black Worker Center (LABWC) — это низовая некоммерческая организация, которая стремится улучшить условия жизни и труда чернокожих работников по всему Лос-Анджелесу. Они возглавляют пропагандистские усилия, чтобы влиять на политику, корпоративные практики и правительственные инициативы в пользу более сильной защиты труда, справедливой оплаты труда и равенства на рабочем месте.
LABWC хотел модернизировать свой бренд и свой веб-сайт.Интеграция смелой типографики, символических узоров и личной фотографии делает новый бренд таким же динамичным, значимым и мощным, как и сообщество, которое он представляет.
Здесь речь идет о какой-то «модернизации сайта и бренда». Это средство, а цель-то в чем? Зачем потребовалось модернизировать? Какая проблема заказчика побудила начать этот процесс?
Если в кейсе отсутствует решение, то это не столько кейс стади, сколько фокус. Хороший фокусник, как известно никогда не раскрывает свои секреты, а вот про дизайнеров так сказать можно едва ли… Автор подобного кейса скорее всего будет работать с хаотичным качеством, зависящим от вдохновения или, прости господи, инсайта.
Эта проблема встречалась в 12-ом эпизоде разборов кейс стади. Вот как автор описывал задачу и решение.
В последнее время на подъеме находятся персонализированные бренды по уходу за кожей… Sephora и Ulta предлагают большой выбор популярных брендов и продуктов, но не предоставляют потребителю никаких рекомендаций, кроме онлайн-викторин и продавцов-консультантов, чей опыт в уходе за кожей не является достаточным.
Glowtastic хочет запустить свой бренд и выделиться среди конкурентов,улучшив процесс покупки средств по уходу за кожей. Поэтому компания запросила функцию, которая поможет улучшить процесс покупки средств по уходу за кожей, а также набор для брендинга.
Далее автор приводит элементы стиля (см. рис.1). Можно ли это считать решением поставленной задачи? Колористика и типографика прорабатываются в любом проекте. Для того, чтобы продемонстрировать как выбранный стиль выделяет продукт на фоне, нужен этот самый фон, а здесь он отсутствует.
Если в кейсе отсутствует итог, то невозможно оценить ценность проделанной работы. Все что делается: дизайн, исследования, тестирование и пр. — делается ради итога. Автор подобного кейса скорее всего не понимает потребностей бизнеса, он свободный художник, ну, тот самый, который «… я так вижу!»
Эта проблема встречалась в 19-ом эпизоде разборов кейс стади. Вот как автор описывал итог кейс стади.
Извлеченные уроки
1. Я начинал этот проект, предполагая, что приложение будет предоставлять только одну функцию: приостанавливать и возобновлять подписки. Однако я очень быстро понял, что для принятия таких решений пользователям нужна информация, к которой у них нет доступа.
2. Предоставление конфиденциальной информации, например, учётных данных других учётных записей, вызывало подозрения. То, что само приложение обещало снизить расходы, создавало дополнительные сомнения. Приложению необходимо было развеять эти опасения с помощью продуманного текста на ключевых экранах, а также предлагать пояснения и способы связи со службой поддержки…
В оригинале список значительно длиннее — пунктов 6-7, но все они про рефлексию в духе начальных сезонов South park — «сегодня мы многое поняли». Авторская рефлексия не может заменить метрик.
Теперь рассмотрим второй класс проблем.
Нарушение структуры ядра — это ситуация, когда все части на месте, но они полностью или частично не связаны друг с другом. Классический пример — письмо родителям из Простоквашино в котором у Дяди Федора все хорошо, но бывает ломит лапы и повысилась шерстистость. Основных проблем в этом классе тоже три:
Нарушена связь между задачей и решением
Нарушена связь между решением и итогом
Нарушена связь между итогом и задачей
Нарушение связи между задачей и решением — это когда «решение» формально есть, но задача была про другое. Эта проблема знакома любому дизайнеру потому, что именно она является причиной бесконечных поправок и переделок. Часто за многочисленные правки винят заказчика. Угадайте с трех раз из чьей ж*пы на самом деле руки растут? Автора подобного кейса нужно будет если не постоянно, то регулярно администрировать, чтобы он не сбился с курса и не начал делать что-то не то. И конечно, будьте готовы к многочисленным переделкам.
Эту проблему буду освещать в 31-ом эпизоде разборов кейс стади, который выйдет 30.07.
Проблема звучала так: «Из-за недостатков софта, сотрудники ведут записи на бумаге». Казалось бы, вполне понятная ситуация, которую необходимо исследовать, определить причину и устранить ее при помощи дизайна.
К сожалению, причина не была описана, а итоговое решение подавалось как «универсальная и надежная система, соответствующая лучшим практикам UX» (см. рис. 2). Как нетрудно догадаться, эта фраза не стоит тех битов, которые использованы для ее хранения на серверах. Я уж не говорю о том, что оценочные суждения в кейсах — это дурной тон, ширма, которая обычно прикрывает отсутствие содержания.
Нарушение связи между решением и итогом — это когда из предложенного решения не следуют выводы описанные в конце кейса. Один из явных примеров нарушения логики между решением и итогом — мы сделали сочную картинку и продажи возросли. Какие ваши доказательства? Часом не кокаинум?! Автор подобного кейса будет регулярно выдавать желаемое за действительное, трактовать все в свою пользу, натягивать сову на глобус.
Эта проблема встречалась в 21-ом разборе кейс стади. Для понимания контекста задача описывалась так:
Worldpackers — это сообщество, основанное на сотрудничестве, которое делает путешествия более доступными для тех, кто ищет глубокий культурный опыт. Через онлайн-платформу мы связываем путешественников, желающих обменять свои навыки на размещение, с невероятными хозяевами со всего мира.
В 2015 году мы решили инвестировать в мобильные устройства, запустив приложение, чтобы помочь путешественникам находить и подтверждать свой опыт Worldpacker на ходу.
Нашими главными целями были: повышение удержания пользователей и более быстрое время отклика
А вот некоторые из итоговых метрик:
И тут вы вероятно спросите — а в чем же было решение? А я вам отвечу — поезжайте в Киев и спросите это неважно потому, что повышение метрик, относящихся к количеству и активности пользователей в туристическом контексте с высокой вероятностью обеспечено за счет перехода от стационарного устройства к мобильному. Есть ли в кейсе попытки разделить влияние которое оказала смена устройства и влияния от дизайнерских решений — догадайтесь сами.
Нарушение связи между итогом и задачей — это когда итоги и задача связаны весьма условно или не связаны вообще. Автора подобного кейса нужно будет регулярно просить переводить с дизайнерского на бизнесовый. Если предполагается, что он должен постоянно контактировать с заказчиком или публично представлять результаты, то супервизия будет нужна постоянно.
Эта проблема встречалась в 22-ом разборе кейс стади. Интересный и хорошо проработанный кейс дизайнера из Uber.
Задача описывалась так:
Приложение Rider, разработанное в 2012 году, с трудом масштабировалось вместе с гиперростом компании.
Итог измерялся следующими метриками:
Расстояние ошибки между запрошенным местом посадки и фактическим сократилось на 34%
Время ожидания водителя сократилось на 20%
Уровень точности посадки увеличился на 17%
Уровень множественных контактов снизился на 3%
В общем и целом эти метрики можно подтянуть к поставленной задаче, но делать это нужно явно и ответственность за это, само собой, лежит на авторе кейса.
На этом мой список критических ошибок подошел к концу. В заключение приведу несколько практических выводов.
Вывод 1: Экспресс проверку / самопроверку кейс стади можно делать по следующему алгоритму:
Шаг 1: Проверить структуру ядра
Задача описана понятно? В ней фигурирует проблема заказчика и / или пользователя? Понятно ради какого профита было потрачено рабочее время дизайнера?
Из кейса понятно что конкретно сделал дизайнер? Описание не слишком абстрактное, водянистое?
Итог измерим? Его можно проверить? Не пытается ли дизайнер подменить результат саморефлексией или необоснованной самопохвалой, оценочными суждениями?
Шаг 2: Проверить наличие связей между составляющими ядра
Действия, которые совершает дизайнер, связаны с поставленной задачей? Эта связь обоснована, представлена в явном виде?
Предлагаемые итоги вытекают из предпринятых действий?
Описанный итог отвечает на поставленные в начале кейса вопросы? Проблемы пользователя устранены? Заказчик получил желаемый / заявленный профит?
Вывод 2: По описанным проблемам можно с немалой вероятностью предсказать те сложности, которые вас ждут при взаимодействии с дизайнером.
Проблема в кейсе | Сложности во взаимодействии |
Проблемы в структуре ядра | |
Отсутствует задача | Автор подобного кейса скорее всего в большинстве случаев действует инстинктивно, наугад. Добиться от него внятного ответа на вопрос «зачем ты это делал?» будет крайне затруднительно. Объяснить свои решения он вряд ли сможет. |
Отсутствует решение | Автор подобного кейса скорее всего будет работать с хаотичным качеством, зависящим от вдохновения или, прости господи, инсайта. |
Отсутствует итог | Автор подобного кейса скорее всего не понимает потребностей бизнеса, он свободный художник, ну, тот самый, который «… я так вижу!» |
Нарушение связей между составляющими ядра | |
Нарушена связь между задачей и решением | Автора подобного кейса нужно будет если не постоянно, то регулярно администрировать, чтобы он на сбился с курса и не начал делать что-то не то |
Нарушена связь между решением и итогом | Автор подобного кейса будет регулярно выдавать желаемое за действительное, трактовать все в свою пользу, натягивать сову на глобус |
Нарушена связь между итогом и задачей | Автора подобного кейса нужно будет регулярно попросить переводить с дизайнерского на бизнесовый. Если предполагается, что он должен постоянно контактировать с заказчиком или публично представлять результаты, то супервизия будет нужна постоянно |
Как всегда, для активных читателей есть ряд дополнительных возможностей:
для дизайнеров
Текст не лучший формат для разбора кейсов. Разборы в видео формате регулярно публикую в ТГ @ux_square
До конца недели открыта регистрация на экспериментальных курс по насмотренности. Подробности в ТГ в закрепе. О прокачке насмотренности писал в прошлой статье.
Поскольку эта статья написана в рамках цикла статей, то рекомендую посмотреть предыдущие, наверняка найдется что-то полезное. Список см. в начале статьи.
для HR-ов
Если взаимодействие с UX/UI дизайнерами это ваш постоянный головняк и есть желание рассказать какие-то интересные истории из практики, можем затеять какую-нибудь совместную активность: статью, интервью и пр. По этому вопросу можно писать мне в ТГ напрямую.