デジタルヘルスガイド

トピック3.2 — デザインシステムとプロトタイピング

デザインシステムは、優れたデザインの判断を、共有され再利用可能なインフラに変えます。そうすることで、アクセシビリティ、臨床安全、一貫性が一度組み込まれ、あらゆる場所で引き継がれ、画面ごとに議論し直され、壊され直されることがなくなります。

医療・ケアにおいてなぜ重要か#

医療・ケアでは、インターフェースは、臨床上の判断と患者の間の、最後の数センチメートルであることがよくあります。紛らわしい投薬のフィールド、アクセスできない日付ピッカー、あるサービスでは「予約をキャンセル」を意味し、別のサービスでは「キャンセルしてデータを失う」を意味するボタン。これらは見た目の問題ではなく、患者安全の問題、公平性の問題、信頼の問題です。すべてのチームが自前で部品をゼロから設計すると、欠陥は増え、ポートフォリオ全体にわたる安全の保証について推論することが不可能になります。

デザインシステムは、同じ過ちに繰り返しお金を払うのをやめる方法です。アクセシブルでよくテストされた部品を一度作り、数十のサービスで再利用すれば、アクセシビリティの欠陥や安全上の曖昧さを一か所で直し、すべてのサービスがその修正を引き継ぎます。代替案、つまりあらゆる場所での特注のフロントエンドは、未知で不均一な品質を意味します。Web Content Accessibility Guidelines（WCAG）を満たすサービスもあれば、公衆衛生サービスに最も依存する人々を静かに排除するサービスもあります。

一貫性は、理解の問題でもあります。患者と職員は、NHSアプリ、トラストの外来ポータル、一般診療の予約ツールといったサービスの間を移動し、見慣れないパターンのすべてが、認知負荷を課します。具合が悪い、不安な、高齢の、デジタルから排除された、あるいは支援技術を使う人々を含む集団では、その負荷は均等に分布しません。共有されたパターンは、全員にとってそれを下げます。本トピックは、仕組み、つまり部品、パターン、トークン、プロトタイプ、デザインオペレーションについてです。それらが、安全で、アクセシブルで、一貫したデザインを、英雄的な行為ではなく、最も抵抗の少ない道にします。

中核概念#

デザインシステムは、一連のデジタルサービスを構築するのに使う、再利用可能な部品、パターン、スタイル、ガイダンスの唯一の情報源です。スタイルガイド以上のものです。動作するコード化された部品と、それぞれをいつ、どのように使うかを教える、デザインの根拠、アクセシビリティの注記、使用のガイダンスを組み合わせています。最も関連の深い公開された例は、二つあります。NHSデザインシステム（NHS Englandが維持し、NHS.UKのフロントエンドを土台とする）と、Government Digital Service（GDS）が維持するGOV.UKデザインシステムです。どちらもオープンで、自由に利用でき、何百万もの操作で実戦を経ています。

コンポーネントライブラリは、ボタン、フォームの入力欄、ヘッダー、エラーのサマリーといった個別の構成要素を保持し、パターンライブラリは、繰り返し現れる問題への、より高次の解決策を保持します。生年月日の尋ね方、質問のページの構成の仕方、エラーの報告の仕方、ユーザーへのNHS番号の尋ね方です。コンポーネントは語彙であり、パターンは文です。どちらも、疎結合で、独立にテスト可能な、再利用可能な部品からシステムを組み立てる、コンポーネントベースのソフトウェア工学に依拠しています。

デザイントークンは、名前付きの変数として表現された、最小の共有された決定です。色、余白の単位、フォントサイズ、フォーカス状態のアウトライン。トークンは、ハードコードされるのではなく名前で参照されるため、トークンの変更（たとえば、タッチターゲットの最小サイズやコントラストを上げる）は、それを使うすべてのコンポーネントに一貫して伝わります。トークンは、システムが拡大しても一貫性を保つ仕組みであり、共有のシステムをフォークせずに、地域の用途に合わせてテーマ化することを可能にします。

唯一の情報源（single source of truth）は、統べる考え方です。各デザインの決定は、ちょうど一か所で管理され、サービス間でずれていくことがありません。部品のデザイン、コード、ガイダンスのすべてが、一つの権威あるライブラリにあれば、絵とプロダクトが食い違うという種類のバグをなくせます。

ソフトウェアのプロトタイピングは、本物を作ることにコミットする前に、何かを学ぶために、意図的に不完全なバージョンのサービスを作る実践です。プロトタイプは、低忠実度（紙のスケッチ、グレースケールのワイヤーフレーム）から高忠実度（インタラクティブで、現実的で、しばしばコードで作られる）まで幅があります。GDSの原則は、保持するためではなく、学ぶためにプロトタイプを作るです。プロトタイプの仕事は、実際のユーザーによるユーザビリティテストを通じて問いに答えることで、その後は捨てられます。これは使い捨て（あるいは「ラピッド」）プロトタイピングであり、本番に向けて堅牢化するつもりの進化的プロトタイプとは別のものです。

DesignOps（デザインオペレーション）は、デザインを大規模に運営する規律、つまり、組織や統合ケアシステム（ICS）全体で、共有のデザインシステムを健全で、資金が付き、信頼できる状態に保つ、人、ワークフロー、ガバナンス、貢献モデル、ツールです。コードにとってのプラットフォームエンジニアリングが、デザインにとってのそれに当たります。うまく機能しているときはほとんど見えず、そうでないときは痛々しいほど明らかになります。プロトタイピングは、Figmaのようなデザインツールか、デザインシステムのフロントエンドを使ってコードで直接行われ、ここでフロントエンドのウェブ開発、つまり再利用が実際に重複、コスト、リスクを減らす、HTML、CSS、JavaScriptの層につながります。

本トピックは、ユーザーが何を必要とするか（トピック3.0 — ユーザーリサーチとサービスデザイン参照）や、言葉がどう書かれるか（トピック3.1 — コンテンツデザインとヘルスリテラシー参照）を、意図的に再び扱いません。それらの規律はデザインシステムに入力を与え、本トピックは、それらの結論を安全に本番へ運ぶ、再利用可能な仕組みについてです。

ベストプラクティス#

  1. 作る前に採用する。 自前で発明するのではなく、NHSデザインシステムとGOV.UKデザインシステムから始めます。それらはすでに、医療と政府のサービス全体での、何年ものアクセシビリティのテスト、コンテンツデザイン、実際の利用を符号化しています。日付ピッカーやエラーのサマリーを作り直すのは、希少で高価なデザインとエンジニアリングの能力の良い使い道ではなく、自前の版は、ほぼ確実により使いにくくなります。地域のニーズに合わせて、これらのシステムを拡張しテーマ化してください。意図的で文書化された理由なしに、フォークしてはなりません。

  2. アクセシビリティと臨床安全を、個々の画面ではなく、共有のコンポーネントに組み込む。 デザインシステムの経済と安全のケース全体は、一度直せば、あらゆる場所で引き継がれるということです。アクセシブルで、キーボードで操作でき、スクリーンリーダーでテストされた生年月日のコンポーネントを、一度構築して保証すれば、それを使うすべてのサービスを守ります。WCAGへの適合、適切なエラー処理、安全に関わる振る舞い（破壊的な操作の明確な確認、用量や測定値の曖昧さのない単位）を、コンポーネント自体に組み込み、チームが容易に誤らないようにします（トピック1.9 — デジタルインクルージョンとアクセシビリティとトピック1.6 — 臨床安全とリスクマネジメント参照）。

  3. 保持するためではなく、学ぶためにプロトタイプを作る。 プロトタイプを、特定の問い、たとえば「ヘルスリテラシーの低い患者は、この紹介を完了できるか」に、安く素早く答える、使い捨ての実験として扱います。忠実度を問いに合わせます。流れと理解を早期にテストするには低忠実度のスケッチを、現実的なインタラクション、アクセシビリティ、エッジケースを後でテストするには、コード化された高忠実度のプロトタイプを使います。プロトタイプをそのまま本番に昇格させたい誘惑に抵抗してください。学習の速さのために最適化されたプロトタイプのコードは、稼働中の臨床サービスにとって、安全で、セキュアで、保守可能であることはまれです。

  4. インタラクションとアクセシビリティが問いであるときは、実際のフロントエンドでプロトタイプを作る。 デザインツール（Figmaなど）のプロトタイプは、レイアウト、流れ、コンテンツを素早く共同で探るのに優れています。しかし、キーボード操作、スクリーンリーダーの挙動、フォーカスの管理、古いNHS環境のハードウェアでの性能を、忠実にテストすることはできません。それらがリスクであるときは、デザインシステムのフロントエンドを使ってコードでプロトタイプを作り、実際のユーザーが実際の支援技術で体験するものに近いものをテストします。

  5. 作る前に、実際のユーザーでプロトタイプをテストする。 代表的なユーザーの前に出されないプロトタイプは、高価な意見にすぎません。自分たちの実際の集団を反映する人々、つまり高齢者、障害のある人、デジタルに自信のない人、時間のプレッシャーの下で働く職員でテストします。5人の参加者でも、重大なユーザビリティと理解の問題の大半が見つかり、プロトタイプでそれらを見つけることは、本番で見つけるより桁違いに安価です（トピック3.7 — テストと品質保証参照）。

  6. トークンを、一貫性のための契約として管理する。 色、余白、タイポグラフィ、インタラクションの状態を、名前付きのデザイントークンとして表現し、その変更を、共有の依存関係の変更と同じ真剣さで扱います。トークンによって、最低限のコントラスト、タッチターゲットのサイズ、フォーカスの視認性をシステム全体で強制でき、地域のチームが、根底のアクセシビリティの保証を壊さずに、自分たちのブランドに合わせてテーマを変えられます。国の標準が変わったとき、1万画面を監査するのではなく、一つのトークンを変えたいのです。

  7. 閉ざされた庭ではなく、貢献モデルを運営する。 中央のチームからの入力しか受け付けないデザインシステムは、実際のサービスのニーズに常に遅れをとり、デリバリーのチームから疎まれます。チームが新しいコンポーネントとパターンを提案する明確な経路を公開し、何が受け入れられるか、誰がレビューするか、共有ライブラリに昇格する前にアクセシビリティと安全がどう保証されるかの基準を定めます。これはDesignOpsの中核の仕事です。システムを腐らせたり断片化させたりすることなく、地域の柔軟性と共有の一貫性の緊張のバランスをとります。

  8. 変更をバージョン管理し、文書化し、周知する。 デザインシステムを、ユーザー（デリバリーのチーム）、ロードマップ、リリースノート、サポートチャネルを持つプロダクトとして扱います。セマンティックバージョニング、変更履歴、明確な非推奨の通知によって、チームは、改善を安全に、自分たちのスケジュールで採用できます。文書化されていない破壊的変更は、チームが自前で作るのではなく共有のシステムを選ぶ信頼を壊します。

  9. 存在ではなく、採用と品質を測定する。 デザインシステムは、使われて初めて価値を届けます。どのサービスが共有のコンポーネントを使っているか、チームがどこで特注の代替物を作らなければならなかったか（そしてなぜか）、採用が進むにつれてアクセシビリティ適合が改善しているかを追跡します。地域の回避策の多さは、システムに何か本物のものが欠けていることのシグナルです。不服従ではなく、バックログとして扱ってください。

チームで話し合うための問い#

  1. 共有の一貫性と地域の柔軟性の間の線はどこに引くべきか。そして、誰が決めるのか。 これは、あらゆるデザインシステムの中心的なガバナンス上の緊張です。厳格すぎれば、デリバリーのチームは妨げられていると感じ、影のコンポーネントを作り、システムを迂回し、守ろうとしていたまさにその一貫性を分断します。緩すぎれば、「システム」は、共有の安全やアクセシビリティの保証のない、緩やかに関連した一回限りのものの山になります。医療・ケアの文脈では、利害が具体的です。一部のばらつきは正当で（精神保健の危機サービスは、通常の予約システムとは本当に異なるニーズを持つ）、一部のばらつきは危険です（破壊的な臨床操作の確認の仕方が一貫しない）。良い答えは、どの決定が譲れず（アクセシビリティ、安全に関わるパターン、中核のインタラクションの振る舞い）、どれが地域でのテーマ化に開かれているかを挙げ、単に乖離を禁じるのではなく、チームが例外を求めたり、新しいパターンを提供したりするための、明示的で人道的なプロセスを定義します。

  2. アクセシビリティと臨床安全は、私たちのコンポーネントの中で実際にどう保証されるのか。そして、誰が承認するのか。 アクセシビリティと安全が「組み込まれている」と主張するのは易しく、それを保証するのは難しいものです。この問いは、保証のパイプラインについて具体的にするよう迫ります。誰が各コンポーネントをWCAGに照らして、どの支援技術で、どの障害のあるユーザーとテストするのか。安全に関わる振る舞いは、自分たちの臨床安全のプロセス（DCB0129/DCB0160）に照らして、どうレビューされるのか。コンポーネントが「再利用して安全」として公開される前に、どんなエビデンスが添付されるのか。議論は、正直なギャップを浮かび上がらせるべきです。おそらく自動のコントラストチェックはあるが、本物のスクリーンリーダーのユーザーとテストしたことがない、あるいは臨床安全責任者が共有のコンポーネントライブラリをレビューしたことがない。強い答えは、名前のある責任者、定義されたテストの体制、そして、文書化されたアクセシビリティと安全のエビデンスなしには、いかなるコンポーネントも共有ライブラリに入らないというルールを生みます。50のサービスに引き継がれる欠陥は、50倍の害だからです。

  3. 最初の熱意が冷めたあと、誰がデザインシステムに資金を出し、人員を配置し、維持するのか。 デザインシステムは、しばしば、勢いの中で作られ、創設チームが去ると静かに放棄され、チームがもはや信頼しない、古くなったライブラリを残します。これは、デザインの問題ではなく、根本的には、DesignOpsと資金の問題です。システムを、継続的なプロダクトとして担う、常設で資金の付いたチームがあるのか、サポート、貢献のレビュー、バージョン管理、上流のNHSとGOV.UKのシステムに歩調を合わせる能力を備えているのか、それとも蒸発してしまう善意に頼っているのかを、正直に議論してください。ICSでは、これはさらに鋭くなります。システムは、一つの支配的な組織が所有しているのか、共同でガバナンスされているのか、それとも、その間で孤児になっているのか。良い答えは、デザインシステムを、名前のある所有者、継続的な予算、土台としている国のシステムとの明確な関係を持つ、長寿のインフラとして扱い、「終わる」プロジェクトとしては扱いません。

  4. 上流のNHSとGOV.UKのシステムとの関係はどうか。そして、それらが変わるなかで、どう歩調を合わせ続けるのか。 国のデザインシステムの採用は、一度限りのダウンロードではありません。自分たちが制御しないインフラへの継続的な依存です。この問いは、「軽くテーマ化して、上流を密接に追う」から「フォークして乖離する」までのスペクトラムのどこに位置するかを、意図的に決めるよう迫ります。それぞれの選択にはコストがあります。近くにとどまることは、他者のスケジュールで、上流の変更（新しいアクセシビリティの修正、改訂されたパターン）を吸収し、時に地域のカスタマイズを作り直すことを意味し、フォークすることは、国のチームが無償で与えてくれたはずの、あらゆる将来のアクセシビリティと安全の修正を、自分で所有することを意味します。医療・ケアでは、乖離への引力は本物で、臨床のワークフローと地域のブランドが本物の圧力を生みますが、あらゆる乖離は常設の負債です。良い答えは、誰が上流のリリースノートを見張るか、地域の拡張が上流の更新を生き延びるよう、どう構造化されているか、そして乖離が許される前に通過しなければならない明示的なテストを挙げます。そうすることで、「見た目を変える必要があった」が、いつの間にか「NHSの日付ピッカーの、古く、よりアクセスしにくいフォークを、いまや自分たちが保守している」にならないようにします。

  5. 「学ぶためのプロトタイプ」と「保持するための構築」の間の線を、実際にどう守るのか。 原則として、使い捨てのプロトタイプを、本番のサービスにしてはならないことには、誰もが同意します。失敗は、納期のプレッシャーの下で、説得力のある高忠実度のプロトタイプがそこにあり、それを出荷することが近道に見えるときに起こります。この問いは、境界を、願望ではなく具体的なものにします。学習の速さのために最適化され、セキュリティ、レジリエンス、保守性のためではないプロトタイプのコードが、稼働中の臨床サービスに昇格するのを、実際に何が防ぐのかを議論してください。技術的な分離（本番に到達できないサンドボックスで作られたプロトタイプ）か、ガバナンスの関門（臨床安全の承認なしには稼働しない）か、それとも、納期が遅れた最初の時に蒸発する、共有された善意にすぎないのか。医療・ケアでは、利害が具体的です。臨床経路の中の保証されていないコードは、単なる技術的負債ではなく、患者安全へのリスクだからです。誠実な答えは、圧力がどこから来るかを認め、「ノー」と言う権限を与えられているのは誰かを挙げ、境界が試されたときに保たれるよう、「保証されたコンポーネントから本番用に作り直す」が実際に何を必要とするかを定義します。

  6. デザインシステムが実際に機能しているかどうかを、どうやって知るのか。そして、指標が不都合なときに何をするのか。 デザインシステムは、存在し、美しく文書化されていても、チームがそれを静かに迂回すれば、ほとんど価値を届けません。この問いは、「デザインシステムがある」を超えて、「それは存在に見合っているか」へと押し進めます。何を測定するかを決めてください。サービス全体にわたる採用、特注の回避策の率と理由、採用が進むにつれてアクセシビリティ適合が実際に改善しているか、再構築せずに再利用することでチームがどれだけ時間を節約しているか。難しいのは、数字を集めることではなく、それをどう読むかを、あらかじめ合意することです。地域の回避策の多さは、共有のシステムに何か本物のものが欠けていることのシグナルであり、デリバリーのチームが不服従であることの証拠ではないからです。良い答えは、不都合な採用データを、バックログとロードマップへの入力として扱うことにコミットし、誰がどれくらいの頻度でそれをレビューするかを定義し、重要なもの（より安全で、よりアクセスしやすく、より一貫したサービスが実際に出荷されたこと）ではなく、見栄えの良いもの（存在、ダウンロード数）だけを測定する誘惑に抵抗します。

実践例：医療・ケアの事例#

3つの急性期トラスト、精神保健トラスト、コミュニティの提供者をカバーする統合ケアシステムが、患者向けのデジタル環境を統合することを決めます。現在、各組織は独自の外来ポータルを運営しており、それらの間には、互換性のない4つの日付ピッカー、NHS番号の3通りの尋ね方、大きくばらつくアクセシビリティ適合があります。内部監査は、4つのポータルのうち、予約の導線の基本的なスクリーンリーダーのテストに合格するのは1つだけであることを発見します。明らかな公平性と臨床安全のリスクです。

ICSは、共同で資金を出す、小さなデザインシステムチームを立ち上げます。ゼロから作るのではなく、NHSデザインシステムを基盤として採用し、ICS固有のブランドのためのデザイントークンの薄い地域の層と、少数の本当に地域的なパターン（たとえば、通訳の支援を予約するための共有パターンで、国のどのシステムもカバーしていない）を定義します。すべての共有コンポーネントは、公開される前に、文書化されたWCAGのエビデンスと、DCB0129のプロセスに基づくICSの臨床安全責任者の承認を伴います。

外来の予約の導線を作り直す前に、チームはプロトタイプを作ります。低忠実度から始め、2人のスクリーンリーダーのユーザー、75歳を超える3人、デジタルに自信のない数人を含む、地域の集団を反映するように募った12人の参加者で、新しい導線の、紙とグレースケールの版をテストします。プロトタイプは、深刻な理解の問題を露呈します。患者は、「日程変更」の操作と「キャンセル」の操作を区別できないのです。チームはパターンを直し、そのあと、デザインシステムのフロントエンドを使って、コード化された高忠実度のプロトタイプを作り、再テストします。今回は、パートナートラストの外来クリニックで使われている実際のハードウェアでの、キーボードとスクリーンリーダーの挙動を確認します。

それからようやく、本物を作り、本番のサービスを、ほぼ保証された再利用可能なコンポーネントから組み立てます。18か月後、WCAGの更新がフォーカスの視認性の要件を厳格化します。フォーカスのスタイルは単一のデザイントークンにあるため、チームは一つの変更を出荷し、ICSのすべてのサービスが次のリリースでそれを引き継ぎます。以前の断片化した環境では、5つの別々の是正プロジェクトを意味し、現実的には、少なくとも一つのサービスが壊れたまま残ったであろう修正です。

セクター別の視点#

スタートアップ#

小さなデジタルヘルスのスタートアップは、自前のデザインシステムをゼロから作ることは、ほぼ決してすべきではありません。アクセシビリティのテストの間接コストを負担できず、投資家が払っているのは、特注のボタンではなく、臨床的な検証だからです。NHSのユーザーのために構築するなら、NHSやGOV.UKのフロントエンドを採用し、プロトタイピングを中核的な競争優位として扱ってください。実際の患者でテストされる、安価で素早い使い捨てのプロトタイプは、資金の豊富な既存企業より速く学ばせてくれます。リスクは逆のものです。投資家のデモに間に合わせるため、洗練された高忠実度のプロトタイプを本番へ直接昇格させ、保証されていない、安全でないコードを、稼働中の臨床サービスに持ち込むことです。資金のプレッシャーの下でも、「学ぶためのプロトタイプ」と「保持するための構築」の間に、厳しい線を保ってください。

小規模事業者#

確立した小規模の提供者、つまり患者向けのツールを調達する一般診療所、地域薬局、介護施設、単独拠点のクリニックには、稼働中の患者がいますが、専任のデザインやフロントエンドの能力はなく、特注の部品のコストを吸収できません。最も強力な手は、あらゆるサプライヤーに、NHSやGOV.UKのフロントエンドの上に構築することを求めることです。アクセシビリティと安全の保証が、約束されるのではなく引き継がれる形で得られ、それを願いではなく契約の書面上の条件にします。自前のデザインシステムを運営する必要はまれで、必要なのは、それをうまく使うこと、そしてサプライヤーの洗練されたデモが、アクセスしやすく保証された稼働中のサービスのエビデンスではないと認識することです。プロトタイプを作る場合、つまり新しいオンライン予約の導線を、実際の、より高齢で、デジタルに自信の少ないことも多い患者でテストするなら、実際のユーザーとの数回のセッションが、洗練されたモックアップが明らかにするよりはるかに多くを捉えます。大きなトラストと同じ法定のアクセシビリティと臨床安全の義務が適用されるため、誠実な問いは、準拠するかどうかではなく、共有の国のインフラから、引き継がれるコンプライアンスを、どう安く得るかです。

大企業#

大規模なNHSトラストやヘルステック企業には、すでに重複するインターフェースを作る複数のチームがあるため、その問題は断片化と重複したコストです。価値のケースは、本物の貢献モデルを運営する、資金が付いた常設のデザインシステムチームであり、採用の指標がリーダーシップに報告され、臨床安全とアクセシビリティのアシュアランスへの明確なガバナンスの線があります。中心的な緊張は政治的なものです。力のあるデリバリーのチームは、制御を譲ることに抵抗し、高圧的な中央のチームは、影のコンポーネントを生みます。大企業は、共有のシステムを義務づけて祈るのではなく、十分に文書化され、よくサポートされ、明らかに高品質な、本当により易しい選択にすることで成功します。

政府#

NHS EnglandやGDSのような国の機関は、自分たちが制御しない組織が使う公共インフラとして、デザインシステムを運営するため、オープンさ、安定性、後方互換性が非常に重要です。その義務は最も強いものです。法定のアクセシビリティ規則、平等義務、そして共有の国のコンポーネントの欠陥が、何百万人もの市民に伝播するという現実。仕事は、発明というより管理運営です。明確なバージョン管理、非推奨の方針、網羅的なアクセシビリティのエビデンス、下流の何百ものチームへの応答性。NHSデザインシステムとGOV.UKデザインシステムが参照例であるのは、まさに、システムを、プロジェクトではなく、長寿の公共財として扱っているからです。

よくある失敗パターン#

  • 放棄されたシステム。 デザインシステムが華々しく作られ、創設チームが散ると保守されなくなり、チームは信頼を失って特注の仕事へと戻る。対策：一回限りのプロジェクトではなく、常設のプロダクトチームに資金を出す。
  • 嘘をつく絵。 唯一の情報源がないため、デザインファイルと本番のコードが食い違い、「デザインシステム」が、プロダクトがもはや行わないことを記述する。コード化されたコンポーネントとそのドキュメントを、権威あるものとして、一緒にバージョン管理する。
  • 後回しのアクセシビリティ。 実際の支援技術のテストなしにコンポーネントが出荷され、アクセスできないパターンがあらゆる場所で引き継がれ、害を減らすのではなく増やす。コンポーネントの公開前に、文書化されたWCAGとスクリーンリーダーのエビデンスを求める。
  • プロトタイプから本番へ。 時間を節約するため、高忠実度のプロトタイプが稼働中のサービスへ直接昇格され、安全でなく、保守できず、保証されていないコードを臨床の現場に持ち込む。使い捨ての境界を徹底し、保証されたコンポーネントから本番用に作り直す。
  • 閉ざされた庭。 中央のチームがあらゆる貢献を拒み、システムが実際のサービスのニーズに応えず、デリバリーのチームがそれを迂回する。貢献と例外のプロセスを公開し、地域の回避策をバックログのシグナルとして扱う。
  • 一貫性の芝居。 本物の地域のばらつきが正当な場面（危機サービス、小児科）に、厳格な画一性が強いられ、整頓の名の下に安全とユーザビリティを損なう。譲れない決定と、正当に地域的な決定を区別する。
  • 誤った忠実度でのテスト。 インタラクションとアクセシビリティのリスクが、キーボードやスクリーンリーダーの挙動を試せない静的なデザインツールでしか「テスト」されず、偽りの自信を与える。インタラクションが問いであるときは、コードでプロトタイプを作る。

成熟度モデル#

観点 着手 発展 標準化 管理 統合
再利用と唯一の情報源 すべてのチームが特注のフロントエンドを作り、共有のコンポーネントがない 共有のコンポーネントが少数あるが、デザインとコードが乖離する 唯一の情報源があり、ほとんどのサービスが、共有されバージョン管理されたコンポーネントから作られる 再利用の水準がサービスごとに目標に対して追跡され、デザインとコードの乖離が積極的に監視・是正される 再利用が既定で、特注の仕事はまれで、意図的で、文書化される
アクセシビリティと安全 場当たり的でテストされていない。適合が不明 自動チェックのみで、時折の手動テスト コンポーネントの公開前に、WCAGと臨床安全のエビデンスが必須 適合がライブラリ全体で測定・保証され、安全の統制が定義された目標に対して監査される 継続的な支援技術と安全のテスト。修正がトークンを通じてシステム全体に伝わる
プロトタイピング チームが本番へ直接作り、テストはほとんどない 一部プロトタイプを作るが、時に本番に昇格される 忠実度が問いに合わせられ、プロトタイプは代表的なユーザーでテストされ、捨てられる プロトタイピングの頻度とユーザーのカバー率が追跡され、プロトタイプから本番への境界がガバナンスされ徹底される 多様なユーザーによる迅速で日常的なプロトタイピングが、構築前のほとんどのデザインの決定を導く
DesignOpsとガバナンス 所有者も貢献の経路もない 非公式な所有。貢献の仕方が不明確 資金の付いたチーム、貢献モデル、バージョン管理、リリースノート、採用の追跡 サポートと貢献の実績がSLAに対して管理され、採用と品質がリーダーシップに報告される ロードマップ、SLA、健全な双方向の貢献を備えた、プロダクトとして運営されるデザインシステム
地域と共有のバランス 完全な断片化か、厳格な画一性 緊張が管理されず、影のコンポーネントが現れる 譲れない決定と地域の決定について明示的なルールがあり、例外のプロセスがある 例外と回避策が記録され、閾値に対してレビューされ、乖離が積極的に管理される トークンによる地域のテーマ化が、共有の保証を壊さず、摩擦が小さい

チェックリスト#

  • ゼロから作るのではなく、NHSデザインシステムやGOV.UKデザインシステムを基盤として採用している。
  • 共有のコンポーネントが、実際の支援技術と障害のあるユーザーでテストされた、文書化されたWCAG適合のエビデンスを備えている。
  • 安全に関わるコンポーネントが、再利用のために公開される前に、自前の臨床安全のプロセスでレビューされている。
  • デザイントークンが、色、余白、タイポグラフィ、インタラクションの状態を統べ、一か所からのシステム全体の変更を可能にしている。
  • コード化されたコンポーネントとそのガイダンスが置かれ、一緒にバージョン管理される、唯一の情報源がある。
  • プロトタイプの忠実度が問いに合わせられ、代表的なユーザーのサンプルでテストされ、使い捨てとして扱われている。
  • インタラクションやアクセシビリティが重要な導線が、デザインツールだけでなく、コードでプロトタイプされている。
  • 資金が付き、名前のあるチームが、ロードマップとサポートチャネルを持つ継続的なプロダクトとして、デザインシステムを所有している。
  • 公開された貢献と例外のプロセスによって、デリバリーのチームが新しいコンポーネントとパターンを提案できる。
  • 採用と品質が測定され、地域の回避策の多さが、不服従ではなくバックログとして扱われている。

主要な情報源#

  • NHSデザインシステム — NHS England：NHSのデジタルサービスのための、コンポーネント、パターン、スタイル、アクセシビリティのガイダンス。
  • GOV.UKデザインシステム — Government Digital Service：英国政府のサービスのための、スタイル、コンポーネント、パターン。
  • GOV.UK Service Manual — プロトタイピングと「プロトタイプを作る」 — Government Digital Service：学ぶためのプロトタイピングとユーザーでのテストのガイダンス。
  • NHS Digital Service Standard — NHS England：共有され一貫したサービスが評価される標準。
  • Web Content Accessibility Guidelines (WCAG) 2.2 — W3C Web Accessibility Initiative：アクセシビリティ適合の標準。
  • Public Sector Bodies (Websites and Mobile Applications) Accessibility Regulations 2018 — 英国政府：公共部門のサービスに対する法定のアクセシビリティ義務。
  • DCB0129 / DCB0160 臨床リスクマネジメント標準 — NHS England：医療ITシステムの製造と導入のための臨床安全標準。
  • Design Council Double Diamond — Design Council：ディスカバリーとデザインを支える、発見、定義、開発、提供のモデル。

参考文献#

  1. Design system — Wikipedia — https://en.wikipedia.org/wiki/Design_system
  2. Software prototyping — Wikipedia — https://en.wikipedia.org/wiki/Software_prototyping
  3. Single source of truth — Wikipedia — https://en.wikipedia.org/wiki/Single_source_of_truth
  4. Usability testing — Wikipedia — https://en.wikipedia.org/wiki/Usability_testing
  5. GOV.UK (and the GOV.UK Design System) — Wikipedia — https://en.wikipedia.org/wiki/GOV.UK
  6. Government Digital Service — Wikipedia — https://en.wikipedia.org/wiki/Government_Digital_Service
  7. Web Content Accessibility Guidelines — Wikipedia — https://en.wikipedia.org/wiki/Web_Content_Accessibility_Guidelines
  8. Component-based software engineering — Wikipedia — https://en.wikipedia.org/wiki/Component-based_software_engineering
  9. Figma — Wikipedia — https://en.wikipedia.org/wiki/Figma
  10. Front-end web development — Wikipedia — https://en.wikipedia.org/wiki/Front-end_web_development
  11. NHS design system — NHS England — https://service-manual.nhs.uk/design-system
  12. GOV.UK Design System — Government Digital Service — https://design-system.service.gov.uk/
  13. Make a prototype — GOV.UK Service Manual — https://www.gov.uk/service-manual/design/making-prototypes
  14. NHS Digital Service Standard — NHS England — https://service-manual.nhs.uk/standards-and-technology/service-standard
  15. Web Content Accessibility Guidelines (WCAG) 2.2 — W3C Web Accessibility Initiative — https://www.w3.org/TR/WCAG22/
  16. Understanding accessibility requirements for public sector bodies — GOV.UK — https://www.gov.uk/guidance/accessibility-requirements-for-public-sector-websites-and-apps
  17. Clinical Risk Management: its Application in the Manufacture of Health IT Systems (DCB0129) — NHS England — https://digital.nhs.uk/services/clinical-safety/documentation-for-clinical-risk-management-standards

GitHubでこのページを編集 — 本書が信頼できる唯一の情報源であり、このサイトはそれを表示するだけです。