Как Олег в «Британке» учился, часть вторая

Вторая часть рассказа про учебу в «Британке» на курсе «Дизайн мобильных приложений» (теперь «Дизайн диджитал-продукта») за 2017-2018 год. Он будет интересен всем, кто задумывается о поступлении в «Британку» или просто хоть раз задавался вопросом «как оно там». Первая часть тут.

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

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

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

Я вёл канал, исследовал, рисовал прототипы, ходил на работу — как же все успевать? Как и в любом деле, главное — захотеть. Толчком может послужить злость, как в моём случае: много хотеть, ничего не успевать, злиться на себя и всё-таки делать. Если вы принимаете на себя подобные вызовы (а Британка — это, несомненно, вызов), то нужно вовремя понять, зачем это тебе и идти до конца. Иначе, для чего вообще бросать себе вызов?

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

Середина января, мы приходим на занятия, где нас ждал совершенно новый блок — исследования. Экспериментальный блок на 1,5 месяца, в конце которого полноценная защита с жюри и оценками. Вообще, стоит отдать должное: курс постоянно модифицируется и адаптируется под постоянно меняющуюся индустрию.

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

Преподаватель блока — Алина Ермакова, эксперт в области исследования пользовательских интерфейсов, руководитель отдела исследований пользовательского взаимодействия в Сбербанк Онлайн.

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

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

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

На курсе образовалась определённая традиция распределения проектов. Метод максимально рандомен, но при этом, у тебя остается ощущение, что ты сам всё выбрал.

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

Для нас брифы зашифровали текстами песен. То есть по 1—2 строчкам ты должен был догадаться, о чем идёт речь. Это довольно волнительно. Я поднял руку на фразе «Город-сказка, город-мечта», и тем самым попал в команду, которой досталась тема исследования города. Заказчиком стала «Студия транспортного проектирования», которой требовалась помощь в организации сбора данных на местности.

Пару слов про то, какие брифы еще присутствовали:

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

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

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

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

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

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

К сожалению, несмотря на то, что у нашей команды все получилось, многие, так или иначе, не справились и остались недовольны; эксперимент с внедрением блока исследования в рамках курса так и не взлетел. Возможно причина в плохих брифах, возможно в том, что всем хотелось работать над UI и поскорее приступить к отрисовке интерфейса. Но некоторые брифы не подразумевали в своем решении наличия какого-то цифрового продукта, ребятам приходилось снимать ролики, придумывать листовки и так далее. Многие просто хотели рисовать, а их заставляли проводить интервью с людьми. В общем, негативных отзывов было больше, чем позитивных, и поэтому в следующем учебном году вместо исследования студенты стали делать проекты на международные конкурсы. Один из таких проектов, кстати, увенчался выигранным RedDot-ом. Как по мне, реддот это конечно круто, но навыки исследования, полученные в ходе этого блока, я активно использую каждый день, и во многом благодаря им меня взяли на текущую работу.

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

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

Напомню, что озвучиваются приблизительные описания проектов, при этом неизвестно, что будет дальше; желающие поднимают руки, набирается команда и так далее. Я попал на бриф от Profi.ru, так как прозвучали слова о сервисе для людей и о необходимости создания нового визуального языка. Мне показалось это интересным. Список заказчиков для общего понимания всех вариантов: Qlean, Билайн, Revolut, SkyEng, CosmoZoo, Apas Monolith, Geobeat.

Первые несколько занятий по продукту вновь провёл Саша Мемус (подробнее о нем в первой части). Саша запомнился своей энергией и запалом сделать все не как обычно: с играми, постоянной обратной связью и небольшими призами. Так что Сашу все ждали, и вот — блок продукта!

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

Два занятия с Сашей закончились рэп-баттлом между командами. Да-да, в рифму и с панчами! Нужно было сначала обыграть тему своего проекта, а потом раскатать проект оппонента. Было супернеобычно и весело. Кроме веселья, смысл был в том, чтобы команды обратили внимание на конкретные колкости в адрес своего проекта, услышанные панчи могут быть потенциальными местами, на которые стоит обратить внимание при исследовании.

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

Мы продолжили исследовать и погружались в проект с Женей Бондаревым, креативным директором Redmadrobot. Каждое занятие он проводил игры на развитие креативности, а также рассказывал про дивергентное мышление, модель двойного алмаза, «пять почему» и т.д. Про это можно прочесть на моем канале.

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

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

Имея список фич и примерное представление того, в какую сторону хотим двигаться мы, тем не менее, валидировали их еще довольно долго — только в конце следующего блока (UX) отбросили все лишнее и сконцентрировались на одной конкретной проблеме. Можно сказать, что нашей команде повезло и у заказчика была довольно очевидная проблема, но далеко не всем удавалось найти точку опоры и вплоть до самого финала некоторые то и дело откатывались к началу.

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

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

Для того, чтобы разобраться во всех особенностях сервиса мы попробовали сами стать специалистами, рассмотрели конкурентов и пообщались с пользователями.

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

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

Углубляясь в поиск решения встает вопрос — а в каком месте нужно остановиться? То есть, как понять какие ограничения у нас есть и какую конечную цель мы хотим достигнуть?

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

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

Сначала мы сделали макеты под роль дизайнера-фрилансера, который ищет заказы через Профиру. Но когда спросили заказчика — какая самая массовая аудитория специалистов, он ответил, что репетиторы, мастера по ремонту и мастера красоты. Получается, что правильно было бы выбрать один из этих типов специалистов. Так мы и сделали, переделав все макеты под роль мастеров ремонта, потому что в их кейсе встречается максимальный набор элементов — и карта, и шаблонные данные (площадь стяжки, тип пола), и текстовое описание заказа.

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

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

Мы хотели внедрить в ленту с заказами бесконечное пролистывание — попадая в карточку заказа и долистав её до конца можно продолжить скролл и тем самым закрыть карточку, вернувшись в ленту.

Вот как это работает:

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

Мы показали ей концепт с бесконечным скроллом, задали несколько вопросов. Она посмотрела на остальные макеты и… перевернула всё с ног на голову!

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

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

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

Исследования и UX у нас получались довольно неплохо, и вообще, процесс шел налажено и гладко — мы изучали продукт и генерировали решения. Когда подошли к блоку UI, я был готов заниматься только этим и не отвлекаться на проработку UX или продуктовые идеи, как в первом семестре. Я думал, что все так же гладко и продолжится, но не тут то было...

В этот раз UI вел не Сергей Гальцев (куратор курса, подробнее в первой части), а Женя Бондарев. Хотя формализовано это не было, в какой-то момент по визуальному языку мы общались с ними обоими.

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

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

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

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

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

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

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

На практике же количество преподавателей ограничено, количество присылаемых макетов огромно, в итоге — объем обратной связи минимален.

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

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

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

Но однажды я все же получил небольшое пояснение этого термина. Одним вечером, после занятий, я решил спросить Сергея (автора этой фразы), что же делать, когда ничего не получается? Он поделился своим опытом — когда ничего не получается, можно начать решать проблемы постепенно, брать какую-то одну небольшую часть проекта — например, контрол, и доводить его до совершенства. То есть фокусируешься на одном элементе, не отвлекаясь ни на что больше. И… постепенно «дожимаешь» весь проект.

На зачете Женя Бондарев должен был выбрать одну из наших трех UI-концепций. Но так как они были одинаково плохи, Женя посоветовал смешать несколько идей из каждой. На этом его активное участие в обучении закончилось. А мы остались один на один с сырым UI, и тут же стали его переделывать. Все майские праздники я провел за работой над UI. Это время не прошло зря, я открыл для себя много нового и из зачаточных мои навыки стали чуть более крепкими.

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

Какое-то время мы варились сами в себе, пока не поняли, что все это зашло слишком далеко и нужно спасать положение. Тогда я забил тревогу, и мы с командой активизировались. Мы собрались в одном чатике с Сергеем и Женей и решили начать все с самого начала. Откатились до мудборда и ключевых слов, чтобы таким образом синхронизироваться и начать грести в одном направлении.

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

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

У нас этого не произошло, и на это было две причины.

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

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

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

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

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

Вот несколько мыслей про защиту в Британке, которые я понял на своем опыте.

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

Второе, нужно максимально упростить повествование не уходя в детали, потому что на выступление дается всего 10—15 минут. Было непросто выбрать логику повествования, ведь рассказ должен понять даже ребенок, а когда работаешь над проектом полгода, сложно выкинуть какие-то части, но чтобы вас поняли, это сделать необходимо. Мы выбрали одну большую боль пользователя и обернули её в историю: от момента, когда он сталкивается с проблемой, до её решения. Одна проблема — одно четкое решение, тогда вас точно услышат и осознанно оценят.

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

Правда, все эти советы касаются исключительно выступления в Британке.

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

Перед защитой всегда очень переживаешь, так как относишься к этому со всей серьезностью. Когда мы готовились к защите, то чувствовали себя аутсайдерами из-за того, что долго и сложно работали над UI. Но по мере подготовки презентации я понимал, что у нас получается крепкая история. Так и вышло, пятёрку получили только две команды: мы и Qlean — нас оценили в первую очередь за то, что мы осознанно попытались решить боль пользователя. Вы можете сами оценить наш кейс, который сверстан практически в точности по сценарию рассказа презентации.

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

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

Думаю, причины такого перевеса в сторону визуала кроются в истории курса. Многие из преподавателей так или иначе работают в агентствах и студиях, где важно поддерживать высокий уровень визуала. Хоть курс и обновляет программу каждый год и стремится быть на одной волне с индустрией (например, внедряя блок по исследованиям), основной упор все равно отдается картинке. Отказ от блока исследования в следующем учебном году (2018—2019) подтверждает это.

Подобный подход — это неплохо, просто он не всегда объективен. Во всяком случае, я не считаю, что продукт не должен выглядеть эстетично, я рад, что Британка заразила меня желанием (или комплексом) стремиться улучшать свой UI, и жалко, что за время учёбы я не так сильно прокачался в этом, как хотелось бы.

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

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

Это чувство жило со мной практически год, пока на текущей работе я не осознал, что справляюсь со всем, что для меня важно, и UI в том числе. Вывод — не стоит забываться и думать что кто-то (даже мастодонты индустрии) знает — как правильно; всегда нужно прислушиваться к себе и фильтровать, что близко и должно остаться, а что лучше принять как рекомендацию и оставить в стороне.

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

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

Сейчас я работаю в hh, и мне все дико нравится. Мы развиваем мобильное приложение и за это время проделали большую работу. Полученные знания позволяют быть в курсе основных трендов, и особой разницы с тем, что я делал на курсе, и чем занимаюсь на работе — нет. Я так же активно исследую, тестирую гипотезы и общаюсь с пользователями, только теперь у меня есть доступ к аналитике, мнению разработчиков и бизнеса. Здорово, что в компании у дизайнеров есть возможность активно влиять на то, как будет развиваться продукт. А из-за того, что у меня был пунктик по поводу UI, я с особым трепетом отношусь к эстетичности своих решений. Трудно остановиться на первом пришедшем в голову решении, когда внутри меня голос все еще повторяет: «Еще чуть-чуть, и точно «дожмешь»».