Снижение доли тикетов в саппорт с 75% до 15% из-за одной, по сути, небольшой продуктовой доработки звучит как аргумент сильнее любого набора красивых экранов. Именно вокруг этой мысли строится материал про портфолио дизайнера: если большие кейсы под NDA, работ мало, а в резюме не космический редизайн всего продукта, это еще не повод собирать папку из пустых макетов и общих слов.
Об этом сообщает Habr / Карьера в заметке о том, как дизайнеру показывать ценность своей работы в ограничениях. Автор разбирает типичные страхи специалистов: нельзя раскрывать метрики, проект был маленьким, а самих работ немного. Проблема знакома не только джунам. На рынке, где найм стал придирчивее, а работодатели хотят видеть не просто вкус, а связь между решением и бизнес-эффектом, слабое портфолио дизайнера отсекает кандидата еще до первого созвона.
Главный тезис материала довольно отрезвляющий: портфолио не обязано быть выставкой из пяти больших продуктовых историй с ресерчем, графиками и драматургией в духе «все горело, я пришел и спас». На практике у многих дизайнеров картина прозаичнее. Кто-то работал внутри корпоративного контура и не имеет права показывать цифры. Кто-то месяцами делал не новый продукт, а одну настройку в старом. Кто-то вообще пришел на проект, где решения принимались маленькими итерациями, и весь его вклад не тянет на плакатный кейс. Но это не отменяет ценности работы. Отменяет только привычку честно ее описывать.
В материале приводятся несколько подходов, которые как раз помогают не маскировать ограничения, а работать с ними. Первый касается NDA-метрик. Частая ошибка выглядит так: раз нельзя публиковать точные показатели, значит, лучше вообще ничего не писать о результате. В итоге кейс превращается в пересказ про цвета, сетки и компоненты, а продуктовая часть растворяется. Автор показывает на примерах Никиты Петрова и Анатолия Микалюка, что можно раскрывать не сами числа, а направление влияния. Иначе говоря, дизайнеру полезно зафиксировать, на какие именно показатели была нацелена работа: конверсия, число обращений в поддержку, скорость прохождения сценария, удержание, активация или что-то еще. Для нанимающего менеджера это уже сигнал: перед ним не человек, который «порисовал интерфейс», а специалист, понимающий, зачем эта работа делалась и как ее вообще оценивают в продукте.
Второй важный прием касается маленьких задач. На российском рынке все еще живет странная идея, будто кейсом можно считать только редизайн крупного сервиса или запуск целого продукта. Все, что меньше, якобы недостойно отдельного разбора. В заметке этот подход разбирается на конкретном примере Саши Лыгина со статусами задач в Blum. Проблема была вполне земная: пользователь после действия видел спиннер до 24 часов и не понимал, что происходит дальше. Отсюда росло беспокойство за награду и поток обращений в саппорт. Ограничения тоже были не декоративные: быстро менять бэкенд было нельзя, а продуктом пользовались миллионы людей. В таких условиях дизайнер не пытался изображать грандиозную трансформацию системы, а показал ход мысли: какая была проблема, какие варианты рассматривались, почему выбран именно аккуратный вариант с понятным статусом и подсказкой по запросу. И вот тут цифра уже работает на полную: доля тикетов по этой проблеме снизилась с 75% до 15%. Размер фичи после этого обсуждать уже не очень интересно.
Для рынка это важный сигнал еще и потому, что найм в дизайне давно сместился от оценки «нравится визуально или нет» к оценке зрелости мышления. Продакты, дизайн-тимлиды и фаундеры смотрят не только на картинку, но и на способность человека работать внутри ограничений. Ограничения, если честно, и есть нормальная рабочая среда: нет доступа ко всем данным, сроки сжаты, бэкенд не готов, исследования неполные, а фича кажется слишком мелкой, чтобы про нее вообще говорить. Хорошее портфолио дизайнера в такой логике становится не галереей, а доказательством профессиональной оптики. Не «я умею делать красиво», а «я вижу проблему, понимаю контекст, принимаю решение и могу объяснить, почему оно было рациональным».
Третий сюжет из материала касается вечного соблазна добить объем портфолио количеством. Когда работ мало, дизайнер нередко начинает складывать туда все подряд: несколько анимаций, россыпь экранов, куски концептов, полунаброски мобильных интерфейсов, 3D-эксперименты и еще немного визуального шума «на всякий случай». Выглядит это обычно как витрина тревожности, а не как профессиональная подача. Автор противопоставляет этому пример Даниила Ермоленко, где одна работа показывает сразу несколько навыков: чувство движения, физику анимации, работу с 3D и аккуратную визуальную подачу. Вывод неприятный, но полезный: одна доведенная до сильного состояния работа продает навык лучше, чем десять средних. Для джунов и мидлов это особенно актуально, потому что именно на ранних этапах карьеры желание компенсировать нехватку опыта объемом часто дает обратный эффект.
Для работодателя, кстати, такой сдвиг в портфолио тоже выгоден. Нанимающей стороне обычно нужны не декоративные герои Behance, а люди, которые умеют формулировать задачу и не теряются, когда исходные данные далеки от идеала. Поэтому кейс без раскрытия точных чисел, но с ясным описанием целевой метрики, может быть полезнее, чем блестящий редизайн без объяснения, что именно в нем улучшилось. Точно так же небольшая продуктовая доработка с понятным влиянием на поддержку или пользовательскую тревожность может сказать о кандидате больше, чем «полный редизайн платформы», где из реальной работы виден только финальный слой пикселей.
На фоне более жесткого отбора в IT-найме это выглядит не как совет по оформлению, а как изменение стандарта. Портфолио все меньше похоже на альбом лучших картинок и все больше на короткое досье о том, как человек думает в продукте. Вопрос теперь не в том, есть ли у дизайнера гигантские публичные кейсы, а в том, умеет ли он честно упаковать ограниченный опыт так, чтобы из него читались зрелость, причинно-следственные связи и влияние на результат. Для многих специалистов это, возможно, даже хорошая новость: рынок наконец-то начинает смотреть не на размер кейса, а на качество аргумента.