Этот пост, в первую очередь, будет полезен дизайнерам. Но полезные советы найдутся и для других ролей :) 

Тестовые задания, по-прежнему, имеют место в процессе поиска работы. Хоть я и выступаю всецело за whiteboard сhallenge (задание в реальном времени на этапе техсобеса), всё же компании продолжают давать задания «на дом». 

Сегодня говорим именно про такие. Обычно они объёмнее и занимают больше времени. И подвох заключается в том, что разные компании ждут разного подхода к выполнению тестового. 

Например, это тестовое в Яндекс. 

А это — в ТБанк. Очень разные объёмы и суть заданий. 

Вот как можно понять потребности работодателя и правильно выполнить тестовое, разбираем разные ситуации 👇

Например, спроектировать недостающую функцию — сделать чат, подачу заявки или просмотр списка сущностей (тех же заявок). 

Что делать? 

— Изучить продукт 

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

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

— Если нет — смотреть продукты-конкуренты или аналоги. Помним, что пользователь проводит больше времени в других продуктах, чем в одном вашем, поэтому решение должно быть узнаваемое. Такое, как у всех. Оригинальность, когда речь идёт про проектирование UX, неуместна. 

Не путайте: дизайн-система — это огромный инструмент для упрощения работы дизайнерам, разработчикам, тестировщикам и всем остальным.

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

Компоненты в Фигме — это не дизайн-система. 

Если чувствуете, что плаваете в теме, вот список добротных дизайн-систем, советую изучить: 

Так вот, если у компании есть публичная дизайн-система: 

— Если есть библиотека компонентов в Фигме — установите себе и проектируйте, используя эти компоненты. 

— Если библиотеки нет, я рекомендую потратить время и отрисовать компоненты самостоятельности. В точности такие, как в их доке. 

— Важно! Не забывайте прочитать доку по дизайн-системе, лид будет следить за тем, чтобы все компоненты вы использовали верно, в соответствии с их правилами. 

Например, один и тот же компонент Segment Control (внезапно) в одной дизайн-системе используется как аналог вкладок (с некоторыми оговорками), а в другой (не буду показывать пальцем и тем более, рекомендовать эту ДС) — как радиокнопки на форме. 

Как бы то ни было, со своим уставом в чужой монастырь идти не стоит. Особенно на этапе тестового.

Это для меня зелёный флаг — менеджеру важно посмотреть, умеет ли дизайнер мыслить сценариями, а не бросаться сразу рисовать красивые картинки. 

В таком случае всё просто и сложно одновременно. 

— Если владеете одной из нотаций (Userflow в спецификации Taskflow будет проще всего, конечно), используйте её, если не оговорено иное. 

— Если не знаете ни одну из нотаций и ни разу не строили схемы, придётся посмотреть пару туториалов. 

— Не забудьте предусмотреть целевой сценарий (идёт по прямой), альтернативные сценарии (допустим, ответвляются наверх) и негативные (соответственно, вниз) — если есть. 

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

Но есть ещё одна классная нотация, которую просто освоить, и она гораздо информативнее UserFlow. Это DRAKON — отечественное изобретение, очень простое в изучении. Эту схему может прочитать любой, даже не владеющий нотацией, она интуитивно понятна. 

Табу — присылать большой текстовый документ со скриншотами. 

— Наскринить проблемные экраны

— Сложить их в FigJam или Miro (или аналоги)

— Выработать единое аккуратное оформление (например, скрины слева, описание проблемы справа), решение проблемы под скрином

— Аппелировать к существующим паттернам UX, не писать субъективное «мне не нравится» / «выглядит плохо»

— Приложить макет с решением проблемы (да, придется порисовать)

— Если на ваше решение нет устоявшегося закона (Аффорданс, Закон Хика, Закон Фиттса, Бритва Оккама и т.д.) — приложите референсы.

Оптимально — если проблема решена у конкурентов или в близком по назначению продукте. 

Последний пункт универсален, здесь приведу набор действий, которые забывают сделать большинство дизайнеров: 

— Грамотно организуй слои в Фигме, назови все осмысленно и консистентно. 

— Заведи токены для цветов, шрифтов и отступов (рекомендую 8-кратные). 

— Сложи там же все свои локальные компоненты (лучше — варианты), чтобы продемонстрировать технические навыки. 

— Если у компании есть и веб, и мобильное приложение, не забудь показать оба состояния. 

— Запиши презентацию решения — объясни, что ты сделал и зачем. Рекомендую использовать Loom. 

И удачи :) 

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