Привет! Я Владимир Белов — продуктовый дизайнер в Group-IB.
Веду телеграм-канал «Заметки дизайнера» , где делюсь полезными ссылками, интересными продуктами для собственного анализа
и статьями.

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

Давай представим, что тебе на почту написал HR из SpaceX, и в ходе переписки от тебя потребовали сделать тестовое задание для приема на работу. В нем потребовалось спроектировать интерфейс по управлению и отслеживанию параметров корабля Dragon. Но может прилететь и проект по проектированию интернет-магазина по продаже мужских стрингов. Безусловно, это два разных проекта, как и по времени, так и по объему. Но весь тезисный процесс проектирования и отправление на ревью — одинаковый.

Задача спроектировать интерфейс, где скорее всего будет короткое ТЗ, без материалов, без структуры, без контента. Почему? Потому что заказчик проверяет вас: на что вы способны, насколько вы мыслите, насколько правильно решаете те или иные задачи.

Составляем мудборды, собираем референсы

Самое простое начало любого проекта — мы начинаем с поисков референсов dribbble, behance, producthunt и т.д.. Чаще всего что-то да находим, но я советую на этом этапе всегда искать и в смежных областях, так как вы расширяете свой кругозор решений, умение в построении нового подхода. Это может быть автомобильная тематика: у Range Rover большой дисплей по отслеживанию технических характеристик автомобиля, bmw, tesla — это то, что приходит мне на ум. Также могут быть промышленные интерфейсы, которых тоже достаточно в интернете. Кроме этого, вы не только прокачиваете свое визуальное и ux-решение, но и старайтесь понимать, что эти референсы могут поспособствовать вашей аргументацией.

Разбор задания

Как я и сказал, чаще всего в нем пару предложений. В моем примере пусть будет, что требуется отображение скорости, давления, температуры корабля. Но нигде не указано, что вы можете добавлять от себя что-либо. Допустим, отображение работоспособности всех 16 двигателей, на каких оборотах они крутятся и умение контролировать и задавать количество оборотов. Думаю этого достаточно. Почему это важно? Умение выходить из рамок требований и думать наперед, думать о пользователях — это также является нашей работой.

Original https://www.spacex.com/vehicles/dragon/

Отсутствие материалов

Гибкость и умение выходить из положения — это очень сильно ценится. Даже если у вас нет подходящих визуальных материалов для использования внутри вашего интерфейса или сайта. В моем случае я не знаю, каких размеров экран для отображения интерфейса, я не знаю, как выглядят запчасти корабля для отображения их состояния. Да, это сложно, но в эти моменты вы должны забыть про сток и сделать это будто у вас все необходимое в руках. Я не знаю размеры экранов? Пускай будут 2 дефолтных планшетных экрана и один кастомный, например, горизонтальные часы на руках космонавтов. У меня нет запчастей? Я найду приблизительные 3Д модели и отрендерю их. Ты не умеешь это делать? Тогда нужно в кратчайшие сроки узнать, как это сделать, либо отрисовать их в иллюстраторе. Самое главное это показать в интерфейсе.

Author https://www.artstation.com/artwork/XBrP6L

Lorem Ipsum

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

Взял пример из Figma Community

«Ну, короче, вот так. Я художник, я так вижу»

Это грубый пример дизайнера, который спроектировал интерфейс, ты его спрашиваешь “почему ты так решил?”, в ответ получаешь “Ну это ну как бы вот мне нравится”. Это означает, что дизайнер не углубился в проект, не изучал его, проектировал основываясь “красиво и гуд”, не обладает аргументацией. В этом случае вам поможет только изучение проекта, продукта, над которым вы собственно работаете, после этого исследуете решение у конкурентов, в смежных областях, выписываете, запоминаете, как хотите. Каждое ваше решение должно аргументировано проектироваться.

Заключение

В конце выделю очень важный пункт: каким образом отдавать тестовое задание и чего избегать.

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

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

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

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

Сайт • Инстаграм • Телеграм-канал • Ютуб-канал

Подкаст «Заметки дизайнера»:
Apple Podcast • Яндекс.Музыка • Google Podcasts