Привет! На связи продуктовая команда PixelPeak. В статье расскажем подробно, как собралась наша команда, почему решили сделать сервис онлайн-музея ЗИЛ, какие исследования проводили, с какими сложностями столкнулись и многое другое. Кейс будет полезен тем, кто хочет знать, как ведётся работа над проектом в диджитал-студиях.

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

Время идёт вперёд, старое заменяется новым, и многие смирились бы с этим, но только не Настя! Она написала в своём телеграм-канале, что собирает команду на некоммерческий проект — те, кто откликнется, станут сотрудниками её студии на время проекта. В условиях найма были ответственность, постоянство, желание учиться и слушать руководителя. Коммерческий опыт не требовался, подходили знания UX/UI, полученные после прохождения курсов. Откликов ожидалось 5-7, а в итоге получилось больше 20, поэтому кроме фестивального сайта решили делать продуктовый сервис.

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

Так, в апреле 2024 года стартанул некоммерческий проект «О, давай сделаем!», началась работа над продуктовым сервисом для музея ЗИЛ и фестивальным сайтом, о котором мы расскажем в следующих статьях.

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

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

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

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

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

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

Вот пример, как выглядело начало нашего интервью:

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

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

Вот что получилось у Игоря после сжатия:

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

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

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

Подробно ознакомиться с результатами опроса можно по этой ссылке.

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

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

Фичей мы придумали много. Но реализация некоторых из них будет неоправданно дорогой в разработке.

Чтобы не тратить время на такие фичи, мы использовали метод приоритезации ICE (Impact, Confidence, Ease) scoring. Он показывает, какие идеи нужно реализовать сначала, какие можно сделать позже, а про какие можно вообще забыть.

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

После всех исследований Игорь сформировал из участников три команды: Terra, Aurora и Stella, каждый из которых свою роль terra — главная страница и онлайн-музей, aurora — весь процесс покупки и stella — оффлайн сегмент (страницы маршрутов, экскурсоводов, экспонатов). Далее лиды составили информационную структуру сервиса, чтобы понять, какие на сервисе будут страницы и определить объем работы. Затем согласовали структуру с Игорем, и все три команды приступили к созданию вайрфреймов.

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

На этом же созвоне Игорь расформировал команду Terra, потому что один из её членов не принимал участия в работе. Выяснилось, что вайрфреймы в этой команде составляли втроём, чтобы успеть к дедлайну (в этом помогал лид, хотя он не должен был заниматься другими задачами). Участников Terra распределили между командами Stella и Aurora.

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

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

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

Мы начали экспериментировать, пробовать разные цвета, шрифты и согласовывать с Настей. Через несколько дней мы предоставили 9 концепций, из которой одна была выбрана и согласована.

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

Игорь провёл созвон, на котором подробно объяснил нюансы разработки UI-кита, разбирал ошибки. Мы решили выделить под это дело отдельного человека (потому что когда за работу отвечают все, в итоге не отвечает никто). Один из лидов, Камиля, вызвалась на эту задачу (что не освобождало её от обязанностей лида).

Когда Настя утвердила главную страницу и каталог экспонатов, Камиля приступила к разработке UI-кита, и начала со шрифтов. Она поместила все шрифты, которые были использованы, на отдельную страницу, чтобы выявить паттерны использования и таким образом «схлопнуть», то есть уменьшить варианты использования шрифтов.

Например, были «схлопнуты» начертания (Bold и Black) и размерность, где шрифты отличаются на несколько пикселей. Затем Игорь проверил работу и «схлопнул» решения ещё сильнее. Камиля беспокоилась о том, что мы будем недовольны таким результатом, т.к. на подбор шрифтов уходило много времени, было много вариантов, а в результате осталось несколько начертаний.

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

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

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

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

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

Лиды поделили работу, и мы приступили к проработке сценариев. Где-то было легче (например, на странице о музее), где-то сложнее. Страница покупки предполагала более детальный и сложный сценарий, там мы не уходили вглубь — остановились на проработке самого базового.

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

После того, как сценарии были проработаны, мы сделали интерактивные прототипы для тестирования. Каждый участник тестировал страницу своего коллеги, а не ту, которую разрабатывал сам (это было сделано для того, чтобы избежать субъективности). Для проведения тестов на одну страницу нужно было найти 5 человек, и прогнать их по определённому сценарию.

По итогу у нас появились данные, по которым можно было сделать выводы о том, где и как улучшить пользовательский путь. Внедрять их мы, конечно же, не стали :) Цель была разработать MVP, а этап тестирования нужен был чтобы задать вектор на развитие онлайн-сервиса музея ЗИЛ.

Мы разработали MVP сервиса-музея, который стоит на крепком фундаменте, и в нём построено не одно здание, а целый город! Ознакомиться с «планом строительства» можно по ссылкам на Dprofile и Behance — заходите, смотрите, исследуйте, оставляйте отзывы, мы обязательно вам ответим. Если у вашей студии есть ресурсы сверстать проект по нашим чертежам — пишите Анастасии Красовской.

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

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

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

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