Колонки

Нужен ли UX/UI-дизайнеру хакатон?

Колонки
Алексей Комаров
Алексей Комаров

UX/UI-дизайнер в IBM

Алина Алещенко

Алексей Комаров, UX/UI-дизайнер в IBM, регулярно участвует в хакатонах с 2017 года. Он неоднократно занимал призовые места, а сейчас выступает на подобных мероприятиях членом жюри и ментором. Как выбрать хакатон, какой тактики придерживаться и как повысить шансы на победу? Своим опытом Алексей поделился в колонке для RB.RU: он будет интересен тем, кто тоже хочет попробовать свои силы в хакатонах.

Нужен ли UX/UI-дизайнеру хакатон?

Несмотря на название, хакатоны нацелены не только на «хакеров» и разработчиков, но и на других представителей IT-индустрии, в том числе на аналитиков, менеджеров и дизайнеров. Как вы уже поняли, мне ближе последнее направление. 

Победа на хакатоне ВТБ More.Tech в октябре 2020

Эксперт в составе жюри на хакатоне Pandemic Data Hack в декабре 2020

 

Ради чего все это

Наверное, здесь не будет уникальных пунктов – мотивация дизайнера мало чем отличается от мотивации других специалистов:

  • заработать деньги;
  • проверить себя;
  • познакомиться с новыми людьми;
  • найти работу;
  • сбежать от рутины;
  • проект в портфолио.

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

С другой стороны, дизайнеры обычно избегают хакатонов, потому что:

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

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

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

 

«С самого начала у меня была какая-то тактика и я её придерживался»

Хакатон не требует от вас готового продукта, который завтра же можно выпускать на рынок. Основная цель данного мероприятия – создать MVP, минимальную версию продукта для демонстрации и проверки идеи.

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

 

Подготовка

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

При подборе обращаю внимание на следующее:

  • сроки проведения;
  • формат;
  • дату окончания регистрации;
  • задачи и предметная область;
  • состав жюри.

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

Если мероприятие очное, но в другом городе – оно тоже не подходит по причине, описанной ранее. Мне больше по душе онлайн-формат, хоть из-за него и утрачивается атмосфера хакатона. 

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

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

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

Даже если формулировка задачи полностью не представлена на сайте хакатона, там будет примерная тематика, например – корпоративный банкинг или сохранение окружающей среды. Мы начинаем анализ предметной области. Гуглим все, что можно найти: оценка рынка, отчеты, удачные и неудачные стартапы и т.д.

Последним пунктом выступает анализ экспертов, ниже пример двух хакатонов: Сбер Еаптека и Moscow City Hack. По сайту хакатона Еаптеки видно, что в составе жюри представители разработки, а это значит, что код точно будут смотреть, и сильно костылить не получится, это может повлиять на оценку.

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


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

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

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

По правилам хакатона нельзя приходить с готовым решением, но ничто не запрещает настроить инструменты. Как дизайнер я стараюсь заранее найти стилистические референсы и создать базовый UI-кит (кнопки, поля ввода, иконки и т.д.), чтобы не тратить на это время в рамках самого хакатона, а собирать макеты из готовых блоков, как из лего.

Разработчики также готовят своё окружение: настраивают сервер, заводят компоненты в код, проектируют базовую архитектуру приложения. 

 

Процесс решения

Как я уже писал ранее, основная цель хакатона – это MVP. После того как начался хакатон, мы сохраняем продуктовый подход: рынок известен, референсы найдены, пора накидывать варианты решения.  

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

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

Первый чекпоинт может быть вечером в день выдачи задания или на следующее утро. До этой встречи в кругу команды мы обсуждаем вводные, предлагаем идеи и начинаем проектировать структуру будущего приложения. Обычно все это происходит в https://miro.com или https://figma.com.

На чекпоинте есть 5-10 минут, чтобы задать вопросы ментору и показать, что сделали. Обратная связь от ментора поможет понять, все ли мы учли и правильно ли в целом выбрали направление решения. 

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

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

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

 

Питчинг

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

Для питча лучше выбирать того, кто умеет хорошо складывать слова в предложения и делает это быстро, так как время ограничено – за 10 минут нужно успеть показать всё, что сделали за 48 часов. Часто таким человеком выбирают именно дизайнера, так как он уже привык постоянно презентовать свои решения в обычной жизни.

Один из моих первых питчей 

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

 

Итог

Хакатон не сложнее обычной рабочей задачи. Шансы на победу возрастают, если понять общие правила:

  • Подготовьтесь заранее – найдите референсы, настройте инструменты, погуглите предметную область;
  • Решайте задачу поэтапно, ставьте себе промежуточные дедлайны;
  • Не гонитесь за количеством идей, работайте над качеством. Лучше хорошо проработать 1-2 сценария, чем пытаться сделать всё приложение за 2 дня;
  • Не забывайте веселиться, погрустить можно и на работе :) 
Фото на обложке и иллюстрации предоставлены автором.

Нашли опечатку? Выделите текст и нажмите Ctrl + Enter

Материалы по теме

  1. 1 Что такое внутреннее предпринимательство и как развивать его с помощью хакатонов?
  2. 2 Хайп вокруг цифровизации: почему не все стратегии digital-трансформации работают
  3. 3 Стартап, который построил корпорат: инструменты развития внутреннего предпринимательства в компании
  4. 4 «Кружковое движение» НТИ и Wordskills Russia организовывают хакатон по анализу больших данных для студентов
  5. 5 Кружковое движение НТИ и аэропорт «Пулково» проведут хакатон для школьников и студентов