Smashing Podcast Эпизод 7 с Эми Хьюп: Что такое система государственного проектирования?

Вы когда-нибудь задумывались, как системы дизайна используются в правительстве? Кроме того, если вы хотите задокументировать дизайн-систему как можно лучше, как бы вы это сделали? Я разговаривал с защитником Design Systems Эми Хьюп, которая поделилась своими советами и извлеченными уроками.

Показать примечания

• Система дизайна GOV.UK
• Следите за Эми в Твиттере
• сайт Эми

Еженедельное обновление

• «Понимание CSS Grid: создание контейнера сетки» , Рэйчел Эндрю.
• «Контрольный список производительности внешнего интерфейса 2020» , Виталий Фридман.
• «Почему вы должны выбрать HTML5 <article> вместо <section>» , Брюс Лоусон
• «Раздвоение личности бруталистской веб-разработки» , Фредерик О'Брайен.
• «Как создать и развернуть приложение Angular Material» , Шубхэм

Стенограмма

Дрю Маклеллан: она специалист по контенту и защитник систем дизайна, последние три года работала старшим дизайнером контента в государственной цифровой службе. В то время она руководила стратегией контента для системы дизайна GOV.UK, включая простой и всеобъемлющий подход к документации. Ранее она работала в компании по защите интересов потребителей Which? где она писала обо всем, от компостирования до перевозки. И новая роль на 2020 год заключается в том, что она становится менеджером проекта Babylon Health Design System, DNA.

Дрю: Она опытный повар, пользователь Instagram и знает, как использовать язык, чтобы сделать услуги доступными и инклюзивными. Но знаете ли вы, что однажды она пела бэк-вокал для Билли Рэя Сайруса? Мои потрясающие друзья, пожалуйста, поприветствуйте Эми Хьюп. Привет, Эми. Как твои дела?

Эми Хьюп: Я разбиваю. Спасибо.

Дрю: Сегодня я хотел поговорить с вами о роли систем проектирования в государственных организациях в целом, но конкретно о системе проектирования GOV.UK, с которой, как я знаю, вы много работали. Я думаю, прежде всего, что включает в себя дизайн-система GOV.UK? И каково было ваше участие в этом, когда вы были в GDS?

Эми: Так что это охватывает все виды вещей. Так что я думаю, что наиболее очевидным представлением этого является веб-сайт GOV.UK/design-system. И там вы найдете всю необходимую документацию. Итак, все рекомендации по дизайну, компоненты и шаблоны, часть кода, множество примеров и множество советов по его использованию. Но в более широком смысле это также включает в себя такие вещи, как набор прототипов, который представляет собой инструмент прототипирования, который используется в правительстве для создания прототипов HTML и CSS. Итак, прототипы довольно высокого качества, и у него также есть свой собственный интерфейсный фреймворк, который называется GOV.UK Front End. Вот и весь код, который они используют для создания сервисов.

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

Дрю: Итак, каково было ваше участие в этом, когда вы были в GDS? Где ты пролез в эту систему?

Эми: Думаю, все это произошло случайно. Итак, я присоединился к Gov в качестве дизайнера контента в январе 2017 года, и когда я пришел в GDS, я намеревался присоединиться к командам по контенту Gov UK. Так что я подумал, что собираюсь начать писать руководство для системы, и это было моей мечтой. Это было то, что я хотел сделать. Затем я прибыл в первый же день и попал в эту маленькую группу защиты, которая называлась командой шаблонов и инструментов Руководства по обслуживанию.

Эми: На тот момент дизайн-системы еще не существовало, но у нас были наши шаблоны дизайна и некоторые кусочки, которые болтались в разных местах. Было стремление попытаться собрать эти вещи воедино. Так что меня включили в эту команду в качестве контент-дизайнера. Я не знал, что такое шаблон проектирования, ничего не знал о коде, вообще ничего не знал о веб-дизайне. Все, что я действительно знал, было довольным.

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

Дрю: Так что же означает разработка контента в таком контексте? Какие повседневные задачи вы решали?

Эми: На самом деле все что угодно. Я имею в виду, что были недели, я думаю, когда я не писал ни единого слова, и это было больше просто исследование и встреча с нашими пользователями и попытка понять, что они хотели от системы дизайна. Так что да, если не вдаваться в подробности, ранее уже предпринимались попытки создать что-то вроде дизайн-системы GOV.UK, поэтому мы и получили такой немного несопоставимый набор ресурсов.

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

Эми: Многое из этого было связано с нашими исследованиями [неразборчиво 00:05:07], и мы сидели в интервью с пользователями, делали заметки и разговаривали с людьми, и просто понимали, что им нужно. Затем были дни, когда мне действительно удавалось сидеть за клавиатурой и писать рекомендации по некоторым вещам, что тоже было приятно. Но да, для меня это было совсем другое. Как вы упомянули во вступлении, я работал в компании Which? Так что это была гораздо более традиционная редакторская роль, и я привык работать с длинными формами контента и просто писать очень длинные статьи и куски. Так что да, это было довольно большое изменение. Это был большой скачок от этого.

Дрю: Значит, в данном контексте ваши пользователи — это люди, работающие в различных государственных организациях? Это правильно? Разные ведомства в правительстве?

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

Дрю: Считаете ли вы, что проектирование или работа над дизайн-системой для правительства по существу чем-то отличается от дизайн-системы для небольшой компании или крупной корпоративной компании?

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

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

Эми: Конечно, когда мы впервые выпустили его, мы увидели фрагменты нашего руководства и кода, появляющиеся в дизайн-системах других людей. Мне потребовалось некоторое время, чтобы почувствовать себя в порядке. Думаю, сначала я подумал: «Что происходит? Почему эти люди берут наши вещи?» Но на самом деле сейчас мне это очень нравится. Я рассматриваю это как большой комплимент, и я думаю, что действительно хорошо повторно использовать то, что вы можете. Но да, я думаю, это странный мир для тех, кто привык работать в более коммерческой среде.

Дрю: Я полагаю, что тот факт, что это по существу система, финансируемая государством, означает, что она однозначно подходит для того, чтобы публика брала и использовала ее, но также и во всем мире, вы видели много использования за пределами Великобритании?

Эми: Да, да, по всему миру было несколько действительно захватывающих проектов, которые подхватили это. Так что я знаю, что правительство Новой Зеландии использовало их довольно много. Я не уверен, на каком этапе они находятся в данный момент, но, безусловно, я видел их раннюю систему проектирования данных, и они действительно использовали много наших рекомендаций и нашего кода, наших макетов и прочего. Я думаю, что правительство Нидерландов также использует дизайн-систему GOV.UK в первую очередь в качестве первого доказательства концепции. Австралийское правительство начало со всех наших руководящих принципов по взносам и в некотором роде адаптировало их на основе своих исследований. Так что мы смогли вернуть кое-что из этого. Да, так что это стало довольно глобальным. Это увлекательно.

Дрю: Будете ли вы учитывать тот факт, что люди будут использовать его при принятии решений о следующем этапе развития событий? Повлияло бы на ваши решения то, что на самом деле вашей аудиторией внезапно стало не только правительство Великобритании, но и аудитория по всему миру?

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

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

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

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

Дрю: Я полагаю, что большая часть роли дизайн-системы заключается в том, чтобы документировать принятые дизайнерские решения, чтобы эти решения могли быть реализованы, поняты и использованы людьми. Итак, я полагаю, что дизайн-система — это не что иное, как артефакт документации, не так ли? Это принятие тех решений, которые были приняты, и объяснение их таким образом, чтобы люди могли использовать их повторно. Как вы, как команда, подошли к разработке системы как своего рода артефакта документации? Как вы документировали то, что делали?

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

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

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

Дрю: Правильно ли я понимаю, что различные правительственные ведомства на самом деле не обязаны внедрять систему дизайна? Вы на самом деле должны эффективно продать его им и убедить использовать его?

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

Дрю: Я полагаю, что с этой целью один из способов, которым вам удалось это сделать, — это поощрение вклада. Это правильно?

Эми: Да, определенно. Так что я большой поклонник вклада в дизайн-системы. Я думаю, что это действительно интересно, и да, конечно, в команде мы проделали большую работу, чтобы сделать возможным внести свой вклад в дизайн-систему GOV.UK. Одним из реальных преимуществ, которые мы увидели в этом, было то, что сеть выступает за расширение системы дизайна. Поэтому, когда вы привлекаете кого-то, чтобы внести свой вклад в это, и они тогда чувствуют себя как бы более заинтересованными в этом и в том, что мы получили, эти люди затем шли в свои команды и становились нашими лучшими продавцами почти потому, что они чувствовали, что они небольшой кусочек, и у них было, что показать людям, а затем они поощряли других людей вносить свой вклад. Таким образом, этот эффект оказывается довольно экспоненциальным. Да. Поэтому мы приложили много усилий, чтобы сделать это возможным.

Дрю: Что вы делали, чтобы поощрять вклад?

Эми: Мы начали очень рано. Поэтому задолго до того, как у нас появилась общедоступная система дизайна, мы начали взаимодействовать с людьми, которые, как мы думали, будут заинтересованы в содействии. Здесь я должен упомянуть, что у нас в команде был блестящий сервис-дизайнер. Она присоединилась к нам, в данный момент я не собираюсь уточнять даты, но я думаю, что она работала с нами в течение всего 2018 года, и ее зовут Игнатия, и она просто проделала фантастическую работу. и вовлечение людей. Так что одна из вещей, которые она сделала, заключалась в том, чтобы пойти и определить все различные модели в правительстве и все различные варианты этих моделей. Так что выйти и как бы сказать, хорошо, есть, есть 10 разных способов попросить адрес в правительстве. Давайте посмотрим на них все вместе и решим, какой подход, по нашему мнению, является наиболее подходящим.

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

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

Дрю: И если говорить практически об управлении этими вкладами сообщества, были ли какие-либо инструменты или процессы или что-то еще, что помогало в этом?

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

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

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

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

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

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

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

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

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

Дрю: Одна из вещей, которая меня всегда очаровывала, особенно в системах проектирования, которые имеют такую ​​большую и разнообразную аудиторию, как система дизайна GFI UK, — это процесс распространения изменений по всей системе. Итак, если вы, например, найдете улучшение доступности, которое вы могли бы сделать в определенном шаблоне, и сделаете это в системе дизайна, как вы гарантируете, что это будет распространено на такую ​​широкую аудиторию? Это то, с чем у вас есть опыт?

Эми: Да. Итак, еще раз, я думаю, что мы в команде системы проектирования GOV.UL уделяем много внимания тому, как это будет работать. Должен быть честным, во многом это связано с технической реализацией, и я определенно не тот человек, чтобы так много говорить о технических аспектах команды. Я нахожу, что есть два лагеря с дизайн-системами, и есть лагерь, который говорит: давайте выпустим материал как можно быстрее. Давайте просто сделаем его открытым, как только сможем, и это остановит дублирование усилий и умножение усилий, и тогда мы сможем итерировать его по ходу дела. Затем я думаю, что есть немного более своего рода лагерь «давайте двигаться немного медленнее», в котором я думаю, что я нахожусь, который благоприятствует откладыванию выпуска материала до тех пор, пока у вас не будет определенного уровня уверенности в нем.

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

Эми: В то время как я думаю, что если вы можете показать, что вы внимательно относитесь к тому, что вы выпускаете, и вы выпускаете изменения только тогда, когда это необходимо, тогда у вас есть эта добрая воля, и тогда люди будут более охотно делать обновления и прочее, я думаю. Но да, я имею в виду, что я знаю, что много работы было потрачено на то, чтобы процесс обновления был достаточно гладким и простым для реализации в дизайн-системе GPV.UK. Думаю, я просто не тот человек, чтобы говорить об этом.

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

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

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

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

Дрю: И при этом вы, очевидно, получите отзывы об этой документации. Есть ли у вас какие-либо предложения о том, как бы вы подошли к исправлению ситуации на основе этой обратной связи? Is there anything specific that you'd be looking for in the feedback to understand how well your documentation had worked?

Amy: Yeah, I mean there's a few things I think to watch out for. I think it's is really important to separate preferences and people perhaps not liking the documentation from people actually not being able to use it. So I think any task-based testing with documentation is better because it might be that actually somebody complains their way through an entire guide but they still complete the task that you've set them. That's not to say that that doesn't matter. If they wanted to do the thing but they actually hated the process, then you of course need to take that into consideration. But I think that some people and I'm probably one of them just can't help themselves and will start, especially if it's a content designer, I think we can't kind of ever quite put that content design mentality aside.

Amy: So I definitely have a tendency to start live editing stuff if I'm supposed to be participating as research candidate on it. So I think yeah, separating preference from actual kind of usability and blockers is quite important. I think that making sure that your really interrogating the need to make changes and to update things. I think sometimes if somebody is particularly engaged with a design system, depending on the sort of person they are, they can be quite vocal about how they think it could be better or how they think that how they would've done it perhaps or how it could be clearer. I think it can be quite, especially if you're sort of trying to build Goodwill and you're in that early stage with the design system, it can be quite tempting to just immediately respond to that feedback and do what they say or try and make it clearer.

Amy: But then you can end up building it too far in the direction of the loud minority and I think actually really saying like how many people have got this problem? What evidence do we have that this isn't working for people? And does that warrant a kind of update? I think yeah, trying to resist the temptation to respond to every comment and bit of criticism that you receive is quite important too, yeah.

Drew: I suppose I'm a common theme here with design systems that enable consistent design and give you a reusable resource in your design and about accepting contributions that make those designs stronger and implementing accessible design choices and documenting your design to make it easy to access and use. It really all comes back to sort of inclusion, would you say that was fair that including people as much as possible?

Amy: Definitely. Да. I mean I think that a good design system is a representative design system and I don't think it's possible to achieve representation by acting on people's behalf. I think you really need to try and involve people in the process as much as possible. I think often for people working on design systems and certainly it was the case for us at the GOV.UK design system, you tend to be one step removed from your organizations end users. So if you think for the GOV.UK design system, the people that the design system is ultimately there to serve are members of the public and citizens and people using government services. But we in our team, we're really working directly with those people. Most of the time our direct users are people working in the civil service. So making sure that you've got really strong feedback loops between your direct users and then their users to ensure that it's representative I think is really important and I think that's where inclusion comes in and yeah, I completely agree. I think it's a really central thing, like I can't imagine how you could build a successful design system without a focus on that.

Drew: Is there anything else that you'd like to share with us about your work on the GOV.UK design system?

Amy: I think my sort of main takeaway from working on it is that, I hate using the word physical when I'm talking about anything on the web, but the the visual representation of a design system I think can end up being the thing that we all get really fixated on. We look at how it's coded and we look at how it's organized and what it looks like and how it's documented and what the design is. I think that obviously that stuff is really important. I think that it's the thing that you can look at and show people and share. So it's easy to see why we get fixated on that. But I really think that the most important factor of it is the people. I think that having inclusive processes and making sure that you're kind of fostering safe discussion spaces and that you're giving people an opportunity to get involved in the work and to participate and feel motivated to help you with it and to feel this sense of ownership over it.

Amy: I think all of that stuff is really important and all of that stuff really happens outside of the code and outside of the documentation. So yeah, I think my key takeaway from working on the GOV.UK design system is how much of it is really just people work and not really anything to do with guidance and code.

Drew: Here's at Smashing we're all about learning. So what have you been learning lately?

Amy: Lately I've been learning a lot about productivity and focus. I think definitely towards the end of last year I became aware that I was really plate spinning and luckily I don't think I smashed any of those plates but I found myself kind of working quite chaotically and moving around lots of different projects and saying yes to everything. So this year is the year that I want to really improve my focus. So I'm trying to learn a little bit about mindfulness and organization and how to say no to things strategically so that I don't get overwhelmed and too distracted. I've started bullet journaling so I've really become the full 2020 cliche at this point. So that's what I'm learning at the moment.

Drew: If you dear listener, would like to hear more from Amy, you can follow her on Twitter where she's @Amy_Hupe or find her on the web at amyhupe.co.uk. Thanks for joining us today. Amy, do you have any parting words for us?

Amy: Stay cool. Какой? Why did I say that? Just came out, it just came out.