Как планировать процесс дизайна сложных продуктов
В отличие от разработки простых продуктов во время Bootcamp, в работе над дизайном сложных продуктов вы столкнетесь с большим количеством UX-челленджей.
На мой взгляд, после 2-3 лет работы продакт-дизайнером вам точно стоит попробовать себя в разработке сложных продуктов. Они будут ставить перед вами больше задач, давать намного больше пищи для размышлений и помогать развиваться как дизайнеру.
Я работал над многими сложными продуктами, иногда добавляя новые функции, а иногда разрабатывая все с нуля. Теперь я хотел бы поделиться своим опытом и некоторыми мыслями о том, как делать это хорошо. Здесь я подробно опишу свой процесс разработки продукта с нуля, поскольку он включает в себя больше этапов и немного сложнее.
Что такое сложные продукты?
Во многих случаях сложные продукты относятся к продуктам B2B, но я считаю, что продукты B2C также могут быть сложными. К примеру, Amazon, eBay и ваш браузер — сложные продукты.
На мой взгляд, сложность продукта определяется не его областью, а конкретными задачами, пользовательскими потоками и взаимодействиями. Предметную же область дизайнеру в любом случае необходимо хорошо изучить. И если она еще незнакома, это не значит, что продукт будет сложно спроектировать. Это просто означает, что вам нужно будет посвятить некоторое время изучению темы в процессе дизайна.
Проблема при проектировании сложных продуктов
При разработке сложных продуктов трудной частью является разделение и планирование работы, чтобы вы могли работать в потоке, не решая все сразу.
Вы не сможете закончить дизайн, если попытаетесь сделать все за один шаг. Важно иметь возможность сосредоточиться на одной проблеме за раз.
Организация работы при проектировании сложного продукта
Организация работы является ключевым моментом. Она делает процесс выполнения задач более эффективным и простым. Но сложный продукт на то и сложный. Трудности останутся, даже если вы составите идеальный план и будете его придерживаться. Давайте же посмотрим, как с этим быть.
Выделите основную функцию
Сначала необходимо определить область применения продукта. Продакт-менеджер, разработчики и вы должны вместе описать, что продукт будет решать в своей первой итерации (версии).
Ваша стратегия должна быть направлена в первую очередь на решение основной проблемы пользователя. Самый эффективный способ сделать это — использовать карту пользовательской истории (user story map). Этот метод описан в книге «User Story Mapping» (Джефф Паттон и Питер Экономи). Я сам прочитал ее и рекомендую вам, но если у вас нет времени, можете прочитать эту статью. В ней все хорошо объясняется.
Проще говоря, это процесс разделения работы на небольшие части, определения их приоритетности и сосредоточения внимания на наиболее важных задачах.
Для применения этой техники можно использовать множество шаблонов. К примеру, вот один от Миро и один от FigJam. Они хорошо подойдут для семинаров по продакт-дизайну с командой.
Важно осознавать, что все ненужные функции, которые команда добавит к продукту в его первой итерации, усложнят проектирование, разработку и тестирование продукта.
Личное наблюдение: многие люди ошибочно полагают, что большее количество функций означает лучший продукт, но я так не считаю. Я уверен, что хорошо работающий продукт с меньшим количеством функций, необходимых пользователю, гораздо более ценен, чем продукт с большим количеством функций, которые пользователю не нужны.
Возьмем ваше почтовое приложение. Оно имеет множество функций, но основная из них — отправка и получение электронных писем. Поэтому вы должны в первую очередь сосредоточиться на этом, а уже потом на всем остальном.
Разделите работу на небольшие части
На протяжении всей своей карьеры я тесно сотрудничал с разработчиками. И теперь, наряду с использованием карт пользовательских историй, о которых я рассказал выше, я также понимаю важность разбиения работы на более мелкие части.
Поскольку процесс создания продукта сложен, разработчики делят работу на небольшие задачи и выполняют их одну за другой. В результате они лучше справляются со своей рабочей нагрузкой.
Таким же образом разбейте проектную работу на небольшие потоки и работайте с ними по очереди. Возьмем, к примеру, процесс входа в систему. Вот как бы я разделил его на маленькие части:
- В Happy Path (счастливом варианте событий) у пользователя нет проблем со входом в систему через логин и пароль.
- Пользователь ввел ошибочный пароль.
- Пользователь ввел ошибочный email.
- Пользователь перешел на страницу входа, но у него нет учетной записи.
- Пользователь забыл пароль.
Мы видим, что у нас есть пять различных потоков, которые нам нужно проработать, чтобы продумать обычный вход в систему. И мы даже не включали сюда другие крайние случаи, например, когда пользователь забыл свой юзернейм.
Таким образом, вы можете сосредоточиться на каждой проблеме отдельно и решить ее, не бросаясь на все сразу. Представьте, что вам нужно проработать все эти случаи одновременно, в одном потоке. Это же просто невозможно.
Контролируйте качества дизайна для каждой задачи
Каждый раз, когда разработчик добавляет новую реализацию в среду разработки, уделяйте время ее тестированию. Это гарантирует, что все потоки будут работать должным образом и ваш дизайн перенесут без ошибок.
Помните, что при контроле качества дизайна главная цель — убедиться, что реализация ведет себя так, как задумано. Это не поиск ошибок. Тем не менее, сообщайте разработчикам, если обнаружите ошибки.
Работайте с дизайн-системой с самого начала
Если вы работаете над существующим дизайном, это здорово. Скорее всего у продукта уже имеется система дизайна, которую вы можете использовать.
Если же продукт новый и дизайн-системы нет, необходимо создать ее с нуля.
Всякий раз, когда я говорю о дизайн-системе, я не имею в виду UI-kit, доступный в Figma. Я имею в виду настоящую дизайн-систему с кодом и компонентами. Следовательно, вам нужно работать с разработчиками и решать, какую библиотеку они будут использовать.
Сегодня существует множество библиотек пользовательского интерфейса, которые вы можете использовать. К примеру, Ant, Material design или Apple Human Interface Guidelines (если вы работаете над продуктом для Apple).
Для многих продуктов вам не нужно создавать каждый элемент с нуля. Вы можете использовать базовые компоненты, такие как кнопки, флажки, переключатели и т. д., из существующей библиотеки. Тогда можно позволить себе поиграть с цветами, шириной линий, радиусами углов и типографикой. А уже в дополнение создать свои собственные компоненты на основе ваших конкретных требований.
Особенно для сложных продуктов, которые требуют больших усилий для управления их потоками и взаимодействиями, я не верю в изобретение велосипеда. В этом просто нет необходимости.
И несмотря на то, что при запуске нового продукта нет времени на все, что мы хотим, создание хорошей дизайн-системы с первого момента (не равно создание каждого элемента с нуля) увеличит скорость работы команды в будущем.
Делайте все компонентом в Figma
Работайте в Figma так, чтобы 99% ваших артбордов содержали только компоненты.
Суть в том, что у сложных продуктов много функций, и вы точно совершите много ошибок. А чтобы не исправлять одни и те же ошибки на каждом артборде, нужно работать с компонентами. Это позволит быстрее вносить изменения и быть намного более эффективным.
Применяйте одинаковую логику в дизайне
Во-первых, одинаковая логика в веб-версии и в приложении сделает продукт более понятным для пользователей. Кроме того, это облегчит жизнь разработчикам, потому что они будут знать, как решать проблемы самостоятельно, а не спрашивать вас каждые 5 минут.
Например, если некоторые задачи являются модальными, логично, что большинство задач в той же категории должны работать таким же образом.
Поговорите с разработчиками о реализации вашего дизайна
Обсуждение процесса реализации с разработчиками — более чем хорошая идея, так как они не будут разрабатывать все приложение за раз. Вместо этого вы можете вместе решить, за какие части им стоит взяться в первую очередь. Так вы будете знать, когда и как предоставить им дизайн. К примеру, сначала вход в учетную запись, потом файловый менеджер, а потом основные части продукта.
Документируйте все свои решения
Каждый продакт-дизайнер принимает множество дизайнерских решений в процессе разработки любого продукта. Однако в отношении сложных продуктов вы будете принимать больше решений, чем обычно. Документирование всего в таком случае имеет решающее значение.
Если хотите узнать больше о том, как это сделать, можете почитать мою статью о дизайн-документации.
Проверяйте снова и снова
Точно так же повара пробуют еду, прежде чем подавать ее клиентам. Протестируйте дизайн перед тем, как показать его команде и отправить в разработку. Сделав это, вы сможете исправить ошибки вовремя и проверить, не отсутствуют ли какие-то сценарии.
Создавайте прототипы
Создавайте прототипы своих потоков, чтобы протестировать дизайн и почувствовать его лучше. Кроме того, с помощью прототипов разработчики и продакт-менеджеры тоже смогут прикоснуться к вашей работе и оставить отзывы.
Как и в разделе «Разделите работу на небольшие части», тут тоже лучше работать с небольшими потоками и тестировать их отдельно. Так вы сможете лучше сосредоточиться на каждой задаче и быть более точными.
Хорошо организуйте свой файл в Figma
Правильная организация файлов — критический фактор в работе над сложным продуктом. Все люди в команде должны легко ориентироваться в общих файлах.
И не стесняйтесь разделять дизайн на несколько файлов. Иногда так проще контролировать всю информацию.
Выводы
В этом руководстве я рассказал, как именно я работаю над дизайном сложных продуктов. Давайте коротко опишем главные пункты:
- Сосредоточьте внимания на основных болевых точках пользователей.
- Приоритизируйте задачи.
- Разделяйте дизайн на небольшие потоки.
- Сотрудничайте с разработчиками на этапе контроля качества дизайна и работайте с дизайн-системой с самых первых этапов.
- Тестируйте снова и снова.
- Не забывайте систематизировать и документировать информацию.
Спасибо за прочтение статьи. Надеюсь, она помогла вам понять, как планировать работу при проектировании сложных продуктов. Нам будет приятно, если вы поделитесь ею со своими друзьями или членами команды.
