Не просто красиво

С чего начать делать тестовое, чтобы не обосраться

У тестовых заданий есть неприятная особенность: иногда хочется сразу открыть фигму и начать что-то рисовать, чтобы почувствовать, что процесс пошёл. Но обычно именно так и начинаются проблемы) Я бы начинала не с макетов, а с подготовки.

1. Внимательно прочитайте ТЗ
Да, звучит как совет из разряда “пейте воду и спите 8 часов”, но правда.Чаще всего в ТЗ уже есть почти всё, что нужно: проблема, контекст, ограничения, метрики, на которые будут смотреть, иногда даже макеты или текущий сценарий. И если это не заметить на старте, можно очень красиво решить вообще не ту задачу.

2. Если чего-то не хватает — спрашивайте
Если в задании есть непонятные места, лучше сразу собрать вопросы списком и отправить рекрутеру. Да, вам могут не ответить. Или сказать что-то в духе: “тут можно пофантазировать, нам интересно посмотреть, как вы рассуждаете”. Но часто недостающую информацию всё-таки досылают. И делать тестовое становится как минимум проще, потому что вы перестаёте гадать на кофейной гуще.

3. Не бегите сразу рисовать финальные макеты
Сначала соберите структуру страничек, чтобы лид или дизайнер, который будет смотреть тестовое, не бегал по файлу в попытке понять, куда смотреть. Понятная структура очень помогает: человек сразу видит, где задание, где финальные макеты, где анализ, где ход работы, а где компоненты. Например, можно сделать так:
задание / финальные макеты / анализ / ход работы / компоненты / обложка. Это не значит, что структура должна быть именно такой. Но файл должен читаться без ощущения, что человек попал в свалку.

4. Не забудьте про обложку
Когда отправляете ссылку на Figma, в миниатюре лучше видеть нормальную обложку, а не миллион маленьких квадратиков.
Это мелочь, но она сразу делает работу собраннее.

5. Выпишите цели пользователя и бизнеса
Перед тем как рисовать, попробуйте понять: что нужно пользователю, что нужно бизнесу, где эти цели пересекаются. Потому что хорошее решение обычно живёт именно на этом пересечении, а не просто в зоне “я сделала красивый экран”. Это один из важных этапов, который даст вам вектор развития решения.

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

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

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

Мой путь в бигтех начался с тестового за 6 часов

Со стороны карьерный путь часто выглядит сильно логичнее, чем он был на самом деле. Типа: человек такой сел, собрал портфолио, попал в нормальную компанию, потом в бигтех, потом ещё куда-то. Всё красиво, всё по плану.У меня было не так)

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

Потом в универский чат скинули стажировку в Студию Лебедева.
Я открыла тестовое, села и сделала его за 5–6 часов. Без большого плана, без мысли “сейчас я разнесу всех”. Просто сделала и отправила, особо ни на что не надеясь.И меня позвали.

Дальше начался отдельный аттракцион: я работала в студии с 10 утра до 8 вечера, а сессия была очная почти всегда. То есть днём ты как будто взрослый дизайнер, а потом внезапно у тебя экзамен и желание лечь лицом в стол) После стажировки меня позвали работать дальше, потому что я схватилась за шанс попасть в ряды дизайнеров любой ценой и студия очень помогла мне на старте.

Не только из-за имени, хотя будем честны: имя тоже сыграло роль. Лебедева знают, и на собеседованиях этот опыт сразу считывался как “окей, человек уже видел реальные задачи, клиентов, сроки и правки”. Но в какой-то момент я поняла, что хочу уйти в продукт.

В бигтех меня сразу не брали, поэтому я ушла на удалёнку в продуктовую компанию поменьше. Это было уже ближе к выпускному году, когда нужно было писать диплом, так что удалёнка оказалась очень кстати) И это было правильное решение. Потому что там появились реальные продуктовые задачи: сценарии, пользователи, разработка и решения, которые нужно не просто красиво нарисовать, а объяснить и довести до жизни.

После этого меня взяли в Яндекс Лавку. Потом был Т-Банк. Сейчас я работаю продуктовым дизайнером в Альфа-Банке.

Если коротко: я не попала в бигтех через один идеальный маршрут.
У меня был путь через универский чат, тестовое за 5–6 часов, стажировку, студию, компанию поменьше и только потом большие команды.

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

В общем, не обязательно сразу родиться дизайнером из бигтеха)
Можно зайти постепенно. Главное — собирать опыт, кейсы и навык нормально объяснять, что вы вообще делали.

А дизайнеру вообще обязательно учиться на дизайнера? Мне кажется, это один из частых страхов у тех, кто хочет в дизайн. Если нет профильного образования — меня не возьмут? Если есть — я автоматически классный дизайнер? Спойлер: нет и нет)

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

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

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

Её часть можно почитать тут 🙂

Зачем я хожу на конференции

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

Я воспринимаю дизайн не только как работу 5/2. Я понимаю, что творчество в целом присутствует в моей жизни на постоянной основе. Я люблю творить руками или посещать красивые места, чтобы черпать вдохновение.

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

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

Есть у меня мечта когда-нибудь так же рассказывать на сцене о своём опыте и делиться знаниями. Аминь)

Ходите почаще на такие тусовки и делайте крутой дизайн.

Я люблю задавать тупые вопросы

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

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

В продуктовом дизайне может казаться, что всё достаточно просто: просто взял и нарисовал макеты. Но только если дизайнер не до конца разобрался в проблеме, спустя время оказывается, что такой дизайн не соответствует ТЗ, сроки горят, а разработчики вообще разводят руками и говорят, что не могут так сделать.

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

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

Так что мой совет всем: не стесняйтесь задавать вопросы, даже если они кажутся глупыми или неправильными. Иногда правда окажется, что вы просто не знали контекст. А иногда окажется, что контекста не знал никто)

А ещё лиды суперположительно относятся к вопросам на стартовых этапах, так как это показывает, что человеку не всё равно на работу, которую он делает.

Как я подхожу к решению любой задачи

Раньше у меня была проблема: в голове отложился паттерн, что дизайнер — это человек, который просто что-то рисует. Типа «рабочие руки». И, придя в Яндекс Лавку, я столкнулась с тем, что рисовать по 10 концептов одного и того же блока уже не работает. Надо подходить к задаче более системно. После разговора с лидом я получила краткий план по пунктам, как решать любую задачу, чтобы потом не приходилось всё переделывать заново.

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

Какую задачу мы сейчас решаем?

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

Откуда мы вообще знаем о проблеме?

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

Как мы поймём, что решение хорошее?

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

Какие есть ограничения?

Технические, временные, юридические — да вообще любые. Чтобы не получилось так, что я сделала макеты, потом приходит юрист и говорит: «Нет, мы так не можем, надо переделать».

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

Что это значит? Я не раз сталкивалась с тем, что делаю какую-то задачу в конкретном блоке, а потом оказывается, что он уже выглядит по-другому, просто макеты в Figma не те. Поскринить прод занимает 5 минут, но бережёт вас от срывного нерва)

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

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

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

Именно это отличает классного продуктового дизайнера от дизайнера, который просто работает руками.

Cобрала небольшую подборку дизайн-вакансий от стажёра до мидла в российских бигтехах и финтехах.

Т-банк мидл - супер классная возможность прокачать продуктовые навыки и поучаствовать в исследованиях

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

Озон - тут ищут дизайнера дизайн системы, вдруг кому-то интересно

Альфа - ищут дизайнера в B2B

Стажер в Сбер - тут ищут коммуникационщика

Стажеры в Авито - стартовал набор стажеров в Avito Bootcamp

Сбер - ищут продуктового диза в гигачат

Если что-то откликается — лучше открывать сразу, потому что дизайнерские вакансии исчезают быстрее, чем кажется)

В Альфу я могу зарефералить, если увидите подходящую вакансию — можно написать мне, скинуть ссылку на неё и резюме + портфолио ❤️

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

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

В реальности у него отлетел инет, не прошла карта, товар закончился за секунду до покупки, он ввёл имя на 48 символов итд

И интерфейс не должен бросить пользователя в самый не подходящий момент.

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

Обычно всё ломается именно там, где кажется: «ну так точно никто не сделает»)