Про портфолио продуктовых дизайнеров

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


ВАШИ КЛИЕНТЫ

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

Основные "клиенты" вашего портфолио (если вы не фрилансер):

🔺 HR — чаще всего смотрит с чек-листом в руках плюс субъективное восприятие. Для них важно просто наличие портфолио. Иногда у них есть чек-лист от лида, например: «Главное, чтобы не ссылка на Диск». Со временем HR, просмотрев сотни портфолио и наблюдая за реакцией лида, начинают чувствовать, кого точно не стоит передавать дальше. Поэтому здесь лучше минималистичные кейсы:

1–2 картинки + кратко:
- Какую задачу решали?
- Что делали?
- Какой результат получили?

💡 Совет: Экономьте время HR'а, и он это оценит.

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

- Как вы работали с данными?
- Как измеряли успех?
- Как принимали решения?

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


ПРО ФОРМУ

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

Первая страница\экран — краткая выжимка для HR + картинка.
Скролл вниз или кнопка «Подробнее» → развёрнутое описание.
Ссылки на макеты в Фигме, прототипы для дизайн-лидов.

Сайт, Dribbble/Behance или Notion — вот в чём вопрос.

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

Лучший вариант — персонализированный сайт (даже на конструкторе). Он помогает выделиться, даёт больше контроля и возможностей, при этом не намного сложнее в реализации, чем Notion.

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


КАК НЕ НАДО

Я уже писал, что нужно экономить время HR, но это оценят и остальные. Поэтому никаких архивов и ссылок на Яндекс.Диск.

Из моей практики самые жёсткие антипримеры:
- Архив на Яндекс.Диске, в котором два .doc-файла с ссылками на Behance 🙈
- Логин и пароль от Behance вместо ссылки на портфолио 🤯

Ещё один момент: мокапы. Дизайн не должен мешать получению смысла. Главное - это ваши макеты, а не в какой макбук или айфон вы их вставили. И, я вас заклинаю, не поворачивайте макеты в мокапе ни в какую сторону. Вот прям фронтально показывайте с углом поворота 0°, разглядывать "креативные" мокапы в изометрии болит шея к концу дня.


ТОЛЬКО ЦЕННОЕ

Финальный совет — пишите о реальном опыте и вызовах.

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

✅ Опишите, какие инсайты вы получили и как они повлияли на результат.

Если вам кажется, что опыт не релевантный — напишите, чему научились. Опыта мало — вытащите всё полезное и важное из тех кейсов, что есть.

Будьте честны, пишите про реальные сложности — и ваше портфолио обязательно заметят.

- -
#портфолио

🛫 Канал: UXFLOW • Сергей Мухин
Сайт: uxflow.ru

Внедрение дизайн-системы сложнее чем реализация

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

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

Но что, если у вас сотни разработчиков, миллионы пользователей, а дизайн-системы нет вовсе? Более того, нет даже базового UI Kit’а, от которого можно было бы оттолкнуться? В таких условиях всё усложняется. Конкретные решения уже не так важны, на первый план выходят процессы, политика и поиск союзников.

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

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

- -

🛫 Канал: UXFLOW • Сергей Мухин
Сайт: uxflow.ru

Функции дизайн-системы

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

Недавно, рассказывая о своих дизайн-системах, столкнулся с удивлённой реакцией: у меня в документации подробно описаны свойства и поведение компонентов, но нет чёткого указания, когда и как их использовать. Например, чем чекбокс отличается от свитчера? Или насколько «зелёную» кнопку должен выбрать дизайнер? Как же дизайнер поймёт, что ему делать?

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

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

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

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

А как у вас? Кто в вашей дизайн-системе описывает применение и решает, какой компонент использовать?

- -

🛫 Канал: UXFLOW • Сергей Мухин
Сайт: uxflow.ru

Наткнулся на статью: в Salesforce Lightning — тех самых, для которых Jina Anne ещё в 2014 придумала концепцию дизайн-токенов — решили отказаться от самого термина. Сконцентрировались на CSS-переменных и считают, что грядущая спецификация W3C слишком сложная и движется не в ту сторону.

Это мне напомнило, как во времена хайпа вокруг performance review один из авторов метода позже сам признал его неэффективным.

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

- -

🛫 Канал: UXFLOW • Сергей Мухин
Сайт: uxflow.ru

Тестовое... Опять...

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

Но реальность такова, что с тестовыми всё равно сталкиваешься. И тут закономерный вопрос:
Как понять, каким должен быть результат, чтобы вот точно пройти?
Ответ: никак. 🤷🏻‍♂️

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

Недавний пример — тестовое на позицию лида дизайн-системы.
Сначала вопрос: «Команда хочет какой-то неведомый компонент. Как будете собирать и обрабатывать требования?»
Следом: «Сделайте этот компонент в Figma».
Но, Карл, ты же сам только что сказал, требований пока даже нет... Что тогда я должен сделать-то? 😔


Как быть?

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

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

Если никакой информации нет — делайте так, как вы бы делали это в реальной работе. Максимально естественно и честно. В худшем случае просто не совпадёте ожиданиями нанимателя — это нормально.

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

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

- -

🛫 Канал: UXFLOW • Сергей Мухин
Сайт: uxflow.ru

Пока писал предыдущий пост, подумал: жаль, не сохранилось ни одного файла из того, что я тогда делал во Flash…
Или всё-таки сохранилось?

Перетряхнул старые ящики электронной почты — и да, нашёл рабочий проект!

Это кусочек сайта, который я делал в 2007 году на тему рок-музыки. Треки, конечно, давно не запускаются, но сам плеер жив — всё нажимается, перетаскивается.

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

Интересно, сколько седых волос я бы сейчас заработал, если попытался бы повторить всё это на JS…

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


- -

🛫 Канал: UXFLOW • Сергей Мухин
Сайт: uxflow.ru

Уже довольно давно основным источником новостей и вдохновения в дизайне для меня стали разные дайджесты, подборки и ленты. Наверное, единственный дайджест, который я читаю регулярно — это Дайджест продуктового дизайна, который ведёт Юрий Ветров.

И вот листаю свежий выпуск за март, и вижу: «Сергей Мухин рассказывает…».

С момента, как я начал вести канал и писать статьи, это до сих пор остаётся самым удивительным — когда кто-то находит в твоём тексте ценность и делится им без твоего участия. Но когда видишь свою статью в медиа, которое сам читаешь — это уже буквально чувство из серии: «Мам, я в телевизоре!»

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

Саму статью можно почитать на моём сайте.

- -

🛫 Канал: UXFLOW • Сергей Мухин
Сайт: uxflow.ru