Привет! На связи продуктовая команда PixelPeak.
В статье расскажем о том, как собралась наша команда, почему решили сделать сервис онлайн-музея ЗИЛ и о том, как проходила работа над сервисом. Раскроем подробно, как мы прошли все этапы разработки, как велась коммуникация в команде. Кейс будет полезен тем, кто хочет знать, как ведётся работа над проектом в диджитал-студиях.
Коротко об идее. Некоммерческое начало
Наша история началась в конце марта 2024 года. Настя Красовская, основатель диджитал-агентства PixelPeak, переехала с семьёй в арт-квартал ЗИЛ. Каждый день, когда она выходила на прогулку, появлялись сожаления о том, что когда-то давно на этом месте был легендарный завод ЗИЛ, а теперь от него ничего не осталось: память о нём постепенно стирается, а истории о великих подвигах героев уходят в небытие.
Время идёт вперёд, старое заменяется новым, и многие смирились бы с этим, но только не Настя! Она написала в своём телеграм-канале, что собирает команду на некоммерческий проект — те, кто откликнется, станут сотрудниками её студии на время проекта. В условиях найма были ответственность, постоянство, желание учиться и слушать руководителя. Коммерческий опыт не требовался, подходили знания UX/UI, полученные после прохождения курсов. Откликов ожидалось 5-7, а в итоге получилось больше 20, поэтому кроме фестивального сайта решили делать продуктовый сервис.
Предложение было выгодно для обеих сторон: Настя получала команду для реализации сервиса, а мы, участники проекта — опыт работы в студии + обучение от фаундера. Собралось более тридцати человек, мы разделились на команды в зависимости от роли, которую хотели выполнять в проекте (разработка фестивального кейса, продуктового сервиса, копирайтинг, пиар).
Так, в апреле 2024 года стартанул некоммерческий проект «О, давай сделаем!», началась работа над продуктовым сервисом для музея ЗИЛ и фестивальным сайтом, о котором мы расскажем в следующих статьях.
Подробно о реализации. Управление процессами в команде
Настя занялась фестивальной командой, а управление продуктовой передала Игорю Шульге, продуктовому дизайнеру из Т-банка. В продуктовой команде нас было 12 человек (до конца дошли 11 — неплохой результат для некоммерческого проекта).
Разработка сервиса длилась почти полгода: мы проводили качественные и количественные исследования, составляли гипотезы, продумывали джоб стори и фичи, отрисовывали вайрфреймы, подбирали референсы и создавали визуальные концепции (первая, кстати, не зашла, но обо всём по порядку).Работа велась недельными спринтами по плану разработки, где были видны все этапы. План работы был реализован в Notion, в этом же сервисе мы выкладывали результаты исследований и другие материалы, необходимые для разработки. Позже у нас появился свой wiki, где находились полезные статьи, видео и книги.
Процесс работы был выстроен как при работе с клиентами в студии, поэтому, кроме графиков и дедлайнов, у нас был заполненный бриф. После брифа мы поделились на команды, и Настя назначила лидов — они менеджерили процессы в своих командах, приводили данные в порядок и помогали участникам, когда возникали сложности. Участникам нужно было отвечать только за свою часть работы.
Основная задача сервиса онлайн-музея —зарабатывать деньги. Нам предстояло разобраться, за счёт чего генерировать прибыль, и мы приступили к исследованиям.
Качественные вопросы и объединение смыслов
Нам дали задание провести качественное исследование (интервьюирование). Для того, чтобы получить больше данных, к нам подключились девять человек из фестивальной команды и копирайтер Аня Казакова. Она живёт в США, и у нас большая разница во времени, но это не помешало подготовить материалы к созвону. Ниже Аня рассказывает, как ей это удалось.
На созвонах Игорь, лид продуктовой команды, обучал нас правильному подходу к исследованиям. Например, чтобы качественно провести интервью, он советовал пользоваться «методом пяти почему». Игорь очень живо и интересно рассказывал, приводил много примеров, а мы делали заметки в тетрадях во время созвона, чтобы ничего не забыть.
Вот пример, как выглядело начало нашего интервью:
Привет, (имя)! Меня зовут Камиля, и я занимаюсь исследованием (на тему …). Спасибо, что согласились побеседовать. Наш разговор займёт не более 30 минут. Дам немного вводной информации: 1) вся наша беседа конфиденциальна, а итоги будут максимально обезличены; 2) не существует правильных и неправильных ответов. Постарайтесь отвечать честно, искренне. Для начала, познакомимся: расскажи немного о себе, откуда ты, чем занимаешься?
Каждый опрашивал как минимум двух респондентов: того, кто посещает музеи, и того, кто в них не ходит. Интервью брали у знакомых и незнакомых людей, и даже у музейных работников. Данные вносили в таблицу, а лиды собирали из ответов саммари. На этом этапе начались сложности: Игорь говорил всем делать стикерами, один из лидов решил написать текстом. «В результате мы немного упоролись на созвоне, но всё-таки объединили ответы по смыслам», — вспоминает одна из участниц проекта. Вот так выглядело наше саммари:
Игорь сказал, что информации очень много, и можно её сильно сжать. Вот что получилось у Игоря:
На этом этапе фестивальная команда отделилась, и работа велась только внутри продуктовой. В саммари мы выявили основные барьеры при посещении музеев, и приступили к формированию гипотез, чтобы найти оптимальные решения. Например, человек не ходит в музей, потому что не с кем. Мы сформировали гипотезу, что если добавить блок «вступите в наш чат», то соберётся компания по интересам, и проблема решится.
В процессе мы также придумывали вопросы, которыми можно было подтвердить или опровергнуть гипотезы, после чего лиды составляли опрос из этого списка для тестирования гипотез.
Основные правила составления опроса, которыми руководствовались в нашей группе:
- Рассчитать необходимое количество респондентов
Составить качественные вопросы:
- один вопрос — одна тема
- простые и логичные
- объективные, без давления на респондента - Продумать варианты ответов, которые можем получить
- Проработать стилистику:
- понятная, живая речь без жаргона
- задавать вопросы от второго лица, отвечать от первого
- вопрос и ответ должны складываться в диалог
- формулировки должны быть универсальными, не привязанными к половой принадлежности респондента.
Опрос был составлен таким образом, что каждый вопрос тестировал одну из гипотез. После получения результатов мы составили список подтвержденных гипотез, затем поделили их между командами и приступили к разработке джоб стори и фичей.
Подробно ознакомиться с результатами опроса можно по этой ссылке.
Мы выбрали формат Job stories, потому что они смещают фокус с характеристик пользователя на ситуацию, в которой у него возникает потребность воспользоваться продуктом. Таким образом, главное значение приобретает то, какую ценность услуга может предоставить потребителю, а не его личные интересы или образование.
Когда [описание ситуации] — Я хочу [мотивация] — Чтобы [результат]
Например, у нас появилась стори «я, как посетитель музея хочу покупать воду, потому что мой ребенок часто хочет пить» или «когда я, как учитель начальных классов иду вместе с учениками в музей, я хочу иметь возможность организовать групповую экскурсию, чтобы я и каждый ученик имели льготный билет». На основе них формируем функции (фичи), делаем список необходимых фич. Далее на их основе формируем архитектуру сайта и проектируем, где что будет располагаться.
Фичей мы придумали много. Но реализация некоторых из них будет неоправданно дорогой в разработке.
Чтобы не тратить время на такие фичи, мы использовали метод приоритезации ICE (Impact, Confidence, Ease) scoring. Он показывает, какие идеи нужно реализовать сначала, какие можно сделать позже, а про какие можно вообще забыть.
Обычно, следующим шагом идёт разработка вайрфеймов и встреча с разработчиками, чтобы сориентироваться по времени и стоимости разработки.
В нашем случае мы пойдем по другому пути. Сначала мы проектируем варфреймы, затем рисуем концепт, потому что у нас нет дизайн-системы. Если бы она была, мы бы сразу пошли и накидали высокодетализированный концепт).
После всех исследований Игорь сформировал из участников три команды: Terra, Aurora и Stella, каждый из которых свою роль terra — главная страница и онлайн-музей, aurora — весь процесс покупки и stella — оффлайн сегмент (страницы маршрутов, экскурсоводов, экспонатов). Далее лиды составили информационную структуру сервиса, чтобы понять, какие на сервисе будут страницы и определить объем работы. Затем согласовали структуру с Игорем, и все три команды приступили к созданию вайрфреймов.
Создание вайрфреймов
Мы созвонились для согласования вайрфреймов. Игорь одобрил решения команды Stella, и мы приступили к обсуждению наполнения вайрфреймов: решали, какие будут отступы, кегль шрифтов, карточки и т.д.).
На этом же созвоне Игорь расформировал команду Terra, потому что один из её членов не принимал участия в работе. Выяснилось, что вайрфреймы в этой команде составляли втроём, чтобы успеть к дедлайну (в этом помогал лид, хотя он не должен был заниматься другими задачами). Участников Terra распределили между командами Stella и Aurora.
После этого мы созванивались внутри команд, где лиды передавали в работу всё, что было согласовано с Игорем.
Поиск референсов и разработка визуальной концепции
Чтобы сделать этот этап более предсказуемым, Настя записала видео, где рассказала свою методику поиска решений: какие подходят и почему, на что надо обращать внимание при поиске и многое другое.
Цвета и шрифты мы взяли у фестивальной команды, но итог не порадовал Настю и Игоря. Концепция не отражала того, что хотелось бы видеть в сервисе, а визуал не выполнял своих задач.
Мы начали экспериментировать, пробовать разные цвета, шрифты и согласовывать с Настей. Через несколько дней мы предоставили 9 концепций, из которой одна была выбрана и согласована.
Наша продуктовая команда приступила к отрисовке страниц сервиса в согласованном стиле. Лиды собирали все макеты, которые нужно отправить Насте на обратную связь, она проверяла их, давала правки, и мы дорабатывали свои решения.
Прежде чем приступить к разработке, Игорь провёл созвон, на котором подробно объяснил нюансы разработки UI-кита, разбирал ошибки. Мы решили выделить под это дело одного человека (потому что когда за работу отвечают все, в итоге не отвечает никто). Один из лидов, Камиля, вызвалась на эту задачу (что не освобождало её от обязанностей лида).
На созвоне я поняла, что не разбираюсь в токенах и ui-китах, поэтому вызвалась его собирать. Мне хотелось разобраться в этой теме.
Когда Настя утвердила главную страницу и каталог экспонатов, Камиля приступила к разработке UI-кита, и начала со шрифтов. Она поместила все шрифты, которые были использованы, на отдельную страницу, чтобы выявить паттерны использования и таким образом «схлопнуть», то есть уменьшить варианты использования шрифтов.
Например, были «схлопнуты» начертания (Bold и Black) и размерность, где шрифты отличаются на несколько пикселей. Затем Игорь проверил работу и «схлопнул» решения ещё сильнее. Камиля беспокоилась о том, что мы будем недовольны таким результатом, т.к. на подбор шрифтов уходило много времени, было много вариантов, а в результате осталось несколько начертаний.
У нас не предполагалось тёмной и светлой темы, поэтому цвета были отобраны для светлой темы. Также в токенах Камиля задала общие расстояния для карточек.
На созвоне с презентацией UI-кита многие из нас действительно не узнали свои страницы. Казалось, они получаются совсем не такими, какими мы их задумывали. Но в итоге Игорь всё объяснил, и мы поняли, что шрифтов было действительно необоснованно много — это мешало нам двигаться дальше.
Наконец, мы добились консистентности, и привязали согласованные стили к своим макетам. После этого Камиля продолжила работу над другими элементами UI-кита: карточками, кнопками, ссылками. Так у нас появились готовые сущности — готовые дизайн-решения, которые можно использовать.
Сценарии
Сначала мы продумывали сценарии на этапе разработки вайрфреймов, но получалось не очень, поэтому Игорь решил поставить сценарии в конец разработки.
Когда все страницы в проекте были готовы, мы приступили к разработке сценариев. Этот этап действительно прошёл быстрее и легче, чем в начале проекта — у нас появились целостное видение и опыт совместной работы.
Лиды поделили работу, и мы приступили к проработке сценариев. Где-то было легче (например, на странице о музее), где-то сложнее. Страница покупки предполагала более детальный и сложный сценарий, там мы не уходили вглубь — остановились на проработке самого базового.
По ходу работы мы задавали вопросы Игорю, на созвонах он давал правки и объяснял логику сценариев, показывал на примерах.
Тестирование
После того, как сценарии были проработаны, мы сделали интерактивные прототипы для тестирования. Каждый участник тестировал страницу своего коллеги, а не ту, которую разрабатывал сам (это было сделано для того, чтобы избежать субъективности). Для проведения тестов на одну страницу нужно было найти 5 человек, и прогнать их по определённому сценарию.
По итогу у нас появились данные, по которым можно было сделать выводы о том, где и как улучшить пользовательский путь. Внедрять их мы, конечно же, не стали :) Цель была разработать MVP, а этап тестирования нужен был чтобы задать вектор на развитие онлайн-сервиса музея ЗИЛ.
Результат
Мы разработали MVP сервиса-музея, который стоит на крепком фундаменте, и в нём построено не одно здание, а целый город!
Ознакомиться с «планом строительства» можно по ссылкам на Diprofile и Behance — заходите, смотрите, исследуйте, оставляйте отзывы, мы обязательно вам ответим. Если у вашей студии есть ресурсы сверстать проект по нашим чертежам — пишите Анастасии Красовской.
Заключение
При потоковой разработке в студии сроки в два раза меньше, чем были у нас, за дедлайны спрашивают строже, без опыта работы сложно выдержать такое погружение в рабочий процесс. Но где этот опыт взять, как научиться бегать, когда ещё не сделан первый шаг?
Мы все очень рады были инициативе Насти Красовской, которая позвала нас в проект, где мы сделали свои первые шаги в разработке продуктовых сервисов!
За полгода мы стали большой сыгранной командой, узнали многое о продуктовой разработке от играющего тренера Игоря Шульги, и о процессах работы в студии от Насти Красовской. Для многих из нас это был первый опыт работы в студии над продуктовым сервисом, и тут очень важно, что он состоялся с адекватным руководителем.
Благодаря новым знаниям и умениям, полученным во время работы с продуктовым дизайнером Т-банка и арт-директором PixelPeak, многие из нас могут устроиться работать в студии.
