サービスデザイン
サービスデザイン準備度のチェックリスト
アプリケーションデザインにおいては、効率的な開発時間とさまざまなデジタルタッチポイントでの一貫したユーザー体験のニーズが高まっています。そのため、組織はその両方を確保するためにService Design Infrastructure（サービスデザインインフラストラクチャ）の構築に依存してきました。
しかし、そうする前に、「デザイン変革に重要なリソースを投入する前に、どのように準備度を確保しますか?」という深刻な課題に取り組まなければなりません。
サービスデザインは貴重なツールになり得ますが、その実装にはかなりの時間、予算、組織アライメント（組織的な連携）が必要です。構造化された準備度フレームワークがなければ、チームは価値を提供できない、または採用されないシステムを構築してしまうリスクがあります。
このチェックリストは、大規模なサービスデザインの実装における実践的な経験に基づいて作成されており、サービスデザインのイニシアティブが成功するか停滞するかを決定する重要な要素を特定しています。特に、チームが確立されたサービスデザインインフラストラクチャの使いやすさを実際に監視するための評価基準として、3つの具体的かつ明確な側面を中心に構成されています。
サービスデザインインフラストラクチャとは?
サービスデザインインフラストラクチャは、製品やサービスにわたって一貫した体験を構築するための共有基盤です。これは通常、再利用可能なコンポーネント、インタラクションパターン、コンテンツガイドライン、実装標準を含む集中ドキュメントとして現れます。
サービスデザインシステムのユーザーベースはデザイナー、開発者、プロダクトオーナー（PO）、マーケティングリード、外部パートナーなど、複数の役割にまたがり、これらの共有リソースへのアクセスを必要とする場合があります。
このシステムは、FigmaやSketchなどのツールで作業するデザイナー向けのビジュアルアセットと、ReactやAngularなどのフレームワークで作業する開発者向けのコード化されたコンポーネントの両方を提供します。その部門横断的な依存関係を考えると、組織の準備状況は特に重要です。
サービスデザインインフラストラクチャの主なメリットと隠れたコスト
サービスデザインインフラストラクチャは、主に3つの方法で価値を提供します。
- 同じ組織内の異なる製品全体でビジュアルおよび機能的な一貫性を確立
- 標準化された再利用可能なコンポーネントを通じて生産を加速
- すべてのステークホルダー（利害関係者）種類にアクセス可能な信頼できる唯一の情報源（SSOT）を作成することで、知識の伝達を改善
Google、Apple、Facebook、Amazon、Microsoftを含む大手テクノロジー企業は、独自の包括的なサービスデザインシステムを確立しています。その中で、GoogleのMaterial Designは広く認識されています。また、そのシステムの使用はテクノロジー分野に限定されなく、保険（例：フランス保険会社のMAIF)、銀行（例：フランス金融グループのBPCE)、公共サービス（例：イギリス）など、さまざまな企業における組織が追随し、拡大するアプリケーションポートフォリオを管理するための独自のフレームワークを実装しています。
ところが、サービスデザインインフラストラクチャを構築および維持するタスクは、あまりにも頻繁に過小評価されています。検討すべきいくつかの主要な課題は以下の通りです。
- 持続可能性を確保するための専用チームリソースを備えた適切なガバナンスモデルを定義
- エンゲージメントを促進するために、技術、製品、デザインチーム間の持続的な連携を確立
- 時間の経過とともに陳腐化を防ぐために、進化の要件を予測
これらの要素が最初から対処されない場合、結果は使用されず、メンテナンスされず、結局放棄される不完全なシステムになることがよくあります。
サービスデザインインフラストラクチャは、価値を提供するために継続的なケアと供給を必要とする生命システムとして機能します。それは成長し、より教育され知的になり、すべてのユーザーにとって貴重な仲間に進化することが必須です。
サービスデザイン準備度のフレームワークの評価する3つの側面
組織は健全で効果的なサービスデザインインフラストラクチャを確保するために、採用（adoption）、進行（progression）、パフォーマンス（performance）の3つの側面に焦点を当てた準備度のフレームワークを使用してパフォーマンスを監視するのは不可欠です。
それでは、各側面が分かりやすく説明します。
採用面の準備度
採用面の準備度は、ユーザーがサービスデザインインフラストラクチャに満足し、積極的に使用しているかどうかを調べます。
パフォーマンス指標は最も注目されることがよくありますが、採用追跡も同様に不可欠です。採用面が無視されると、強力な技術実装にもかかわらずサービスデザインの取り組みは失敗する可能性があります。
つまり、自問するのは「デザインシステムインフラストラクチャは実際にユーザーにとって役立つか？コンポーネントをリクエストするプロセスはどれほど応答性が高いか?」
採用度を測定する際、チームは最も一般的に使用されるコンポーネントや、サービスデザインシステムがどのくらいの頻度で訪問されるかなどの具体的な指標を追跡できます。Figmaといったツールはコンポーネントの追跡を可能にしますが、チームは本番環境のアプリに直接タグ付けすることもできます。特定のアプリの開発は、アプリの使用コンテキストと特性により、システムを必要としない場合があります。
なお、定期的なインタビューやフィードバックフォームなどの他の方法は、個々のユーザーレベルでシステムがどこで機能しているか、または失敗しているかについて、より定性的な見方を提供します。定量的追跡と定性的追跡を組み合わせることで、ユーザーの採用と評価プロセスをより徹底的にすることができます。
進行面の準備度
進行面の準備度は、サービスデザインインフラストラクチャがチームのニーズを満たすために絶えず進化することを保証します。これには、構築および保守活動の監視が必要です。
新しいコンポーネントの作成率、開発時間、ドキュメントの完全性などの指標は、インフラストラクチャの堅牢性を示めます。ドキュメントは、FigmaやSketchでデザイナーが使用する「グラフィカル」コンポーネントと、ReactやAngularなどのテクノロジーで開発者が使用する「開発された」コンポーネントの両方を考慮する必要があります。
主要な進行指標には、単純なコンポーネントを設計するための平均時間、消費アプリケーションの数、月ごとおよび前年比の貢献（新しいコンポーネントリクエスト）の数、そして生成および処理されたバグの数が含まれます。進行は、Figmaの組み込み追跡システムを使用して測定できますが、最終的には専用の追跡ボードが欠かせないです。
パフォーマンス面の準備度
パフォーマンス面の準備度は、サービスデザインインフラストラクチャがデザイナーと開発者が一からコンポーネントを作成せずに、標準化されたコンポーネントを再利用できるようにすることで、生産コストを削減するかどうかに対処します。
実装プロセス自体が重大なコストであり、メンテナンスチーム全体を含むまでの可能性があるため、この投資は生産節約を実証することによって正当化されなければなりません。
主な質問は、デザインと開発の生産時間が短縮されるかどうかです。その他の重要な要素には、バグ数が減少したか、生産品質が向上したかが含まれます。デザインシステムインフラストラクチャがすべてのリソースを1か所に集めるため、新メンバーのオンボーディング時間の短縮もその有効性を表すとも言えます。
明白なのに、デザインシステムのパフォーマンスを測定する1つのシンプルな方法はインフラストラクチャありとなしで費やした時間を比較することです。例えば、すべてのコンポーネントを一から設計する画面に費やした時間と、事前に設計された利用可能なコンポーネントを使用した同じ画面にかかる時間を確認します。
最終の考慮事項：コンテキストへの適応
サービスデザインのコンテキストは大きく異なるでしょう。インフラストラクチャは、多数のアプリケーション、さまざまなエンドユーザー種類によって使用され、複数のテクノロジーで開発され、さまざまなデバイスで使用される可能性があります。これらのコンテキスト質問への回答は、追跡する指標のタイプを方向付けるべきです。
リリース時には、コンテキスト、ユーザー、そのニーズを理解することが関連する指標を決定するために不可欠です。
採用の測定が鍵です。その上、コンテキストに適応したさまざまな形式を取ることができますが、組織は最初から誰でも役立つシステムを設計し、寿命全体を通じてその能力が維持されることを保証するためにリソースを専念させる必要があります。
準備度のフレームワークは、組織がサービスデザインインフラストラクチャを維持するために必要なガバナンス、コラボレーション、進化能力を持っているかどうかを評価します。実装の前と最中で採用面、進行面、パフォーマンス面に焦点を当てることで、製品およびCXリードは可能性のある見落としを特定し、軌道修正がまだ可能な間に行動を起こすことができます。