Глава 5: Поддержка системы дизайна (часть 2)
← Предыдущая часть | Следующая часть →
Перед вами перевод книги Atomic Design Брэда Фроста, разработчика интерфейсов, поклонника мобильного интернета и создателя методики «Атомарный дизайн».
Если вы здесь впервые, то лучше начните сначала.
Придайте системе официальный статус
Возможно, ваше руководство по стилю начнет свою жизнь в качестве побочного проекта, появится на хакатоне, или его создаст кто-то из амбициозных членов вашей команды. При этом вашему заказчику или боссу даже не обязательно знать, что вы создаете целую систему дизайна и сопутствующую библиотеку паттернов. Помните: лучше просить прощения, а не разрешения!
Будет прекрасно, если система появится естественным путем, но чтобы она стала по-настоящему эффективной и привела вашу компанию к долгосрочному успеху, ей нужен официальный статус. Лишь в этом случае система будет восприниматься как полноценный продукт, и, следовательно, на него будут выделяться время, бюджет и исполнители.
Убедить заказчиков потратить большую сумму денег и выделить ресурсы на разработку системы дизайна чрезвычайно сложно. Так что же делать? Вот вам инструкция:
- Спроектируйте систему.
- Покажите ее пользу.
- Придайте ей официальный статус.
Давайте разберем эти шаги подробнее.
# 1. Спроектируйте систему
С чего-то нужно начинать, поэтому иметь на руках хоть какой-то прототип куда лучше, чем пространно рассуждать о нем.
- Выберите пилотный проект для создания системы дизайна;
- Пройдите по шагам, перечисленным в главе 4;
- Обдумайте философию атомарного дизайна, подробно описанную в главе 2
— так вы заложите прочный фундамент для последовательной системы дизайна и библиотеки паттернов, которые помогут вашей команде работать эффективнее.
После этого оформите паттерны пользовательского интерфейса в библиотеку паттернов и придайте ей презентабельный вид. Потратьте на это пару дней, и вам воздастся сторицей, ведь в результате у вас получится что-то, что можно продемонстрировать заказчику. Повторюсь: показывайте, а не рассказывайте.
# 2. Покажите пользу системы
С системой дизайна, которая только-только создается, но которую уже можно «пощупать», вы сможете вести более содержательные переговоры с людьми, которые отвечают за деньги, планирование и ресурсы. Вы сможете рассказать, как именно система дизайна уже помогла сэкономить время и деньги (см. «Как преподносить идею» в главе 4), а затем описать то, как масштабировать экономию в случае, если компания даст добро на запуск полноценной официальной системы дизайна.
Попросите поддержки от членов команды разных специализаций при обсуждении первых результатов применения системы, а также привлеките всех, кто впоследствии будет пользоваться благами от развития системы дизайна.
# 3. Придайте системе официальный статус
Итак, вы доказали ценность системы дизайна и составили дорожную карту ее развития. Если повезет, ваша компания согласится придать ей официальный статус.
Заручившись поддержкой на самом высоком уровне, вы сможете доработать план, привлечь исполнителей, установить четкую стратегию управления проектом, дополните дорожную карту продукта.
Стоит отметить, что все может выйти совсем не так, как вы ожидаете. Несмотря на очевидную ценность внедрения системы и наличие конкретного плана действий, ваше руководство все равно может зарубить инициативу. Не отчаивайтесь. Вы проиграли битву, но можете выиграть войну. Ваша команда должна самостоятельно продолжать развивать систему дизайна, пока ее значимость не перестанет вызывать малейшие сомнения. По мере того, как все больше людей будут извлекать пользу из наличия системы, вы получите мощную поддержку «снизу».
# Команда для работы над системой дизайна
Если инициатива по развитию системы дизайна получила «добро», пришло время подобрать правильных людей и привести в порядок рабочие процессы.
Разработчики и пользователи системы дизайна
Перво-наперво, важно понять, что при любом раскладе будут люди, которые работают над созданием и поддержкой системы дизайна, и те, кто станут ее пользователями. Эти две группы могут пересекаться. Тем не менее, важно разграничить роли создателей и пользователей.
Говоря о более тесном взаимодействии, я вновь неизбежно слышу, как люди из крупных организаций говорят: «Но, Брэд, сотни (или даже тысячи) разработчиков работают с нашим продуктом. Невозможно заставить всех этих людей сотрудничать и тесно взаимодействовать».
И они правы. Было бы идеально, если бы всей процессы внутри компании стали гибче и лучше побуждали к сотрудничеству. Однако, организационная сложность такой инициативы настолько велика, что это нереально. Следует понять вот что: не все сотрудники компании обязаны вносить свой непосредственный вклад в систему дизайна, но кто-то (скорее всего, несколько человек) должен взять на себя ответственность за нее.
Разработчики системы дизайна — это те, кто создает, поддерживает и управляет системой. Им необходимо тесно сотрудничать, чтобы система была удобной, гибкой, масштабируемой и отвечала потребностям пользователей и бизнеса. Пользователи системы проектирования — это сотрудники компании, которые возьмут систему в работу и начнут применять паттерны интерфейса для конкретных целей.
Между разработчиками системы дизайна и ее пользователями нужно наладить тесное рабочее взаимодействие, чтобы гарантировать, что паттерны, входящие в систему, релевантны, а вся документация ясна.
Разработчики обеспечивают общую целостность системы дизайна, в то время как пользователи ориентированы на конкретные способы ее использования. Джина Болтон из Salesforce очень хорошо описала отношения между разработчиками и пользователями:
Система дизайна влияет на наш продуктовый дизайн, а наш продуктовый дизайн влияет на систему дизайна. ~ Джина Болтон, Salesforce
Обе стороны вопроса имеют решающее значение для успеха, поэтому важно, чтобы между разработчиками и пользователи установились здоровые отношения, которые предполагают сотрудничество.
Разработчики системы дизайна
Кто обновляет систему дизайна? Кто утверждает изменения? Кто общается с пользователями системы, чтобы убедиться, что она отвечает их потребностям? Кто решает, какие паттерны оставить, какие нуждаются в настройке, а от каких пора избавиться?
Ответы на эти вопросы в значительной степени зависят от размера и политики вашей компании.
Крупные компании могут себе позволить выделить серьезные ресурсы на управление системами дизайна. К примеру, Salesforce содержит отдельную команду для работы с системой дизайна, в которую в настоящее время входит примерно дюжина штатных сотрудников. Эта команда отвечает за управление системой и следит, чтобы она соответствовала потребностям внутренних продуктовых команд и внешних разработчиков, которые работают на платформе Salesforce. Когда система дизайна обслуживает тысячи пользователей, выделить несколько штатных сотрудников для управления и развития системы — идея, по меньшей мере, здравая.
Небольшие компании вряд ли выделят целую команду на обслуживания системы дизайна. Сотрудники маленьких компаний вынуждены периодически примерять на себя разные роли, поэтому управление системой дизайна скорее всего станет еще одной задачей. Возможно, это звучит, как дополнительное бремя: «Отлично… Еще одна задача, за которую я несу ответственность без повышения зарплаты!» Однако, именно эту задачу стоит принять с радостью, поскольку она повышает эффективность и качество всей остальной работы. Да здравствуют системы дизайна!
Как правило, разработчики систем дизайна в небольших организациях — это старшие сотрудники, у которых есть опыт принятия взвешенных решений и соответствующие полномочия.
Кроме того, существуют внешние агентства, подрядчики и консультанты. Какова их роль, когда речь идет о долгосрочном обслуживании системы дизайна клиента? С одной стороны, внешние партнеры находятся в невыгодном положении, ведь фактически они не работают в компании своего клиента. Успешная система дизайна должна стать частью ДНК организации, а поскольку любые третьи стороны существуют за пределами стен компании, их влияние ограничено.
С другой стороны, внешние подрядчики могут составить адекватную оценку, которую порой трудно получить, находясь внутри компании. Именно в этом заключается сильная сторона аутсорса. Работая консультантом, я разрабатываю стратегии долгосрочной поддержки систем дизайна разных компаний, помогаю найти нужных людей и правильно организовать процессы. В то время как долгосрочный успех системы в конечном итоге зависит от самой компании, внешние подрядчики могут научить «ловить рыбу», дать важные стратегические рекомендации, обратную связь и оценку.
Пользователи системы дизайна
Кто использует систему дизайна для создания новых функций и приложений? Кто обсуждает с разработчиками возникающие проблемы и делает запросы на новые функции?
И вновь ответы на эти вопросы во многом зависят от размера и структуры вашей организации.
Пользователи системы дизайна могут быть одновременно ее разработчиками, отдельными командами в вашей организации, дизайнерами и разработчиками младшего уровня, партнерскими агентствами, внешними центрами разработки или другими сторонними командами.
Несомненно, вовлеченность пользователей в создание системы дизайна будет различаться. Вы можете работать над одним-единственным продуктом в крошечном стартапе — тогда ваша команда будет одновременно и создавать, и использовать систему дизайна. Или вы можете работать в крупной международной корпорации с разбросанными по всему миру командами разработчиков и сторонними партнерами. Если это так, тогда разработчики и пользователи системы будут редко (если вообще когда-либо) пересекаться. Это означает, что качественная документация и масштабное видение картины будут иметь гораздо большее значение.
Одним из главных преимуществ создания продуманной системы дизайна является то, что она позволяет организациям масштабировать лучшие практики: адаптивность, доступность, производительность, UX, эргономику и т. д. Все это включается в систему, а пользователи просто берут нужные паттерны и пожинают плоды. Таким образом для продуктивной работы рядовым пользователям системы не обязательно нужно быть разработчиками или дизайнерами высокого уровня. Система дизайна служит средством контроля качества, которое помогает пользователям применять лучшие практики вне зависимости от их квалификации.
# Структура команды, работающей над системой дизайна
Чтобы успешно управлять, поддерживать и развивать систему дизайна вам потребуется команда специалистов из разных областей. У всех направлений работы в компании, будь то UX, графический дизайн, контент, фронтенд, бэкенд, менеджмент продукта, управление проектами или что-то еще, есть свои уникальные особенности, которые, без сомнения, будут влиять на структуру работы. Очень важно учесть эти особенности в системе дизайна, но вовсе не обязательно настаивать на том, чтобы специалисты из каждой области были постоянными участниками разработки.
Специалистам ряда областей придется принимать активное участие в работе над системой, в то время как другие возьмут на себя скорее роль консультантов. Тем, кто отвечает за проектирование и создание пользовательского интерфейса — UX-дизайнерам, графическим дизайнерам, фронтенд-разработчикам — придется поработать. Они будут выполнять основную работу и выпускать обновления системы дизайна. Им предстоит сотрудничать и координировать свои действия с другими направлениями (как описано в главе 4), чтобы система отвечала целям и потребностям бизнеса.
С теми, кто не столь активно вовлечен в непосредственную работу, необходимо провести интервью и убедиться, что их пожелания отражены в системе.
Бэкенд-разработчики должны сообщать команде о любых архитектурных решениях, которые повлияют на пользовательский интерфейс. Руководители должны информировать команду о важных инициативах, которые повлияют на роль и использование системы. А пользователи системы дизайна, естественно, должны давать обратную связь разработчиками, чтобы система удовлетворяла запросам при разработке конкретных реальных продуктов.
Над переводом работают Ольга Кокоулина и Ринат Шайхутдинов.
Если вам понравился перевод, дайте нам знать — нажмите кнопку Clap в левой части экрана.
Видеокурсы и практика по дизайну интерактивных систем: ux/ui, веб-дизайн и бренд-дизайн
Вас ждет плотная проектная практика по анимации интерфейсов, дизайну сайтов, а также мобильных и веб-приложений. Под руководством наставников в стиле «смотри и повторяй»!
Breezzly — это среда для тренировки digital-навыков. Здесь вы встретите комплекты видеокурсов в актуальных инструментах интерактивного дизайна, среди них Figma, Principle и Invision Studio. А каждый проект — это живой кейс с историей, собранной по горячим следам!
