Когда ищете дизайнера для веб-приложения, глаза разбегаются. Портфолио красивое, но после найма оказывается, что макет нельзя натянуть на реальный интерфейс: всё съезжает, разработчики проклинают, а сроки горят. И дело не в отсутствии вкуса, а в том, что дизайнер не умеет работать с системой.
Хороший UX/UI-дизайнер делает больше, чем рисует красиво. Он выстраивает процесс: от идеи до кода. В объявлениях сильных специалистов это видно сразу. Они говорят не только про цвет и шрифты — упоминают жизненный цикл продукта, компоненты и стыковку с фронтендом. Разберём, на что смотреть.
Что должен уметь дизайнер, если хочет делать продукты
- Проектирование от начала до конца. Полный цикл: исследование, сценарии, вайрфреймы, прототипы, финальный интерфейс. Если дизайнер делает только картинки в Figma без анализа задач, итог будет красивым, но бесполезным.
- Построение user flow. Важно уметь объяснить, как пользователь попадает из точки А в точку Б и где он застревает.
- Дизайн-системы. Это библиотека компонентов: кнопки, поля, карточки, цвета, типографика. Один раз собрали — потом используем везде. Это ускоряет работу и не даёт интерфейсу превратиться в хаос.
- Атомарный дизайн. Подход, при котором маленькие элементы собираются в более крупные блоки и страницы. Сайт становится конструктором, а не набором отдельных экранов.
- Паритет «дизайн — код». Означает, что элементы в макете соответствуют тому, что реально реализуют разработчики. Отступы, состояния, резиновость — всё одинаково.
- Интеграция с фронтендом. Дизайнер должен понимать, как его работа будет связана с архитектурой фронтенда. Писать код не требуется, но объяснять решения разработчикам — обязательно.
Важна не каждая строчка из списка по отдельности, а их связка. Когда дизайнер одинаково свободно говорит о прототипировании и о дизайн-токенах, скорее всего, он уже выводил продукты в продакшен.
Почему дизайн-система — это деньги
Многие заказчики считают дизайн-систему роскошью. Напрасно. Если вы заказываете лендинг, она может быть избыточной. Но если речь о веб-приложении с несколькими экранами и ролями, без системы вы переплатите.
Как это работает. Дизайнер создаёт библиотеку базовых элементов: иконки, кнопки, инпуты. Затем из них собирает более сложные блоки. Разработчики берут готовые стили и кладут их в код. Когда нужно добавить новую страницу, не приходится рисовать всё заново — достаточно использовать компоненты.
Плюс для бизнеса один: консистентный интерфейс. Пользователь привыкает к логике, меньше ошибается, быстрее достигает цели. А правки и развитие продукта стоят дешевле.
Таблица: что проверять в портфолио
Смотрите не на количество красивых экранов, а на наличие этих пунктов.
| Что смотрите | Зачем это нужно | Как проверить на собеседовании |
|---|---|---|
| Проектирование сценариев | Дизайнер понимает задачи пользователя, а не просто рисует | Попросите рассказать, как он решал конкретную проблему в кейсе |
| Вайрфреймы и прототипы | Показывают логику до того, как потрачены деньги на дизайн | Есть ли в кейсе черновики или только финальные макеты |
| Дизайн-система | Масштабирование без хаоса и лишних правок | Попросите показать библиотеку компонентов, а не просто скриншоты |
| Атомарный подход | Быстрая сборка новых страниц из готовых элементов | Спросите, как он структурирует файлы в Figma |
| Паритет «дизайн — код» | Разработчикам не приходится додумывать макет | Уточните, как передаёт документацию — просто ссылкой или со спецификациями |
| Работа с фронтендом | Меньше конфликтов между дизайном и реализацией | Спрашивайте про прошлый опыт интеграции с фронтендерами |
Типичные ошибки при выборе дизайнера
Первый и главный промах — смотреть только на скриншоты. Скриншот ничего не говорит о том, как дизайн ведёт себя при разных разрешениях, с разными данными и после правок. Требуйте показать процесс.
Вторая ошибка — игнорировать разговоры о технической стороне. Если дизайнер фыркает, когда вы спрашиваете про CSS-переменные или сетку, — бегите. Даже для не-технического заказчика важно, что специалист способен говорить с разработчиками.
Третья — нанимать дизайнера, который обещает «всё из коробки», но не показывает кейсов с развитием продукта. Хорошо, когда в портфолио есть примеры, как интерфейс жил после релиза: что дорабатывали, как система пережила рост.
Четвёртая — не проверять, как дизайнер принимает ограничения. Запросите правки «по нереальным требованиям» — например, придумать интерфейс для очень маленького экрана. И посмотрите, как он поведёт себя. Суть в другом: найдёт ли он компромисс.
Что делать заказчику
- Соберите бриф: цели, аудитория, ожидаемый стек. Чем яснее задача, тем легче оценить дизайнера.
- Попросите показать один кейс целиком: от вводных до передачи в код. Особенно интересуйтесь, как специалист работал с командой разработки.
- Уточните, войдёт ли дизайн-система в стоимость. Для продуктовых задач это обязательная часть.
- Если бюджет ограничен, обсудите поэтапную работу: сначала user flow и каркасы, потом визуал. Так вы снизите риски.
Сильный дизайнер сам расскажет о проектировании, системах и интеграции. Если в ответ на ваш вопрос о дизайн-токенах он отвечает «мы можем нарисовать красиво» — продолжайте искать. Продукт делают из решений, которые работают и через год.
Fluxs
Комментарии (0)
Войдите, чтобы комментировать.
Пока нет комментариев. Будьте первым.