Улучшенная документация и командная коммуникация с документами по дизайну продукта

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

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

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

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

Падение дизайнера героев

Примерно в 2018 году я работал удаленным дизайнером продуктов из Мадрида в компании, работающей в Латинской Америке, привлекая к этому процессу другие команды из Мексики и Сан-Паулу, Бразилия.

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

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

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

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

Запросы на вытягивание позволяют вам вносить изменения в большую кодовую базу, документируя их и подтверждая свои решения отзывами других людей. Таким образом, внесенные вами изменения идеально сочетаются со всеми стандартами и связями, которые уже есть в коде. Это именно то, чего мне нужно было добиться, но, конечно, в дизайнерско-модном подходе. Позвольте представить вам документ Product Design Doc.

Документ о дизайне продукта

Product Design Doc (PDD) — это документ, в котором проблемы, которые вы хотите решить, контекст и окончательное решение преобразуются в итерационный или поэтапный подход.

Это означает, что вы можете задокументировать весь процесс проектирования в одном документе, которым можно поделиться с кем-либо в вашей компании, и он будет служить базой знаний для принятия решений о продуктах, которые вы принимаете. Звучит круто, да? Давайте углубимся в детали.

Общие концепции

PDD можно описать четырьмя основными понятиями: метаданные, контекст, этапы и обратная связь .

• Метаданные — это просто полезная информация о документе, такая как заголовок, дата, статус и так далее.

  

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

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

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

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

Пример структуры

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

• Заголовок должен быть кратким, четким и легко отличаться от других заголовков PDD, которые у вас уже есть.
• Статус показывает, на каком этапе сейчас находится ваш документ:
• Черновик
  Все еще работаю над определением контекста. Не готов к обратной связи.
• С30, С60, С90
  Различные этапы (30%, 60%, 90%) вашего решения (подробнее об этапах позже).
• Полный
  Все отзывы учтены, недостающих моментов нет. ПДД закончен.
• Резюме — это описание проблемы, для решения которой вам нужно разработать дизайн, обычно со ссылками на другие полезные материалы, которые у вас могут быть.
• Цели — это ключевые моменты, на которых должно сосредоточиться ваше решение. Это контрольный список, который вы будете постоянно просматривать, чтобы убедиться, что вы на правильном пути.
• S30 (или Стадия 30% ) — это первое предложение, которое вы делаете на основе аннотации и целей, фокусируясь на более широком решении, а не на деталях, возможно, предоставляя каркас низкой точности или аналогичную технику. Это этап, на котором предлагаемое решение может иметь совершенно другой подход, и ожидается, что произойдет основная обратная связь.
• S60 (или этап 60 % ) — это ваше решение на 60 % завершенности, в котором применяются отзывы от S30. В нем меньше деталей, чем в S90, но четко указано намерение вашего решения. Вы предоставляете высокоточный каркас с большим количеством случаев и некоторыми определениями потока. Вы можете получить какую-то обратную связь, в основном касающуюся упущенных случаев и небольших неожиданных сценариев.
• S90 (или Этап 90 % ) — это этап, на котором решение завершено на 90 % и применяется обратная связь из S60. Этот этап сосредоточен на самых мелких деталях вашего дизайна, включая все различные сценарии, крайние случаи, визуальный дизайн и даже прототипы. Ожидается, что будет какая-то незначительная обратная связь.

Вы можете спросить себя, нужно ли мне следовать тому же порядку и соглашению об именах этапов? Ну, нет. Вы можете переименовать этап с S30, S60 и S90 просто на: Исследование, Предложение, Решение.

Вы также можете изменить порядок, чтобы наиболее совершенная работа (S90, Решение) находилась в верхней части документа, а поток чтения переходил от заключительного этапа к раннему (S30, Исследование).

Шаблоны

Начните быстро с одного из предоставленных шаблонов для наиболее распространенных письменных платформ. Помните: соглашения об именах разделов полностью настраиваются. Если вам не нравится Abstract , просто используйте Brief , About или что-то еще, что соответствует вашим потребностям. Основная концепция, которую вам нужно сохранить, заключается в создании различных итераций, чтобы сосредоточиться на каждом этапе, вы можете просто переименовать S30 в Exploration, S60 в Proposal и S90 в Solution.

• Бумага
• Понятие
• Гугл документы
• Пример из жизни

Основные преимущества использования PDD

1. Каждое решение документируется.
   Это означает, что даже когда вы покинете свою компанию/проект (а это произойдет рано или поздно), все знания, полученные вокруг, навсегда останутся в компании, чтобы другие люди могли посмотреть на них и повторить с того места, где вы ушли.

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

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

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

Заключительные примечания

Завершая рассказ об этой удаленной компании, я проработал там еще несколько месяцев и смог внедрить Product Design Docs как минимум на 5 различных проектах. Мое разочарование значительно уменьшилось, и я смог достичь консенсуса по своим дизайнерским предложениям, поэтому продукт продолжал развиваться. С тех пор компания сильно выросла, и часть работы, которую я проделал в свое время, все еще используется.

PS: Я начал писать эту статью в 2019 году, потом в 2021 году увидел, что Abstract создает продукт для документирования процесса проектирования, поэтому решил вернуться в нужное русло и закончить. Похоже, это все еще достаточно актуальная тема.

Список используемой литературы

• Как выполнять упражнения по проектированию в удаленной команде, Ханна Харт
• Избегайте эффекта чайки: схема обратной связи 30/60/90 Лорен Мун
• Как вы разрабатываете дизайн-документ? Джон Сайто
• Сила дизайн-документа Брендана Фэгана
• Представляем ноутбуки Мэтта Кольера