В свое время мне пришлось иметь дело с большим количеством стартапов разного уровня сложности и финансирования. У стартапов, конечно, есть своя специфика, но проектирование в них кардинально не отличается от того, которое проводится в студиях и компаниях. Сейчас я уже работаю с проектами другого класса, но иногда стартаперский шлейф умудряется меня догонять. Так, по сарафану порой прилетают довольно интересные заказы на перепроектирование — переосмысление, переработку, редизайн сервиса. И почти всегда это реально клёво. Ниже я расскажу, почему.
То, что вы сейчас читаете, родилось из миддлрида в моем фэйсбуке, поэтому некоторые мысли здесь повторяются практически дословно. Однако есть и много чего новенького. Не переключайтесь.
Заранее извиняюсь за некоторую грубость повествования: в выборе выражений я не силен.
Почему перепроектирование — это клёво
Вообще, по понятным причинам любое перепроектирование (не только стартапов) предполагает меньше неопределенности — а значит, оно безопаснее, проще. И это так. Но почему-то многие берутся за него со старым подходом: обычным, привычным и унылым. Тупо проектируют. А там же нюансов — миллион. Не учтешь какие-то, и работать придется больше, а результат будет не таким стабильным. Ты наверняка сделаешь лучше, чем было, но дольше, дороже и хуже, чем могло быть.
Бабло
Оно на первом месте, разумеется. Если проект готов к глобальной перестройке — значит, он «выстрелил». В той или иной мере, конечно, но у него есть деньги. А значит, работа будет оплачена. Не будет вымораживающих «давай на проценте войдешь», «мы такие крутые, не хочешь нас в портфолио?» или «у нас есть два килобакса, давай ты все придумаешь за нас». Все эти истории хороши в начале карьеры, когда ты еще не испытал собственной жопой жесткие камни бизнес-реалий. Работать бесплатно можно только на себя, и то «условно» (если ты не волонтер, но это совсем другая история).
Кроме того, если у бизнеса есть хоть какие-то деньги, то тебе, скорее всего, не придется вымаливать копейку на банальное А/В тестирование или привлечение внешнего технического специалиста. Значит, ты реально сможешь поработать с гипотезами — а это всегда доставляет.
Аналитика
Первое, что я спрашиваю у клиента перед перепроектированием — это доступ к GTM, Яндекс.Метрике, Branch/Amplitude и тп. И только потом называю финальную оценку своей работы. Если аналитика на старте была настроена грамотно, то 90% гипотез могут быть проверены за несколько минут (пусть иногда и косвенно). И это по-настоящему круто. Вот прям круто-круто.
Реальный случай, из недавнего: клиент заявляет, что пользователи жалуются на сложную форму заказа и это — главная проблема сервиса. Начинаю копать аналитику и понимаю, что с формы заказа отваливается примерно половина пользователей, тогда как со страницы поиска услуг — около 80%. То есть вглубь воронки проходит только 20%, из которых половина валится на заказе. Если даже не делать ничего с заказом, а добиться удвоения прохождения поиска (с 80% до 60%) — это будет равносильно идеальной форме заказа, со стопроцентной конверсией. Конечно, это не значит, что заказ не надо трогать. Это говорит только о том, что мнение клиента попало под влияние «систематической ошибки выжившего»: до заказа доходили только самые упорные клиенты, и они же потом не ленились писать про сложность формы. Они не говорили о траблах с поиском, просто потому что заказ был их крайней проблемой, а мозг, ленивая скотина, склонен экономить джоули.
Пользователи
Живые, реальные, плоть от плоти сервиса. Их можно палочкой потыкать, или за ништяки какие-то привлечь к беседе. Такой возможности не будет при классическом проектировании — и очень странно, что некоторые мои коллеги тупо забивают на это болт. Нет, они, конечно, учитывают наличие пользователей, но для них это скорее какой-то ограничивающий фактор. Хотя, казалось бы, все просто: выбейте из клиента скидку для участников вашего опроса, и у вас появится железная доказательная база выстоявших под этим натиском гипотез.
А еще у фаундеров всегда имеется тьма тьмущая настоящих отзывов: хотелок, недовольств, восхищений. С ними надо быть аккуратнее, слепо доверять не стоит (вон выше пример), но само по себе это довольно мощный инструмент сужения домыслов. Если уметь обработать, можно массу скрытых грабель выкопать.
Бизнес-процессы
Тут, скорее, банальная лень. Но все же знают, чей именно она двигатель, да?
Чаще всего внутренняя часть БП уже настроена, так или иначе обкатана, вычислены узкие места. Не нужно много думать, предполагать, строить монструозные BPML’ки. Чаще всего достаточно взять готовое и оптимизнуть. И это прекрасно, ибо для меня лично бизнес-процессы — самая унылая часть проектирования. Да, она, вероятно, самая важная, но как же выбешивает опрашивать менеджеров колл-центра или по крупицам собирать ценные факты из потока пожеланий какого-нибудь руководителя отдела.
Грабли
То, что вы можете с любопытством рассматривать шишки на лбу прежних продуктологов, создававших этот сервис до вас — уже само по себе приятно. Если вам доступна проектная документация, отчеты или хроника факапов сервиса, то ваш собственный лоб будет значительно целее.
К граблям, на которые можно наступать неоднократно, относятся:
- неверное определение целевой аудитории, их микропотребностей;
- самонадеянная проработка UX, слабо соотносящаяся с реальностью;
- нюансы финмодели, «просаживающие» прибыль сервиса;
- еще миллион явлений, решений и событий.
Поспрашивайте у клиента, что они меняли в сервисе и почему. Как он развивался, какие дыры залатывали разработчики. Учится надо по возможности на чужих ошибках. Если можно проанализировать факапы предшественников — только идиот этого не сделает.
Техническая составляющая
Здесь, вроде, вы как раз ограничены. Инфраструктура сервиса определена, архитектура выстроена и все работает, особенно не развернешься. Но это, на самом деле, тоже плюс. За один-два разговора с техническим директором или ведущим разработчиком вы сможете выяснить все недочеты существующей системы. Все ее ограничения, особенности. Если где-то есть слабое место, вы сможете его усилить или «обойти» интерфейсно.
Поясню на примере. Делал перепроектирование одного маркетплейса. Намечался глобальный редизайн, вплоть до упразднения ролей пользователей и разнесения сущностей. Архитектура базы данных позволяла вытворять всякое, а разработчики планировали полностью переписать сервис — радость, да и только. Но при первом же общении с техдиром выяснилось, что при всей внутренней свободе, завязка на внешних сервисах, вроде Amazon Elasticsearch, накладывала ряд не самых очевидных ограничений (которые наверняка бы были упущены, не изучай разрабы эти сервисы уже год).
Масштабируемость и развитие
Особенно это касается стартапов, которые на старте еще только щупают рынок и определяются с бизнес-моделью. При перепроектировании вектор развития, как правило, уже определен — и вам не нужно планировать «во всех направлениях». Вместо этого вы можете сконцентрироваться на конкретных задачах и вылизать их до зеркального блеска.
В упомянутом ранее примере такой задачей стало усиление так называемых «клубов совместных закупок», хотя изначально это была лишь небольшая фича сервиса, малозаметная и, как казалось, незначительная. Но за пару лет существования сервиса именно она стала приносить больше всего прибыли компании.
И таких историй — тьма. Круто, когда понимание того, как должен развиваться и расти проект, приходит не из туманных гипотез, а из сухих и холодных финансовых отчетов.
Контент
Чаще всего контент — это серьезный геморрой при проектировании. Я уже неоднократно заявлял, почему в макетах не должно быть текста-рыбы. Но иногда реальный контент взять неоткуда. Иногда — но не в случае с перепроектированием. Это же рай: ваш прототип/макет может содержать только реальные данные. Вам не нужно копать в Интернете, подсматривать у конкурентов или что-то выдумывать (увеличивая вероятность «просачивания» левого текста в продакшн). Более того, вы можете составить текстовый кит проекта (!) и требования к контенту. Если не это счастье — то что?
Черные лебеди
Пожалуй, самый неочевидный и неоднозначный момент, который стоит учитывать при переосмыслении продукта. Если вкратце: практически любой сервис рано или поздно сталкивается с событиями, которые невозможно спрогнозировать и учесть — ввиду их теоретически ничтожной вероятности. Но такие события случаются. И, случившись, они оказывают серьезнейшее влияние на продукт — и отнюдь не всегда это влияние положительное. Анализировать таких «черных лебедей» по отдельности — занятие, чаще всего, попросту бесполезное. А вот копнуть первопричины этих событий, да наложить их на вероятные последствия… Это как кунг-фу, только в голове и круче.
Если в сервисе, который вам надо перепроектировать, случались такие истории, то глупо их не учесть. Нет, вы не сможете предугадать «лебедей» — потому они и «черные». Более того, вам вовсе не нужно этим заниматься. Попробуйте найти причины их возникновения, корневые, глубинные предпосылки, постройте карту вероятностей — и закрывайте те места, куда могут ударить такие события. Или наоборот, придумайте, как сделать их максимально выгодными для компании.
На самом деле, эта тема очень обширная, и в рамках одного раздела я не смогу ее раскрыть даже теоретически. Наверное, напишу отдельную статью, с реальными кейсами. А если вы до сих пор не читали книгу Нассима Талеба «Черный Лебедь. Под знаком непредсказуемости» — то сделайте это обязательно, прямо сейчас.
Риски перепроектирования
Конечно, я не могу отказать себе в ложке дегтя. Как и везде, в переработке продукта тоже есть свои сложности. И иногда они могут обернуться реальной катастрофой для бизнеса. Подробно останавливаться на этом я не буду, благо статей на тему «как не завалить редизайн» предостаточно.
Красная кнопка
Круто работать в большущей корпорации, которая с легкостью поглотит все вибрации от твоего фэйла. Когда у тебя оклад, а между работой и пофигизмом — только совесть. Куда сложнее, если твои решения могут банально похоронить сервис. Если ты проектировщик или продуктовый дизайнер в небольшой компании, то на тебе лежит серьезная ответственность. Зафэйлить апдейт просто. Сложно потом объяснить пользователям и начальству, почему это ты обосрался.
Все считается
Буквально недавно я опубликовал странный пост о том, почему важно считать фэйлы и рассказывать о них миру. При грамотном руководстве все ваши провалы обязательно будут замечены, посчитаны и предъявлены. Хотя бы потому, что это очевидно и не сложно: посмотреть конверсию «до» и «после», умножить на количество посетителей и средний чек.
Просто думайте об этом, когда выдумываете заново свой продукт. Старайтесь сделать так, чтобы результаты вышеизложенных вычислений были положительными, а не отрицательными.
Снова пользователи
Эти ребята, снующие туда-сюда по вашему сервису, не всегда — благо. Да, их можно допросить, помогая себе яркой лампой и скидками. Да, они — единственный источник реальной обратной связи. Источник, который можно пощупать. И который обязательно обгадит вас и ваши решения, как только вы выложите первый вариант редизайна. Просто смиритесь, что так оно и будет. Причины просты: никто не любит учиться. А тем более — переучиваться. Максимум, что вы можете сделать — свести период недовольства к минимуму.
Чем больше у сервиса пользователей, тем более аккуратно нужно выкладывать обновления. Если они привыкли к определенному сценарию, надо менять его плавно. Представьте, что вы кормите льва с руки: одно резкое движение может отминусовать вам кисть, а то и голову.
Итог
Правила постописания обязывают меня сделать какой-нибудь эффектный завершающий финт. Типа «резюмируя все вышеизложенное…». Нафиг. По статистике, до этой части статьи добирается три-пять процентов посетителей. Если вы в их числе — вот вам моё «спасибо». Переключайтесь.
