Как провалить тестовое, следуя ТЗ до конца

Как вы знаете, рынок дизайна сегодня — это сотни откликов на одну вакансию, а бонусом к каждой вакансии — тестовые задания. Некоторые из них требуют действительно пары часов, на другие же тратится времени почти как на полноценный проект. Для последних часто необходимо полноценное погружение, UX-проработки, прекрасное понимание Figma и пользовательских сценариев, но при этом они все остаются неоплачиваемыми и нередко заканчиваются обычным игнором.

Это история как раз о таком кейсе. Я получил тестовое на позицию UX/UI-дизайнера от агентства, выполнил его с максимально серьёзным подходом, сделал User Flow, CJM, UI-кит, UX-исследование и макет. А потом получил обратную связь, которая вызвала больше вопросов, чем дала ответов.

Отбор начался с небольшой анкеты и скриншотов игры Can’t Unsee. А уже после этого кандидат получал ТЗ в Telegram.

Через два дня мне в Telegram приходит данное сообщение

Анкету, судя по всему, просматривали мельком — HR ошиблась с городом и даже обратилась ко мне в женском роде.

Здесь я спросил, каков дедлайн, кем тестовое будет проверяться и какое кол-во времени необходимо на его проверку.

Что интересно, результат тестового будет проверяться действующим дизайнером агентства, место которого может занять кандидат.

Ну а следующим сообщением приходит тестовое

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

• Выявить UX-проблемы текущего сайта и предложить новый сценарий: «зашёл — заказал — получил» • Создать низкодетализированный прототип

• Создать низкодетализированный прототип

• Сделать редизайн главной страницы

Ну а к сценарию самовывоза просили не обращаться. Казалось бы, всё предельно понятно и никаких трудностей не предвидится.

Я начал с анализа текущего сайта и проработки User Flow, далее сделал CJM — с учётом всех технических ограничений и логики пользовательского поведения.

Затем было выполнено:

• Проектирование главной страницы, карточки заведения, карточки блюда, корзины и оформления заказа

• UI-kit, где я описал все визуальные принципы нового дизайна и компоненты (После отправки макета, слегка его переделал, добавив новые блоки)

• Список UX-проблем сайта и предложенные улучшения с пояснением, почему они критичны для конверсии и пользовательского опыта

Использовал сетку с контентной областью 1366 px и интервалами по 20 px. Такая структура создаёт баланс: с одной стороны, страница остаётся адаптивной для ноутбуков, с другой — боковые отступы добавляют «воздуха» и улучшают визуальное восприятие.

Полностью переработал структуру сайта, сменил шрифтовую пару на «Mulish» и «Nunito» Гармоничное сочетание с дружелюбным характером, которое отлично подходит фуд-тематике. Эти шрифты можно использовать в коммерческих проектах, за чем также довольно важно следить.

Обновил цветовую палитру: добавил оранжевый и акцентный фиолетовый — оба оттенка ассоциируются с едой и аппетитом, усиливают вкус в визуальном восприятии и хорошо выделяются на фоне. В первом блоке я вывел три популярных блюда одного ресторана. Это создаёт маркетинговое преимущество: заведение может «купить» этот блок, чтобы продвигать свои лучшие блюда. Используемый мной подход не только повышает продажи конкретных блюд, но и формирует ценность сервиса как площадки для сотрудничества.

Далее идёт блок преимуществ, который отвечает на вопрос пользователя: «Почему я должен выбрать именно этот сервис?». Это повышает доверие потенциального клиента.

Я убрал раздел «Ещё» из фильтров — в нём была лишь одна категория «Сладкое», которая и так вписывается в общую ленту. В самих карточках я усилил приоритет визуала блюд, а логотипы аккуратно поместил в правый верхний угол, что сохранило узнаваемость заведений, но не перегрузило саму карточку.

Также я заменил непонятную фразу «от 600₽» на «Мин. заказ: 600₽», чтобы избежать путаницы со средним чеком. Это важная правка, исходя из пользовательских болей, выявленных в моём CJM.

Футер получил обновлённую структуру: я перераспределил контент, усилил читаемость и добавил визуальный порядок.

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

Карточка блюда также была изменена: контурные кнопки заменили заливку, чтобы избежать чрезмерного визуального шума. Элементы с пометками «новинка» и «хит» теперь выглядят более выразительно и лаконично, визуально перекликаясь с блоком преимуществ на главной странице, что поддерживает консистентность всего дизайна.

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

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

Я заблюрил фон, чтобы сфокусировать внимание на карточке. Контент структурировал по смыслу: сначала состав, затем описание, а потом энергетическая ценность и БЖУ. Важно подметить, что описание и состав теперь слева, ведь именно эта часть привлекает к себе больше всего внимания.

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

Я упростил визуальное восприятие формы: разбил её на логические блоки, чтобы уменьшить нагрузку на пользователя. Благодаря этому страница больше не воспринимается пользователем как длинная и сложная.

Все элементы упрощены и выровнены по вертикали, что помогает быстро пробежать глазами по содержимому. Кнопки имеют высокий приоритет, а основное CTA «Оформить заказ» контрастен и хорошо заметен.

На всё это у меня ушло два полных рабочих дня. Конечно, не целая неделя, но и не «пару часов»

Из важных моментов, которые я не реализовал в макете, но понял это уже в момент отправки:

• Было бы отличным решением добавить поп-ап с вводом адреса при первом заходе, дабы пользователь смог сразу ввести адрес доставки и ему выдавались только те рестораны, откуда имеется возможность совершить заказ.

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

На удивление, тестовое проверили очень быстро, отправил его я вечером в 19 часов, а ответ пришёл уже утром на следующий день. Фидбек был таков:

«Не хватило понимания, что будет третьим шагом при оформлении заказа. Не предусмотрены отслеживание, отмена заказа, история предыдущих заказов. Возможно, это должно быть в личном кабинете, но он не отображён.»

Формально — замечание корректное. Только есть один нюанс: на сайте, очевидно, нельзя оформить заказ без реальной оплаты. Следующий шаг после кнопки «Оформить» появляется только после фактической оплаты заказа.

То есть, чтобы показать третий шаг, мне, как кандидату, нужно было оформить и оплатить заказ — в рамках неоплачиваемого тестового. Или нарисовать этот шаг «с нуля», вообразить, как бы всё это выглядело, но данный вариант очень слабо вписывается в саму задачу из ТЗ «Выявить проблемы существующего пользовательского пути и предложить переработанный сценарий доставки еды». Выявить проблемы нынешнего пользовательского пути третьего шага не является возможным без полноценного заказа у агрегатора.

Если всё же имелось в виду придумать с нуля третий шаг, то формулировка задачи была нечёткой: в тексте задания было сказано «зашёл — заказал — получил», и можно предположить, что «получил» — это и есть третий шаг. Но об этом — ни слова подробнее, что нужно рисовать дополнительные макеты с самого нуля.

«Важно понимать, что человек, открывающий приложение доставки, уже принял решение воспользоваться именно нашим сервисом. Его цель на этом этапе — максимально быстро и просто выбрать еду, а не сравнивать рестораны.»

Т.е., по мнению проверяющего дизайнера, человек, который только что зашёл в приложение агрегатора, обязательно должен оформить заказ, он не может просто поинтересоваться, что это за сервис и не может уйти с него? Да и на текущем сайте главный экран состоит именно из ресторанов, а карточки еды там появляются только внутри самих заведений. Мне же предложили отказаться от текущей логики и показывать блюда сразу, без выбора ресторана. При этом в ТЗ было сказано, что оформить заказ можно только из одного заведения.

«В текущей версии приложения основной акцент сделан на ресторанах, однако главный экран не показывает пользователю самое главное — аппетитные блюда, которые можно заказать здесь и сейчас. Это создает ненужные барьеры: вместо того чтобы сразу увидеть то, зачем он открыл приложение (вкусную еду), пользователь вынужден листать список заведений, анализировать их и делать лишние действия.»Дизайнер предлагает отказаться от концепции карточек ресторанов, вместо них оформив всё «одним полотном». В итоге, вместо того, чтобы спокойно выбрать, из какого ресторана стоит сделать заказ, а у заведений есть ограничения по способу доставки, минимальном заказе и времени их работы, мы делаем огромный пласт блюд со сложным фильтром по этим параметрам, а также по выбору самого ресторана, так ещё где-то нужно указать, что «один заказ — один ресторан». Получается неоправданно сложный интерфейс для пользователя, в угоду тому, что мы убрали карточки ресторана. Фраза «Его цель на этом этапе — максимально быстро и просто выбрать еду, а не сравнивать рестораны.» звучит забавно, ведь, если реализовать такой каталог, пользователю как раз придётся разбираться со сложным фильтром.

Наконец, финальное сообщение от HR выглядело так:

После получения первого сообщения с результатами моемо выполненного ТЗ я закрыл доступ к макету, есть такой момент, однако моя претензия к логике обратной связи, по моему мнению, не требует повторного ознакомления с моим макетом, ведь я задал ровно те же вопросы, о которых писал выше — «Зачем нам убирать карточки ресторанов и делать интерфейс сложнее, а главное — зачем и ради чего? Сделать сценарий на один клик меньше? Но ведь в таком случае мы добавляем, грубо говоря, десяток новых кликов по новому фильтру, который будет необходим. Показать фотографии блюд? Они и без этого показаны в карточках ресторанов.», «Почему дизайнер так уверен, что пользователь, зайдя на сайт, уже твёрдо решил оформить заказ?», «Как мне пересмотреть логику взаимодействия с третьим шагом, если единственный способ его увидеть — оформить заказ?» Ответы на эти вопросы я так и не получил.

Как по мне, здесь возникает конфликт:

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

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

В итоге:

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

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

Даже если вы постарались, сделали UX-исследование, продумали логику, оформили UI и всё расписали — можно получить отказ по формулировке, которая не имеет прямого отношения к задаче. Рынок сейчас — крайне хаотичный. Не всегда дело в уровне, подходе или старании.

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

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

Если вам откликается этот кейс — делитесь своими историями. Таких кейсов, на самом деле, куда больше, чем кажется.