Провалила вайтборд, но прошла тестовое — как я делала задание для Т-Банка

Всем привет! Меня зовут Катя, я продуктовый дизайнер. За последние 5 лет успела поработать над разными проектами: от креативных сайтов и клиентских сервисов до высоконагруженных B2E систем и даже HMI интерфейсов.

За все время у меня был как опыт быстрого найма, когда ко мне обращались напрямую через знакомства или портфолио, так и тестовые задания, в том числе вайтборд. Но первый вайтборд комом (об этом как‑нибудь потом).

Хочу рассказать о том, как работала над тестовым заданием на стажировку в Т‑Банк. Как раз таки сюда я и не прошла вайтборд за пару недель до начала экзаменов на стажировку. Не стала отступать и спонтанно решила, что я в деле.

Подготовка

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

Процесс работы

1. Понимание задачи

2. Погружение в предметную область

3. Исследование

4. Гипотезы

5. Проектирование

6. Выводы и дальнейшие шаги

Задача

Я выбрала задание в инхаус команду. Задача: спроектировать веб‑сервис для инженеров центра мониторинга беспилотного такси. Сервис должен помогать отслеживать состояние машин, выявлять проблемы и быстро на них реагировать.

Понимание задачи

Читаю задачу, подчёркиваю ключевые моменты, расписываю бизнес‑цели, миссию, аудиторию и метрики. Сразу формирую первые вопросы и записываю их, чтобы попытаться ответить в процессе исследования. Например: «Работает ли инженер посменно? За сколько машин отвечает? Как работает беспилотная машина и система в связке?»

Прочитать задачу один раз — мало. В процессе работы я постоянно возвращалась к карточке с задачей и понимашкой, чтобы убедиться, что я не ухожу в дебри и мое решение покрывает требования задачи.

Погружение в предметную область

На старте я не знала о беспилотных машинах ничего, кроме факта их существования. Что уж там — я и про обычные машины знаю немного.

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

Машины почти всё время работают автономно, инциденты случаются нечасто, поэтому один инженер может отслеживать десятки машин одновременно. Ещё у Tesla нет лидаров и радаров — в отличие от Waymo и Яндекса. Представила, что Т‑Такси ближе к Яндексу по технологиям, и учла это при проектировании.

Исследование

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

Сформировала Job Stories. Важно: это гипотезы, которые обязательно нужно проверять в реальной работе. Но это лучше, чем гадать.

Дальше — бенчмарки. Выделила три типа интерфейсов для анализа:

• Диспетчерские сервисы (Яндекс Таксопарк)

• Управление беспилотниками (Wheelies, Waymo)

• Системы мониторинга инцидентов (Incident.io, Finedog)

Работа над внутренними сервисами научила быть хитрым исследователем, потому что обычно в открытом доступе не так много решений конкурентов.

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

Смотрю на паттерны навигации, работу с контентом, статусами, все фиксирую и делаю выводы, которые становятся основой моего сервиса.

Инциденты — основная рабочая зона инженера. Отказалась от идеи с картой на дашборде: привычный паттерн — табличный вид, карта может не дать полного контекста проблемы и увеличит время на обнаружение инцидента. В идеале я бы провела A/B-тест с картой, комбинированным видом и таблицей, чтобы узнать, что удобнее.

Гипотезы

Сформировала интерфейсные гипотезы: описала, как решения могут повлиять на метрики, какая потенциальная польза, и обосновала выводами из кабинетного исследования.

Так как по условиям задачи это новый сервис, то решаю, что буду оценивать гипотезы с точки зрения ценности и сложности реализации. А в работу возьму гипотезы с высшим приоритетном, чтобы продукт постепенно наращивал фичи.

Проектирование

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

Выделяю два ключевых сценария для проработки happy path: устранение аварийного инцидента и проактивная отправка машин с низким зарядом на дозарядку.

Первые драфты

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

Лайфхак: попросите нейронку почелленджить ваше решение, она может подсказать, где у вас есть слабые места или ux тупики. Можете попросить ее встать в роль инженера и дать обратную связь, но помните, что это не истина и нейросеть не заменит вам фидбек реальных людей.

Сценарии

Собираю референсы и перехожу к чистовым макетам. Наскринила внутренние интерфейсы Т-Банка, Яндекса и другие кусочки из Pinterest. Кстати, я веду тематические доски — это сильно ускоряет этап концепции. Велком на досочку: ссылка.

Я люблю чистоту в файле и макетах: навожу порядок, оставляю заметки, быстрые ссылки, помечаю флоу стрелочками и описываю, что происходит на экране. Макеты собираю на автолейаутах, проверяю нейминг слоёв. Это базовая гигиена — не пренебрегайте ей, особенно в командной работе.

Под конец ещё раз перечитываю задачу и проверяю решение. Кто-то скажет — тревожник, а я скажу, мне важны details. Собираю кликабельный прототип в Figma и прокликиваю сценарий. Кажется, всё готово. Почти.

Заключение

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

Советы от меня

• Не старайтесь сделать тестовое за 2–4 часа. Давайте голове переварить задачу, потомиться где‑то на фоне. Не бойтесь переосмысливать свое решение и ставить его под сомнение.

• Фиксируйте свои мысли и идеи в процессе. Делайте заметки прямо в фигме, показывайте свой ход мысли максимально подробно и честно.

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

• Выбирайте только те фреймворки, которые сработают у вас. Не стоит проводить исследования ради исследования. Ваша цель собрать максимум полезных инсайтов, которые вы примените в решении.

• Не бойтесь экспериментов. В тестовом у вас почти нет ограничений, придумайте контекст, главное — аргументируйте и подкрепляйте фактами.

• Проявите заботу к опыту проверяющего. Создайте приятный опыт от проверки вашего задания, разложите все по логическим секциям. Бережно проведите по процессу и задайте фокус на важном.

Буду рада ответить на вопросы в комментариях и раскрыть любую тему подробнее.

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

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

Решение задания в фигме → ссылка