Всем привет! Меня зовут Катя, я продуктовый дизайнер. За последние 5 лет успела поработать над разными проектами: от креативных сайтов и клиентских сервисов до высоконагруженных B2E систем и даже HMI интерфейсов.
За все время у меня был как опыт быстрого найма, когда ко мне обращались напрямую через знакомства или портфолио, так и тестовые задания, в том числе вайтборд. Но первый вайтборд комом (об этом как‑нибудь потом).
Хочу рассказать о том, как работала над тестовым заданием на стажировку в Т‑Банк. Как раз таки сюда я и не прошла вайтборд за пару недель до начала экзаменов на стажировку. Не стала отступать и спонтанно решила, что я в деле.
Подготовка
Я придерживаюсь такого мнения, что если ты хочешь работать в конкретном месте, то нужно максимально погрузиться в процессы и изучить стандарты компании. Поэтому заранее прочитала статьи прошлых лет о стажировке и тестовых. Хоть и многое для меня не в новинку, это дало ориентиры, на что делать фокус в своей работе.
Процесс работы
Понимание задачи
Погружение в предметную область
Исследование
Гипотезы
Проектирование
Выводы и дальнейшие шаги
Задача
Я выбрала задание в инхаус команду. Задача: спроектировать веб‑сервис для инженеров центра мониторинга беспилотного такси. Сервис должен помогать отслеживать состояние машин, выявлять проблемы и быстро на них реагировать.
Понимание задачи
Читаю задачу, подчёркиваю ключевые моменты, расписываю бизнес‑цели, миссию, аудиторию и метрики. Сразу формирую первые вопросы и записываю их, чтобы попытаться ответить в процессе исследования. Например: «Работает ли инженер посменно? За сколько машин отвечает? Как работает беспилотная машина и система в связке?»
Прочитать задачу один раз — мало. В процессе работы я постоянно возвращалась к карточке с задачей и понимашкой, чтобы убедиться, что я не ухожу в дебри и мое решение покрывает требования задачи.
Погружение в предметную область
На старте я не знала о беспилотных машинах ничего, кроме факта их существования. Что уж там — я и про обычные машины знаю немного.
Пошла в гугл и просто искала всё доступное: статьи на западных форумах, материалы про беспилотный транспорт Яндекса, интервью инженера из Waymo на ютубе, сайт с аналитикой по работе машин Tesla и Waymo. Уже на этом этапе начинает формироваться картинка, приходят первые идеи — их пока просто записываю, чтобы не забыть.
Машины почти всё время работают автономно, инциденты случаются нечасто, поэтому один инженер может отслеживать десятки машин одновременно. Ещё у Tesla нет лидаров и радаров — в отличие от Waymo и Яндекса. Представила, что Т‑Такси ближе к Яндексу по технологиям, и учла это при проектировании.
Исследование
Доступа к целевой аудитории у меня не было. Я не стала искать знакомых без релевантного опыта, чтобы не получить искажённые данные. Вместо этого выцепила инсайты из интервью с инженером Waymo на ютубе и почитала описания вакансий инженеров в команды беспилотного такси Яндекса и западных компаний — так сложила контекст работы.
Сформировала Job Stories. Важно: это гипотезы, которые обязательно нужно проверять в реальной работе. Но это лучше, чем гадать.
Дальше — бенчмарки. Выделила три типа интерфейсов для анализа:
Диспетчерские сервисы (Яндекс Таксопарк)
Управление беспилотниками (Wheelies, Waymo)
Системы мониторинга инцидентов (Incident.io, Finedog)
Работа над внутренними сервисами научила быть хитрым исследователем, потому что обычно в открытом доступе не так много решений конкурентов.
Помимо всем известного Моббина ковырялась в подвалах сайтов аналогичных продуктов, смотрела вебинары с разборами продуктов, спецификации и презентации.
Смотрю на паттерны навигации, работу с контентом, статусами, все фиксирую и делаю выводы, которые становятся основой моего сервиса.
Инциденты — основная рабочая зона инженера. Отказалась от идеи с картой на дашборде: привычный паттерн — табличный вид, карта может не дать полного контекста проблемы и увеличит время на обнаружение инцидента. В идеале я бы провела A/B-тест с картой, комбинированным видом и таблицей, чтобы узнать, что удобнее.
Гипотезы
Сформировала интерфейсные гипотезы: описала, как решения могут повлиять на метрики, какая потенциальная польза, и обосновала выводами из кабинетного исследования.
Так как по условиям задачи это новый сервис, то решаю, что буду оценивать гипотезы с точки зрения ценности и сложности реализации. А в работу возьму гипотезы с высшим приоритетном, чтобы продукт постепенно наращивал фичи.
Проектирование
Набрасываю, как система работает в связке: машины — интерфейс — инженер. Раскладываю функционал на информационной архитектуре, сверяюсь с задачей и выводами из исследования.
Выделяю два ключевых сценария для проработки happy path: устранение аварийного инцидента и проактивная отправка машин с низким зарядом на дозарядку.
Первые драфты
Первым вариантом стали черновые наброски в фигме. Важно было продумать навигацию, разложить контент на логические секции, продумать точки входа и убедиться, что нет тупиков.
Лайфхак: попросите нейронку почелленджить ваше решение, она может подсказать, где у вас есть слабые места или ux тупики. Можете попросить ее встать в роль инженера и дать обратную связь, но помните, что это не истина и нейросеть не заменит вам фидбек реальных людей.
Сценарии
Собираю референсы и перехожу к чистовым макетам. Наскринила внутренние интерфейсы Т-Банка, Яндекса и другие кусочки из Pinterest. Кстати, я веду тематические доски — это сильно ускоряет этап концепции. Велком на досочку: ссылка.
Я люблю чистоту в файле и макетах: навожу порядок, оставляю заметки, быстрые ссылки, помечаю флоу стрелочками и описываю, что происходит на экране. Макеты собираю на автолейаутах, проверяю нейминг слоёв. Это базовая гигиена — не пренебрегайте ей, особенно в командной работе.
Под конец ещё раз перечитываю задачу и проверяю решение. Кто-то скажет — тревожник, а я скажу, мне важны details. Собираю кликабельный прототип в Figma и прокликиваю сценарий. Кажется, всё готово. Почти.
Заключение
Возвращаюсь к целям, проверяю, решена ли проблема. В реальной работе решение нужно сверить с бизнес-процессами, проверить гипотезы на юз тестах, отрисовать корнер кейсы и ошибки. А дальше собирать фидбек и улучшать сервис.
Советы от меня
Не старайтесь сделать тестовое за 2–4 часа. Давайте голове переварить задачу, потомиться где‑то на фоне. Не бойтесь переосмысливать свое решение и ставить его под сомнение.
Фиксируйте свои мысли и идеи в процессе. Делайте заметки прямо в фигме, показывайте свой ход мысли максимально подробно и честно.
Не идите первым делом к нейросетям. Просите её челленджить решение и подсвечивать тупики, накидывать идеи. Но фильтруйте все решения через цели и выводы исследования.
Выбирайте только те фреймворки, которые сработают у вас. Не стоит проводить исследования ради исследования. Ваша цель собрать максимум полезных инсайтов, которые вы примените в решении.
Не бойтесь экспериментов. В тестовом у вас почти нет ограничений, придумайте контекст, главное — аргументируйте и подкрепляйте фактами.
Проявите заботу к опыту проверяющего. Создайте приятный опыт от проверки вашего задания, разложите все по логическим секциям. Бережно проведите по процессу и задайте фокус на важном.
Буду рада ответить на вопросы в комментариях и раскрыть любую тему подробнее.
Считаю своим долгом делиться опытом — возможно, моя статья окажется кому-то полезной, как когда-то мне помогли статьи других ребят. Мой подход помог выделиться среди большого числа кандидатов и пройти на этап собеседования.
Сейчас жду финального ответа. Если интересно, чем закончится история — заходите в мой телеграм, там я чаще делюсь мыслями и находками в дизайне.
Решение задания в фигме → ссылка