エイミー・ヒュープとポッドキャストエピソード7を壊す：政府の設計システムとは何ですか？

公開: 2022-03-10

簡単なまとめ↬SmashingPodcastのこのエピソードでは、英国政府の設計システムを見ていきます。政府内で設計システムはどのように使用されていますか？それは私たちが商業部門で働く方法と何か違いがありますか？ドリュー・マクレランが設計システムの提唱者であるエイミー・ヒュープと話します。

政府内で設計システムがどのように使用されているのか疑問に思ったことはありませんか？また、設計システムを可能な限り最善の方法で文書化したい場合、どのように行いますか？デザインシステムの提唱者であるエイミー・ヒュープに話を聞きました。エイミー・ヒュープは彼女のアドバイスと学んだ教訓を共有しています。

メモを表示

GOV.UKデザインシステム
Twitterでエイミーをフォロー
エイミーのウェブサイト

毎週の更新

「CSSグリッドの理解：グリッドコンテナの作成」 、レイチェルアンドリュー
ヴィタリー・フリードマンによる「フロントエンドパフォーマンスチェックリスト2020」
BruceLawsonによる「<section>ではなくHTML5 <article>を選択する理由」
フレデリック・オブライエンによる「ブルータリストのウェブ開発のスプリットパーソナリティ」
Shubhamによる「 AngularMaterialアプリケーションを作成してデプロイする方法」

トランスクリプト

エイミー・ヒュープの写真 Drew McLellan：彼女は、政府デジタルサービスでシニアコンテンツデザイナーとして過去3年間働いた、コンテンツスペシャリストおよびデザインシステムの支持者です。その間、彼女はGOV.UKデザインシステムのコンテンツ戦略を主導しました。これには、ドキュメントへの直接的で包括的なアプローチが含まれます。彼女は以前、消費者擁護会社で働いていましたが、どれですか？彼女は堆肥化から運搬まですべてについて書いた。そして2020年の新しい役割は、彼女がバビロンヘルスデザインシステム、DNAのプロジェクトマネージャーに就任することです。

ドリュー：彼女は熟練した料理人であり、Instagrammerであり、言語を使用してサービスをアクセス可能で包括的なものにする方法を知っています。しかし、彼女がかつてビリー・レイ・サイラスのバックボーカルを歌っていたことを知っていましたか？私の壊滅的な友人、エイミー・ヒュープを歓迎してください。こんにちはエイミー。元気ですか？

エイミー・ヒュープ：私は壊している。ありがとう。

ドリュー：それで、今日、政府機関内での設計システムの役割についてお話ししたいと思いますが、具体的には、GOV.UKの設計システムについてお話ししたいと思います。まず第一に、GOV.UKのデザインシステムには何が含まれているのでしょうか。そして、あなたがGDSにいる間、あなたはそれとどのように関わっていましたか？

エイミー：それはあらゆる種類のものを網羅しています。ですから、それを最も明白に表現しているのは、一種のWebサイト側、つまりGOV.UK/design-systemだと思います。そして、そこにはあらゆる種類のドキュメントがあります。したがって、すべての設計ガイドライン、コンポーネントとパターン、およびコードの一部、多くの例、およびその使用方法に関する多くのアドバイスが表示されます。しかし、それよりも広い意味で考えると、政府でHTMLやCSSのプロトタイプを作成するために使用されるプロトタイピングツールであるプロトタイプキットなども含まれます。非常に忠実度の高いプロトタイプであり、GOV.UKフロントエンドと呼ばれる独自の種類のフロントエンドフレームワークもあります。これが、サービスの構築に使用するすべてのコードです。

エイミー：でも、私はデザインシステムをもっと全体的に考えるのが好きです。したがって、そのすべてだけでなく、その周りにあるすべてのプロセスもあります。つまり、人々がそれにどのように貢献するか、そして人々がそれが存在することをどのように知るようになるかなどです。養子縁組や気づきなど、あらゆるものがあります。ですから、人々が政府でサービスを設計および構築できるようにするすべてのものは、私がそれをどのように定義するかということです。

ドリュー：それで、GDSにいたときのあなたの関わりは何でしたか？そのシステムのどこにスロットを入れましたか？

エイミー：それはすべて偶然に起こったと思います。そこで、2017年1月にコンテンツデザイナーとして参加しました。GDSに来たときの私の意図は、実際にはGovUKコンテンツチームに参加することでした。それで、システムのガイダンスを書き始めようと思ったのですが、それが私の夢でした。それが私がやりたかったことでした。それから私は初日に到着し、サービスマニュアルパターンとツールチームと呼ばれるこの小さな保護チームに飛び込みました。

エイミー：その時点ではデザインシステムは存在していませんでしたが、デザインパターンといくつかの断片がさまざまな場所でノックアウトされていました。それらをまとめようとする野心がありました。それで私はコンテンツデザイナーとしてそのチームに入れられました。私はデザインパターンが何であるかを知りませんでした、コードについて何も知りませんでした、ウェブデザインについて本当に何も知りませんでした。私が本当に知っていたのは満足だけでした。

エイミー：それはかなり急な学習曲線でした。私は次の6か月から1年を費やして、チームがプロトタイプを作成し、どのように編成およびレイアウトするか、ガイダンスをどのように作成するかを理解するのを手伝ったと思います。そのようなものすべて。そして、その中でコンテンツに取り組む中で、貢献の側面も検討し始めました。それで、人々がそれにどのように貢献し、人々がそれを発見し、私たちと連絡を取り合うようになるか、そして彼らが私たちと連絡を取り、それをより良くしようとしたときに私たちが何をするか。

ドリュー：では、そのようなコンテキストでコンテンツをデザインすることには何が含まれるのでしょうか？あなたが取り組んでいた日常の仕事はどのようなものでしたか？

エイミー：そういうことは本当に。つまり、私が一言も書かなかった時期があったと思います。それは、ユーザーを調査して会い、彼らがデザインシステムに何を求めているのかを理解しようとするだけでした。そうですね、あまり深く掘り下げることなく、以前はGOV.UKデザインシステムのようなものを作成する試みがありました。そのため、この種のわずかに異なるリソースのセットになりました。

エイミー：どういうわけか、これらのものはかなり広がってしまいました、そしてそれは本当にこれらのもののために行く中心的な場所として見られたそれらの1つではありませんでした。その多くは、以前に何が起こったのか、そしてなぜそれらのことが必ずしも私たちが望んでいた方法でうまくいかなかったのかを理解しようとしていました。私たちの既存の風景のどの部分が人々のために働いていて、どの部分がうまくいかなかったかを理解しようとしています。

エイミー：それで、私たちの調査[inaudible 00:05:07]で多くのことが行われ、ユーザー調査のインタビューに参加し、メモを取り、人々と話をし、彼らが何を必要としているかを理解しました。それから、私が実際にキーボードの前に座って、いくつかのことについていくつかのガイダンスを書くようになった日がありました。それも良かったです。しかし、ええ、それは私にとっては非常に異なっていました。イントロでおっしゃったように、私の経歴はどちらで働いていましたか？ですから、それははるかに伝統的な編集の役割であり、私は長い形式のコンテンツに取り組み、本当に長い記事や作品を書くことに慣れていました。そうそう、それはかなり大きな変化でした。それからの大きな飛躍でした。

ドリュー：では、このコンテキストでのユーザーは、さまざまな政府機関で働いている人々ですか？そうですか？政府内のさまざまな部門？

エイミー：うん。はい、そのとおり。ですから、働いている人々は、政府には25の異なる大臣部門があり、それから多くの機関や地方政府部門もあると思います。それで、私たちは公務員全体から本当に幅広い人々と話を広げて話そうとしていました。そうそう、それらの初期の頃にはたくさんの旅行がありました。

ドリュー：政府の設計システムの設計や作業は、本質的に、中小企業や大企業の設計システムとは何か違うと思いますか？

エイミー：そう思います。つまり、これまでの会話や行った会議などから収集できることから、すべてのデザインシステムはわずかに異なり、コンテキストは常にわずかに異なります。その点で政府も同じです。。しかし、ええ、私は、政府のために何かに取り組むことへのユニークな挑戦のいくつかは、まず第一にそれの規模であると思います。ですから、政府は非常に大きく、さまざまな種類の部門やそれらの組織の地理的な広がりがあるため、聴衆はおそらくあなたが持つことができる最大の数です。ですから、その規模は間違いなく少し違うものです。

エイミー：商業的に競争力がないという事実もあると思います。ですから、私たちはすべてを覆い隠そうとはしていませんでした。すべては可能な限りオープンで行われました。ええ、それはすべて大きなオープンソースプロジェクトとして実行されていますが、それは私にとっては少し珍しい概念でした。それに慣れるのに少し時間がかかりました。

エイミー：確かに、私たちが最初にそれをリリースしたとき、私たちのガイダンスとコードの一部が他の人のデザインシステムに現れるのを見るでしょう。私がそれについて大丈夫だと感じるのに少し時間がかかりました。最初は「どうしたの？なぜこれらの人々は私たちのものを取っているのですか？」でも実は今、私はそれが本当に好きです。それは大きな褒め言葉だと思いますし、できることを再利用するのは本当に良いことだと思います。しかし、ええ、それはあなたがより商業的な環境で働くことに慣れているときに入る奇妙な種類の世界だと思います。

ドリュー：それは本質的に公的資金によるシステムであるという事実は、それを利用して使用する一般の人々に独自に適していることを意味すると思いますが、英国以外でも世界中で多くの使用が見られましたか？

エイミー：ええ、ええ、それを取り上げた本当にエキサイティングなプロジェクトが世界中にいくつかあります。ですから、ニュージーランド政府がそれをかなり多く使用していることを私は知っています。現時点で彼らがどの段階にあるかはわかりませんが、確かに彼らの初期のデータ設計システムを見て、彼らは私たちのガイダンスやコード、レイアウトなどを実際にたくさん使用していました。オランダ政府も、主に最初の概念実証としてGOV.UK設計システムを使用していると思います。オーストラリア政府は、私たちの貢献ガイドラインのすべてから始めて、彼らの研究に基づいてそれらをある種適応させました。だから、私たちはそのようなもののいくつかを取り戻すことができました。ええ、それはかなりグローバルになりました。エキサイティングです。

ドリュー：人々が物事の次の段階の種類について決定を下すときにそれを使用するという事実を考慮に入れますか？それはあなたの決定に、実際にはあなたの聴衆が突然英国政府だけでなく、実際には世界中の聴衆になる可能性があるということを考慮に入れますか？

エイミー：それは間違いなく考慮事項であり、私たちが行っている特定のことについてチームとして非常に神経質になったことは確かだと思います。それを使用していました。しかし、個人的には、私たちが主に英国政府に奉仕するためにそこにいるということにあまり巻き込まれることはできないと思います。したがって、潜在的なオーディエンスのすべてを検討することは現実的ではありません。自分自身や自分のユーザーに必要な方法でそれを適応させるのは、チーム次第だと思います。しかし、確かに、テスト済みのものになる前に、物を捨てることについて非常に慎重に考える必要があります。

ドリュー：それで、この設計システムに取り組んだことで、当初の予想よりも広く使用されたという事実以外に、他の種類の驚きはありましたか？他に何かが湧き出て、それについてあなたを驚かせましたか？

エイミー：私にとって間違いなく目立ったのは、聴衆の範囲の広さでした。ですから、聴衆の大きさだけでなく、人々の知識レベルの変化、彼らのスキル、彼らの自信、彼らが行ったさまざまな種類の仕事、そして彼らが働いていた状況の種類のように。確かにそこにはたくさんのバリエーションがあると思います。私の認識では、このようなデザイナーのフロントエンド開発者のようなビジョンを頭の中に持っていたと思います。技術的な知識が豊富で、実際にはそれは1つのタイプのユーザーにすぎません。コンテンツデザイナーのような他の多くの人々がいて、物事は必ずしもそれの期待された聴衆ではありませんでしたが、主要なユーザーであることが判明しました。

エイミー：そうですね、それは間違いなく私にとって驚きだったと思います。それから、デザインシステムでこのように幅広いニーズを持つすべての人々にどのように対応できるかを考えることは、間違いなく非常に大きな課題でした。ええ、それはおそらく私の最大の驚きだったと思います。それから、私はそれと並んで、どれだけの人々がそれを自分のものとして採用するのを見たのかを推測します。ですから、私たちがかなり早く立ち上げた後、自分の部門やチーム内でそれを提唱している人や、それに貢献しようとしている人、そして私たちに連絡して方法を尋ねる人がたくさんいることに本当に嬉しく思いました。彼らはそれを自分のユーザーに適応させることができます。それは最初から本当にコミュニティが所有していると感じました、そしてそれは必ずしも私が期待したものではありませんでしたが、見る準備ができていたものでした。

ドリュー：設計システムの役割の多くは、行われた設計上の決定を文書化して、それらの決定を実装して理解し、人々が使用できるようにする方法としてのものだと思います。ですから、デザインシステムは何よりも重要だと思いますが、ドキュメントのアーティファクトではありませんか？それは、下された決定を取り、人々がそれらを再利用できる方法でそれらを説明しています。チームとして、一種のドキュメントアーティファクトとしてシステムを設計するためにどのようにアプローチしましたか？自分がしていることをどのように文書化しましたか？

エイミー：それは、そのドキュメントから人々が何を必要としているかを本当に明確に把握できる限りのことだと思います。ですから、これは、コンポーネントやパターンを一種の単一のタスクのように文書化することについて人々が話すさまざまなニーズがあるため、非常に幅広い対象者であると私が述べた時点に戻ります。しかし実際には、それを行うためのさまざまな方法がたくさんあり、考慮に入れる必要のあるさまざまなニーズがたくさんあります。ですから、例えば、「ああ、この背後にある研究を見たい」と言う人がいます。一部の人々にとって、それは数を意味します。彼らは、それが20の異なるサービスで使用されていることを知りたいので、製品マネージャーに、サービス内での実装に時間とお金を投資する価値があることを伝えることができます。

エイミー：それは彼らにとって、彼らがやや押し通そうとしている決定に対して、証拠に基づいた裏付けを得るということです。しかし、他の人々は、研究を理解すること、そしてそれが彼らの文脈に適切であるかどうか、そして見逃されたギャップやおそらく彼らが独自の状況で扱っているギャップを埋めるために埋める必要があるかもしれない追加の研究を本当に気にかけている人がいます。したがって、アプローチは、これらのさまざまなニーズをすべて理解し、それらの間で優先順位を理解し、ドキュメントから人々が持っているさまざまなさまざまな要件のすべてにどのように対応できるかを理解することだったと思います。誰にでも合うのは、1つの種類だけではありません。

エイミー：それで、これらすべてのニーズにどのように対処し、コンテンツを本当にうまく標識するかを考え出すことで、人々は自分たちにも関係のない部分をスキップできるようになりました。あなたがそのような幅広い聴衆に奉仕しようとしているとき、明らかにあなたはかなり多くの情報を提供することになります。ですから、それが本当によく標識され、整理されていることを確認することは、私たちがやっていることの非常に重要だったと思います。

ドリュー：それで、政府内のさまざまな部門が実際に設計システムを採用することを強制されていないことを理解しているのは正しいですか？あなたは実際にそれを彼らに効果的に売り、彼らにそれを使うように説得しなければなりませんか？

エイミー：ええ、少し複雑です。したがって、政府には政府サービス標準と呼ばれるものがあります。これは、特定の数を超えるユーザーがいるすべての政府サービスが、資金を調達し、アルファ、ベータ、そしてライブに移行するために満たす必要がある標準です。サービス標準のポイントの1つは、3週間前に残したもので、すでに頭から離れていますが、サービス標準のポイントの1つは、パターンとコンポーネントの再利用と、その内容の再利用について説明しています。すでにそこにあります。ですから、その点では、彼らはそれを使用せざるを得ませんが、それは緩く、評価者が誰であるかによって異なります。それほど義務付けられているわけではありません。私たちは皆、サービス評価のポイントをチェックするために、箱から出してすぐにパターンを再利用するのではなく、特定のコンテキストで最善を尽くすことを常に支持します。したがって、それを強制することは困難です。したがって、このアプローチは常にはるかに協調的であり、それは常に、人々の喉に押し付けられるのではなく、設計システムのサポートを構築し、アドボカシーを構築することでした。

ドリュー：そのために、あなたがそれを成し遂げた方法の1つは、貢献を奨励することだと思います。そうですか？

エイミー：ええ、もちろんです。ですから、私は設計システムへの貢献の大ファンです。それは本当に興味深いことだと思います。確かに、チームでは、GOV.UKの設計システムに貢献できるようにするために多くの作業を行いました。それから私たちが見た本当の種類の利点の1つは、デザインシステムのネット支持者が増えていることでした。ですから、誰かに貢献してもらい、彼らがそれに投資し、私たちが受け取ったものにもっと投資していると感じると、それらの人々はチームに出て行き、ほとんど彼らが持っているように感じるので、彼らは私たちの最高の営業担当者になりますそれのほんの一部であり、彼らは人々に見せるためのある種の何かを持っていて、それから彼らはより多くの人々に貢献することを奨励するでしょう。そのため、その効果はかなり指数関数的になります。うん。そのため、私たちはそれを可能にするために多大な努力を払いました。

ドリュー：貢献を促すためにどのようなことをしましたか？

エイミー：私たちは本当に早く始めました。そのため、パブリックデザインシステムを導入するずっと前から、関心のある貢献者と思われる人々と関わり始めました。ここで言及しなければならないのは、チームには優秀なサービスデザイナーがいたことです。彼女は私たちに加わってくれました、私は今のところ正しい日付を取得するつもりはありませんが、彼女は2018年のようなものと彼女の名前のイグナシアの全体で私たちと一緒に働いたと思いますそして彼女はちょうど周りを回る素晴らしい仕事をしました人々を魅了します。それで、彼女がしたことの1つは、政府のさまざまなパターンのすべてと、それらのパターンのさまざまなバリエーションのすべてを特定することでした。ですから、外に出て、政府で住所を尋ねる方法は10通りあります。それらをすべて一緒に見て、どれが最も適切なアプローチであるかを判断しましょう。

エイミー：どうすればこれらを1つに統合できますか？彼女は大きなワークショップを開催して、人々にそれらを見てもらい、チームとしてそのような統合を行ってもらいました。私たちが実際に何かを公開する前にコラボレーションを構築するという彼女のアプローチは、人々がすでにそのような認識を持っていて、多くの人々が私たちの前に何らかの形ですでにそれに貢献していたことを意味するので、それは本当に助けになったと思います実際に公開しました。ですから、少し先に進んでください。ですから、それは本当に重要だったと思います。そして、人々が貢献するのを助けるようなチーム全体からの多くの永続性のように、単なる永続性。かなり甘いギグのデザインシステムに人々を貢献してもらうと、すべての仕事を人々にやってもらうことができるという考えがあると思います。

エイミー：そして、あなたはただそこに座って、レベルコードを修正し、みんなが実際にあなたにすべての良いものを与えています。しかし実際には、設計システムに取り組んでいる人なら誰でも知っているように、それは信じられないほど複雑です。複数の異なるチームで機能する一元化されたソリューションを作成することは非常に困難です。実際、設計システムに取り組んだことがない限り、それが何を必要とするかを誰かが本当に理解することを期待するのは合理的ではありません。ですから、手持ちがたくさんあります。貢献者の貢献を支援することには多くの作業が必要です。前にも言ったと思いますが、誰かが設計システムに貢献するのを手伝うには、一元化されたチームで自分で物を作るよりも時間がかかると思います。。しかし、それがもたらす価値を認識し、人々に貢献を認識させ、彼らがそれを行うのを助けるためのあなたの努力に固執することは、彼らがそれをする意欲を感じるのを助けると思います。そうですね、その永続性は、私たち、その分野での成功の鍵のようなものだったと思います。

ドリュー：そして、コミュニティからの貢献を管理することについて実際に話すと、それを支援するツールやプロセス、または何かがありましたか？

エイミー：ええ、私たちはかなり厳格なプロセスを持っていたと思います。厳密に言えば、厳密は間違った言葉であり、包括的はおそらくより良い言葉です。そうですね、設計システムにある一連の貢献基準があります。したがって、すべてが可能な限りオープンであるため、人々は何を期待すべきかを知ることができます。ですから、チーム外の政府コミュニティのさまざまな人々と一緒に開発した一連の基準があります。繰り返しになりますが、これらのプロセスの作成に人々を巻き込むことを試みるように、私は本当に重要だと思います。したがって、設計システムへのすべての貢献が満たす必要のある一連の基準があり、私たちがかなり公平であり、物事がそれらの基準を満たしているかどうかを決定するという点で公平であることを確認するために、私たちは参加しました政府全体からの代表者のパネルであったワーキンググループのサポート。さまざまな部門、さまざまな分野、さまざまなレベルの年功序列を持つ人々からのすべてです。

エイミー：それで、貢献についてはみんな少し違った見方をするでしょう。私たちは月に一度彼らと集まり、新しい貢献をレビューして、彼らが基準を満たしているかどうかを判断するように頼みます。そうですね、それは私が推測する設計システムの設計を民主化しようとし、それを代表的なものにして、私たちのチームが真ん中に座ってすべての決定を行うのではなく、実際にどのように理解するかを理解しないようにするために設計された一種のプロセスでしたそれらを使用するチームに影響を与えます。

エイミー：ええ、それは私たちのようなプロセスでした。私が言及しなければならないもう1つの投稿は、GitHubにコミュニティのバックログがあり、誰でも使用できることです。あなたはそれを見に行くために政府で働く必要はありません。それは設計システムからアクセス可能であり、基本的には、設計システムのコンポーネントとパターンに入るすべての研究とすべての実験的なものと例をホストしようとする場所です。繰り返しになりますが、それは、人々が発言権を持ち、実際に公開される前に物事に影響を与えることができるように、その透明性を推進し、可能な限りオープンに取り組むことです。

ドリュー：そして、あなたはそのプロセスがうまくいったと思いますか？同じことをもう一度始めた場合、同様のプロセスを採用すると思いますか、それともうまくいかなかったものはありますか？

エイミー：私は同じようなプロセスを採用すると思いますが、おそらく少し異なる期待を持って入ります。私が言うことは、おそらくもう少し現実的な期待であり、貢献することで物事がより簡単かつ迅速になると私たちがどのように考えているかについて私が言ったことを言ったことです。私は間違いなくそのキャンプにいました。最初は人々に貢献に慣れるための仕事が急増し、その後はもっと手を差し伸べることができるようになり、人々はそれをこなすだけで大丈夫だと思いました。しかし、実際にはそれは実際には実現しませんでした。人々の貢献を支援することには常に多くの仕事が関わっていましたが、私が言うように、それは一種の期待であると思います。本当にそれから逃れることはできないと思いますが、それでも価値があると思います。

エイミー：私はまだその時間を投資する価値があると思いますが、おそらくあなたが物事をスピードアップするか、貢献することでより速くまたはより大きくスケーリングできるようになるという考えではありません。そうですね、プロセスはうまくいったと思います。さまざまな組織に合わせて調整する必要があると思うので、月曜日に新しい役割を開始します。おかしなことに、別の設計システムに取り組んでいます。そのプロセスを理解して移動できるとは思っていません。あそこに。すべてをあなたが扱っている組織と文脈に合わせて調整する必要があると思いますが、私が試みて持ち込みたい要素は確かにあります。しかし、ええ、少し和らげられた期待で、私は思います。

Drew：数回前に、Hayden Pickeringと、特にアクセス可能な設計システム内でのコンポーネントの設計について話しました。それはあなたにもたくさんの経験があると思います。明らかに、政府の設計システム内で作業する場合、アクセシビリティは本当に非常に重要ですが、私たちの多くは、どこで作業していても、それは本当に本当に重要であると主張します。デザインシステムは、デザインのアクセシビリティまたはデザインの実装において役割を果たすと思いますか？

エイミー：それで、タチアナ・マックによる、これに触れる包括的な設計システムの構築についての素晴らしい話があり、それは私にとって本当に影響力があり、彼女は設計システムの一種の乗算効果について話します。つまり、設計システムを使用して、優れたものがどのように見えるかを人々に伝え、人々にベストプラクティスを伝えていることを実装するための簡単な方法を人々に提供しています。したがって、どちらの方法でも機能します。あなたが人々に良いデザインと良いアクセシブルなデザインを与えるなら、それは本当にうまくいくでしょう、そしてあなたはそのアクセシブルなデザインを増やし、デフォルトで物事をよりアクセシブルでより包括的にする可能性があります。

エイミー：サービスをデザインする人々の出発点となる一元化された空間で、デザインシステムの人々を排除する決定を下すと、その排他的なデザインを広める可能性が本当にあります。ですから、私は間違いなく、デザインシステムがアクセシビリティの促進と拡大に役割を果たすと思います。しかし、それはすべて、それを実現するために設計システムに取り組んで使用しているチームの意図から始まると思います。デザインシステムは、実際には私が想定している種類の車両であり、物事にアクセスできるようにするためにそこに意図がある必要があります。

ドリュー：特にGFI UKデザインシステムのように非常に多くの多様な聴衆がいるデザインシステムで常に私を魅了することの1つは、システム全体に変化を広めるプロセスです。たとえば、特定のパターンで行うことができるアクセシビリティの改善を見つけて、それを設計システムで行う場合、それがこのような幅広い対象者に確実に展開されるようにするにはどうすればよいでしょうか。それはあなたが経験したことはありますか？

エイミー：うん。繰り返しになりますが、私たちはGOV.UL設計システムチームの一種であり、それがどのように機能するかについて多くの考慮を払っていると思います。私は正直に言うと、それは技術的にどのように実装されているかに関係しているので、チームの技術的な側面について多くを語るのは間違いなく適切な人物ではありません。デザインシステムを備えたキャンプが2つあり、できるだけ早く物を運び出そうというようなキャンプがあります。できるだけ早く開いてみましょう。そうすれば、労力の重複や労力の増加がなくなり、作業を繰り返すことができます。それから、もう少しゆっくりとキャンプを動かしてみましょう。ある程度の自信が持てるようになるまで、リリースを延期するのが好きだと思います。

エイミー：それは非常に重要だと思います。一般的に、製品やサービスを設計する場合は、最小限のものから始めて、それを繰り返していくとうまくいくと思いますが、何かを構築するときはそう思います。多くの人々が再利用して多くの異なるオーディエンスに提供するように設計されたセントラルは、物事とその使用方法の制御を非常に迅速に使用します。ですから、リリースする前にある程度の自信を持って、ある種の保証プロセスを実施することは、それが出て行く前にアクセス可能であるというある程度の自信を持っていることを意味すると思います。物事は少し安定していて、それは信頼にとって本当に重要だと思います。設計システムに変更を加えることについて話すとき、信頼は非常に重要だと思います。なぜなら、変更を常にリリースしていると、システムの使用が非常に不安定になり、信頼が失われ、人々がそうではないと思うからです。更新などをインストールする可能性が非常に高いです。

エイミー：リリースする内容に配慮し、必要な場合にのみ変更をリリースしていることを示すことができれば、その善意が得られ、人々はより積極的にアップデートなどを行うことができると思います。しかし、ええ、私は、更新プロセスがかなりスムーズで、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.