Иногда на старте проекта уже есть настолько подробное ТЗ, что кажется: осталось спроектировать экраны, нарисовать дизайн и передать всё в разработку. С hh.prom было примерно так.
Изначально задача выглядела как разработка отраслевого портала вакансий для промышленности. Работодатели размещают предложения, соискатели находят работу, откликаются — понятная механика, которую можно довольно быстро разложить на страницы и интерфейсы.
Но в процессе исследования и проектирования рамка продукта изменилась. Стало понятно, что просто ещё одна доска вакансий промышленному рынку не особенно нужна.
В итоге мы проектировали уже не каталог вакансий, а карьерную платформу, которая должна связывать работодателей, специалистов и образовательные организации.
И это хороший пример того, зачем вообще проводить UX-исследование до того, как команда начинает рисовать интерфейс.
[1] На старте всё выглядело довольно просто
Первоначальная логика продукта была линейной.
- Есть промышленная компания. У неё появилась вакансия. Компания публикует её на платформе.
- Есть соискатель. Он открывает каталог, выбирает регион, специальность, зарплату, опыт, находит подходящую вакансию и отправляет резюме.
В исходном ТЗ были главная страница, каталог вакансий, карточка вакансии, информация об индустриальных парках, раздел для работодателей и форма отклика. Для каталога предусматривались фильтры по локации, специальности, зарплате и опыту.
Причём продукт специально проектировался достаточно лёгким с технической точки зрения.
Полноценных личных кабинетов не было. Работодатель размещал вакансию через авторизованную форму, а дальше управлял публикацией по ссылкам из email: мог продлить вакансию или снять её. Отклики тоже приходили на почту. Модерацией занимался администратор.
Для MVP это вполне жизнеспособная схема.
Проблема была в другом: она описывала только момент, когда работодатель уже ищет сотрудника, а человек уже ищет работу.
А рынок труда устроен шире.
[2] Исходная логика оказалась слишком узкой
Если проектировать сервис буквально по исходному ТЗ, получается специализированный аналог обычного сайта вакансий. Только вместо всех профессий — промышленность.
Сам по себе такой продукт может работать. Но возникает вопрос: зачем пользователю идти именно сюда, если поиск вакансий уже закрывают крупные рекрутинговые платформы?
Вот здесь исследование становится важнее дизайна.
Нужно смотреть не на набор страниц из ТЗ, а на весь контекст: как человек вообще приходит в промышленную профессию, как выбирает компанию, где узнаёт о возможностях развития, как работодатель конкурирует за кадры и откуда в отрасли появляются новые специалисты.
Когда начинаешь рассматривать задачу так, продукт перестаёт быть только про вакансию.
Вакансия становится одним из сценариев.
[3] Вместо двух аудиторий появилось три стороны продукта
Самое заметное изменение — сама модель платформы.
В исходной постановке были две основные стороны: работодатель и соискатель.
В новой архитектуре появилась третья — образовательные организации.
hh.prom стал строиться как пространство, где встречаются компании, специалисты и образование. Именно так продукт описывается и в итоговой концепции проекта.
Это сильно меняет проектирование.
Для специалиста платформа — это уже не только «найти вакансию». В карьерном сценарии появляются стажировки, практика, знакомство с компаниями и возможности профессионального развития.
Для работодателя задача тоже шире, чем публикация объявления. Компании важно показать себя, рассказать о производстве и профессиях, работать с HR-брендом и формировать поток потенциальных кандидатов ещё до того, как открылась конкретная позиция.
Образовательные организации добавляют ещё один слой: связь программ подготовки с работодателями и промышленными профессиями.
На публичном уровне продукт в итоге позиционируется именно как карьерная экосистема промышленного сектора, а не как обычный сервис вакансий.
Это уже принципиально другой продукт.
[4] Когда меняется модель продукта, приходится пересобирать архитектуру
Вот здесь особенно хорошо видно отличие UX-проектирования от рисования интерфейсов.
Если бы мы сразу пошли в дизайн по первоначальной структуре, получилось бы несколько вполне аккуратных экранов: главная, каталог, вакансия, форма отклика.
После расширения модели этого было недостаточно.
Нужно было проектировать разные сущности внутри одной системы и понимать, как они связаны между собой.
В проекте появились отдельные структуры карточек специалиста, работодателя и университета. Мы переработали каталог, категории и фильтрацию, продумывали B2B-сценарии и работу с большим объёмом информации.
И здесь возникает типичная задача сложного digital-продукта. Можно сделать каждый раздел отдельно удобным, но получить систему, в которой пользователь постоянно упирается в тупики.
Например, человек нашёл интересную компанию. Что дальше?
Ему нужно видеть не только список открытых вакансий. Он может захотеть понять, чем занимается компания, какие специалисты ей нужны, есть ли стажировки и какие карьерные возможности существуют внутри.
И наоборот: компания существует на платформе не только в момент публикации вакансии. Её профиль становится самостоятельной точкой входа.
Поэтому мы проектировали не страницы, а связи между сущностями.
Это менее заметная часть работы, чем красивый первый экран. Но именно она определяет, сможет ли продукт дальше развиваться или через полгода его придётся собирать заново.
[5] Каталог пришлось проектировать заново
В исходном ТЗ каталог состоял только из вакансий. Карточка показывала должность, работодателя, локацию и зарплату, а пользователь мог фильтровать выдачу по региону, специальности, доходу и опыту.
После пересмотра концепции этого стало недостаточно. В продукте появились новые типы контента и отдельные структуры для работодателей, специалистов и образовательных организаций. Поэтому пришлось пересматривать категории, состав карточек и логику каталога так, чтобы новые сущности можно было добавлять без очередной переделки всей структуры.
[6] Профессиональная аудитория меняет требования к интерфейсу
В промышленном продукте легко уйти в одну из двух крайностей.
Первая — сделать всё слишком корпоративным. Много серого, таблиц, формального языка и интерфейс, который визуально напоминает внутреннюю ERP.
Вторая — попытаться сделать «молодёжный HR-сервис» и потерять ощущение серьёзной профессиональной среды.
Нам нужно было пройти между этими вариантами.
Интерфейс должен быть достаточно живым, чтобы работать с молодой аудиторией, студентами и начинающими специалистами, но при этом нормально восприниматься HR-командами, промышленными предприятиями и образовательными организациями.
При этом на экране много содержательной информации.
Поэтому визуальный дизайн здесь нельзя отделить от архитектуры. Если плохо расставить приоритеты, даже красивый интерфейс превращается в шум.
Сначала пользователь должен понять, куда он попал и что может здесь сделать. Потом — быстро найти нужное. И только после этого начинают работать визуальный характер, анимации и остальные элементы бренда.
[7] UX-исследование ценно не отчётом
Есть странная практика: провести исследование, собрать презентацию на сто слайдов, положить её рядом с ТЗ и дальше всё равно сделать продукт так, как собирались изначально. Тогда исследование действительно превращается в дорогой ритуал.
Его ценность появляется только тогда, когда после него команда готова менять решения.
В hh.prom изменилась сама рамка задачи.
Был портал вакансий.
Стала платформа, которая должна работать с карьерным маршрутом человека и соединять несколько участников промышленного рынка.
Из-за этого поменялись структура, сущности, пользовательские сценарии и требования к архитектуре.
То есть исследование повлияло не на цвет кнопки и не на расположение фильтра.
Оно повлияло на то, что именно мы вообще разрабатываем.
[8] Разработка тоже должна выдерживать изменение продукта
Когда продукт развивается таким образом, нельзя проектировать техническую часть только под набор экранов первого релиза.
В основе проекта использовался Python, но frontend строился на Vue. Vue работал в связке с Python, при этом заказчику передавался исходный код и документация, чтобы проект можно было дальше сопровождать и развивать.
Это важный момент.
Мы довольно часто видим проекты, где MVP технически сделан ровно под первоначальное ТЗ. Появляется новый тип пользователя, новый сценарий или новая сущность — и любое развитие начинает требовать обходных решений.
Здесь архитектуру изначально старались собирать так, чтобы продукт можно было расширять.
После основной разработки работа с платформой не закончилась: проект перешёл в развитие и техническую поддержку, включая UX/UI-доработки, новые интерфейсы и функциональность.
Для digital-продукта это нормальный сценарий. Запуск — не финальная точка.
[9] Что в итоге
Для нас hh.prom — в первую очередь не кейс про дизайн HR-сервиса.
Он про другое.
Подробное ТЗ ещё не означает, что продукт правильно сформулирован.
Заказчик может отлично понимать, какой функционал ему нужен сегодня: каталог, карточки, фильтры, формы, уведомления. И всё это действительно может понадобиться.
Но задача проектировщика — посмотреть уровнем выше.
- Какую проблему решает продукт?
- Кто реально участвует в этом процессе?
- Что происходит до целевого действия и после него?
- Почему человек должен пользоваться именно этим сервисом?
- Как сегодняшняя структура выдержит развитие через год?
В нашем случае ответы на эти вопросы постепенно превратили отраслевой портал вакансий в более широкую карьерную платформу для промышленности.
Именно для этого и нужно UX-исследование.
Не чтобы подтвердить уже нарисованный интерфейс.
А чтобы вовремя понять, что рисовать нужно вообще другой продукт.
Полный кейс в нашем портфолио: HH.PROM карьерная платформа для промышленных вакансий
