TL;DR Резюме

• Многие (большинство?) команды цифровых продуктов не имеют лидерства, ориентированного на дизайн, и/или ресурсов, необходимых для серьезного редизайна продукта (или для комплексного применения новой системы дизайна).
• Однако общая ошибка дизайнеров в этих организациях заключается в разработке «идеальных», желаемых шаблонов, которые представляют собой серьезные изменения в системе: то есть «давайте спроектируем лучшую систему, о которой мы только можем подумать», вместо системы, которая лучше всего улучшит работу. существующий продукт.
• Мой предпочтительный подход — меньше «революции», больше «эволюции»: развивая систему из корней существующего продукта (а не форсируя революционные изменения), вы гораздо быстрее достигнете более согласованного, предсказуемого и удобного пользовательского опыта. .

Компании имеют ограниченные ресурсы для внесения изменений в конструкцию

Такие организации, как Airbnb и Apple , показали нам, что подход к продукту, ориентированный на дизайн, может привести к прекрасным впечатлениям, а иногда даже к коммерческому успеху! А такие компании, как MailChimp и Google (с запуском Material Design ), проделали замечательную работу, исправив курс во всестороннем положительном изменении дизайна.

Часто, когда команды дизайнеров говорят о дизайн-системах, они имеют в виду компании: «Нам нужен материальный дизайн для [нашего продукта]!» Очень захватывающая вещь, но это непростая задача для команды с ограниченными, востребованными инженерными ресурсами, которая уже имеет загруженный бэклог: они хотели бы иметь хорошо спроектированный продукт, но сначала они должны работать над [X, Y, и проекты Z]... все они, вероятно, имеют более четкую историю окупаемости инвестиций, чем изменения дизайна.

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

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

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

Так как же вам, дизайнеру продукта, привести эту вещь в форму?

Революция: достичь дизайнерской нирваны одним ударом

Да здравствует революция! Когда вы сидите в Sketch перед дисплеем Apple Thunderbolt, легко попасть в эмоциональную ловушку: «Если бы я только мог начать с нуля, я мог бы заставить этот продукт петь! ». Но как вы планируете реализовать это на самом деле? Вероятно, что-то вроде этого:

Отличная работа: вы получили идеальную дизайн-систему! Давайте разберем этот подход для применения дизайн-системы.

Плюсы

• Ваш продукт теперь имеет дизайн нашей мечты! ЭТО ВОЛШЕБНО!
• Вы спроектировали все сразу, с одними и теми же дизайнерами в комнате, так что все супер слаженно и продуманно. ТАК ХОРОШО!

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

Модель «Полярная звезда»: достижение нирваны дизайна продукта, одно чудесное мгновение за раз

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

Хорошо, у нас есть некоторое движение, и к концу этого процесса у нас есть несколько действительно приятных впечатлений от нашего продукта (даже если мы все еще несем с собой кое-какой багаж).

Плюсы

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

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

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

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

Это эволюция, детка : получить лучший продукт быстрее, ценя то, что у вас есть

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

1. Узнайте о вашей текущей дизайн-системе (если она есть) : откуда берутся компоненты? Есть ли где-нибудь в вашей организации основная таблица стилей или библиотека? Как они организованы? Кто его построил? Кто использует его больше всего, и какие его части они используют? Когда им приходится ездить по бездорожью без него?
2. Перечислите шаблоны и модели поведения, которые вы видите в своем продукте : как вы представляете различные типы информации пользователям? Как пользователи выбирают то, что они хотят видеть? Как они вводят информацию? Для элементов интерфейса: вы видите вкладки, карточки, списки или формы? В каких ситуациях появляется каждый элемент?
3. Запишите правила, которым, кажется , следует ваш продукт; затем сами ужесточите правила: где-то за всем дизайном стоит логика того, как был собран ваш продукт. Поймите правила дизайна, которым, кажется , следует ваш продукт, а затем удвойте их. « Кажется, мы используем таблицы для многих целей, в том числе когда пользователям приходится выбирать, с чем взаимодействовать », возможно, превращается в правило: « Мы используем строки таблицы, чтобы позволить пользователям выбирать между связанными, но независимыми элементами ».
4. Добейтесь консенсуса от вашей команды (команд): сообщите о своей оценке и своем плане. Достижение консенсуса легче сказать, чем сделать, но то, что вы построили эту систему из существующего продукта , облегчит этот разговор и переход, чем если бы вы придумывали совершенно новые шаблоны и правила. Конечно, многие из этих заинтересованных сторон также внесли свой вклад в то, как продукт выглядит сегодня, поэтому этот путь более уважителен к их ролям и всем организационным знаниям, заложенным в существующие проекты.
5. Начните строить с этой системой: теперь, когда вы знаете, каким правилам следовать и какие шаблоны использовать, определите эти шаблоны и начните следовать им! В следующий раз, когда ваши инженеры добавят таблицу, карточку, форму и т. д., убедитесь, что это именно тот элемент , который указан в спецификации, и что они используют его правильно. Со временем большая часть вашего интерфейса будет использовать эту новую систему дизайна, но она должна относительно хорошо сочетаться со старыми частями интерфейса.

Плюсы

• ТАК МНОГО ЗЕЛЕНОГО . Основывая новую систему на основе существующих шаблонов, вы быстрее добьетесь «хорошего».
• «Хороший опыт» относительно хорошо сочетается со «старым опытом», что обеспечивает более плавный опыт — да, даже в эти трудные переходные месяцы и/или годы.
• Менее радикальные изменения означают, что вы сможете быстрее применять новые компоненты и шаблоны. Затем, когда они все подключены к системе, вы можете изменять и обновлять их на системном уровне: это увеличивает шансы на то, что вы сможете не отставать от соседей Джонса (т. е. ваших конкурентов) позже, когда они неизбежно получат новый собственный интерфейс.
• Менее кардинальные изменения также могут быть полезны с точки зрения пользователя: пользователи, как известно, не любят изменений (посмотрите на каждый редизайн Facebook или масштабный редизайн вашего любимого инструмента B2B), поэтому избегание значительных скачков может смягчить удары в ваших отношениях с вашими клиентами. пользователи/клиенты.
• Это менее ресурсоемко и более естественно для вашей органичной организации. В отличие от «революции» и гигантских управленческих инициатив, это может лучше поддерживать доброжелательность команды. Благодаря этому хороший дизайн кажется правильным , а не просто очень сложной работой.

• Никто!
• Просто шучу. Как видите, мы не дошли до «идеальной» фазы дизайнерской нирваны в этой модели. Более консервативная модель «Эволюция» дала нам хороший дизайн быстрее и проще, но, возможно, мы не воспользовались некоторыми возможностями «большой идеи», которые в противном случае могли бы быть у нас.
• Иногда работа в малом масштабе и отсутствие планирования «большого видения» может привести к тому, что вы упустите некоторые зависимости и/или возможности на более позднем этапе эволюции вашей дизайн-системы. Есть способы смягчить это — например, иметь какое-то видение, отличное от «маленьких шагов», — о котором я расскажу позже в более подробном посте.
• Иногда «старый» дизайн вашего продукта действительно очень плох, поэтому он может даже не быть хорошей отправной точкой. (Это заманчивый мысленный путь, но я бы отговаривал вас от этого: в большинстве случаев, если вы работаете даже над относительно успешным продуктом, что- то в старом дизайне работает хорошо, нравится вам это или нет. ).

Ваша задача — улучшить впечатления клиентов и пользователей от вашего продукта. Если вы стремитесь к лучшему в каждом маленьком дизайне, а затем сжигаете кучу инженерных ресурсов, воплощая эти изменения в жизнь, вы можете «тратить» эти ресурсы плохо и тем самым ограничивать объем работы, которую вы можете сделать, чтобы улучшить другие вещи для ваших пользователей. . Лучше ли сделать один пользовательский поток идеальным , чем три пользовательских потока ? Может быть, для вас, но, вероятно, не для ваших пользователей.

Если вы будете более реалистичны в своей дизайн-системе — построите ее на основе существующих основ и сохраните ее удобной для перехода, — вы сможете быстрее внедрить новую систему, и вы (и ваши пользователи) сможете начать пожинать плоды.

Так что вперед и развивайся!

Обновление (через год или около того)

Я написал еще одну статью об этой дизайн-системе, над которой работал для Hired — тот же проект, который вдохновил меня на создание этой статьи «Эволюция» годом ранее.

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