コンテンツ管理
次のユーザーエクスペリエンスプロジェクトのモジュール性を向上させる
By Michael Andrews
モジュラーコンテンツとモジュラーデザインのメリットを活用するには、企業は両方が将来に備えていることを確認する必要があります。あなたのコンテンツモデルとデザインシステムはあなたの次の大きなプロジェクトの準備ができていますか?
モジュール性は、デジタルデザインの主要なテーマとして浮上しています。
- モジュラーコンテンツは、さまざまなコンテキストでのコンテンツの再利用をサポートします。
- モジュラー設計は、アプリケーションやプラットフォーム全体での設計コンポーネントの再利用をサポートします。
どちらも、パーツのキットを提供することにより、デジタルチームが新しいエクスペリエンスを構築するのに役立ちます。コンテンツモデルとデザインシステムは、新しいエクスペリエンスを作成するためのビルディングブロックを提供します。
しかし、チームが重要な構築パーツを見逃している場合、またはチームが適切に適合していないことに気付いた場合、UXのモジュール性の利点を逃してしまいます。
動機は似ていますが、モジュラーコンテンツとモジュラーデザインは別々に開発されています。どちらのアプローチも、繰り返し使用できる構造の定義に重点を置いており、コンテンツとデザインアクティビティの効率を向上させますが、これらのアプローチの可能性は、既存のコンテンツとデザイン作業の最適化だけにとどまりません。連携して開発すると、チームができることを拡張するためのプラットフォームが提供されます。アドレス、新しい要件に対処できるようにします。
以前は、デジタルチームがコンテンツとデザインを切り離して、特定の画面のコンテンツのデザインを停止する必要がある理由を説明しました。また、ユーザーエクスペリエンスをサポートするために、コンテンツモデルとデザインシステムを調整することの重要性を強調しました。この投稿では、その方法について説明します。チームは、次のプロジェクトでモジュール性の使用をアップグレードできます。
ガバナンスと機能を強化します。組織がコンテンツをデザインから切り離すことに移行すると、コンテンツとデザインの成熟度に弱点が見つかる可能性があります。
- 彼らはアドホックな方法で多くのプロジェクトを行っており、コンテンツやデザインの構造についてはほとんどガバナンスがありません。
- 彼らの現在のコンテンツモデルとデザインシステムは少しずつ成長しており、将来のニーズを処理するのに十分な堅牢性を備えていません。
彼らはより強力な基盤を必要としています。デフォルトでコンテンツをデザインから切り離すヘッドレスCMSを実装することは、これらの次元を改善するための触媒として役立ちます。
新しいプロジェクトは、現在の機能のギャップを浮き彫りにすることができます。主要な新しいプロジェクトの詳細に身を投じる前に、デジタルチームは次の4つのことを行う必要があります。
- プロジェクトの斬新なものを定義する
- すでに利用可能なフレームワークを評価する
- 既存のシステムの準備状況を判断する
- あなたの弱点を強化する
ステップ1:小説を定義する
最初のステップは、チームが以前の作業方法をどの程度変更する必要があるかを知ることです。
提供しようとしているものを見て、過去に行ったプロジェクトとどの程度異なるかを尋ねます。考慮すべきいくつかの質問:
- 既存のUIコンポーネントで十分ですか?
- 現在のコンテンツ構造は、想定されるメッセージとインタラクションを処理できますか?
- 新しいプロジェクトは、既存のパターンからどの程度逸脱しますか?
- どのような新しい要素が必要になる可能性がありますか?
必要になる可能性のある新しいコンテンツとデザイン要素の例を次に示します。
新しいコンテンツ要素の例 | 新しいデザイン要素の例 |
|
|
ノベルティは必ずしも根本的に新しいとは限りませんが、新しい場合もあります。新しいプロジェクトが次のいずれかに拡張されると、目新しさが現れる可能性があります。
- 新しいサブジェクトドメインやチャネルへの対応など、行われたことの範囲
- 以前は構造化されていなかったテンプレート化されたコンテンツに、より詳細な構造が与えられた場合など、表示されている内容の詳細または粒度
あなたのプロジェクトの目標は、何が斬新であるかを明らかにします。新しいプロジェクトが過去のプロジェクトとどの程度異なるかを判断します。プロジェクトは次のようになります:
- まったく新しいグリーンフィールドプロジェクト?
- 既存のアプリケーションの再設計またはリファクタリング?
- コンテンツまたは機能範囲の幅または深さの拡張?
- 代替の相互作用モードで別のチャネルにサービスを提供するなど、新しい方向性はありますか?
プロジェクトが以前に行ったことと比較して斬新さを導入するときはいつでも、コンテンツモデルやデザインシステムに構造を追加する必要があることを示唆しています。
例:プロジェクトでは、以前は1つの言語でしか利用できなかったアプリの多言語バージョンが導入されています。コンテンツモデルは、コンテンツのさまざまなバージョンに対応する必要がありますが、特定のデザインコンポーネントでは、ボタンや入力などの要素のサイズ、画像内のテキスト、日付、数値、通貨、またはレイアウト-特に右から左への言語を追加する場合。
別の例:プロジェクトが拡張現実(AR)を導入する場合、チームはそのチャネルに情報を提供および提示するためのフレームワークを開発する必要があります。
ステップ2:すでに持っているフレームワークを評価する
実施されている基盤の完全性を評価します。既存のコンテンツモデルと設計システムを確認します。提示する必要のあるコンテンツの種類と提供しているチャネルに対応できますか?
コンテンツモデルと設計システムの成熟度をテストして、新しい要件をどれだけうまく処理できるかを確認します。さまざまなシナリオと、システムがそれらをサポートできるかどうかを検討してください。
あなたのコンテンツモデルはどのくらい詳細ですか?既存のコンテンツモデルは、より構造化されたコンテンツ用に構築されていない可能性があります。未成熟なコンテンツモデルには、2つの一般的な問題があります。
- それらは曖昧で大まかに構造化されており、トピックやタスクに関する情報を整理することができず、代わりに限られた範囲の一般的なコンテンツコンテナを提供します。
- それらは、その意味と目的に従って情報を構造化するのではなく、既存の画面に表示されるテキストを反映するため、過度に指定されています(これは画面設計の副産物として生じる事実上のコンテンツモデルです)。
もう1つの制限は、既存のコンテンツモデルがWeb固有であることが多いことです。モバイルアプリ、チャットボット、電子メール、およびその他のWeb以外のチャネルは、多くの場合、このコンテンツモデルをまったく使用しません。マルチチャネルコンテンツ配信をサポートするためにコンテンツモデルを統合する場合は、Webチャネルの一部ではない可能性のあるトピックとタスクを含める必要があります。そうすることで、コンテンツに対するガバナンスが向上します。
コンテンツモデルに必要な粒度を決定します。公開の柔軟性をサポートするのに十分な粒度が必要ですが、価値を提供せずに複雑さを生み出すほどではありません。コンテンツチームが情報を管理する方法と、コンテンツに関連する高レベルのユーザータスクに応じて、コンテンツタイプを決定します。ユーザーがさまざまなシナリオで特定の情報にアクセスする方法に注意を払うことにより、タイプ内のコンテンツ要素を分割(デクランプ)します。コンテンツ要素により、デザイナーはどの情報の詳細を提示するかを制御できます。
- 詳細ユーザーは、さまざまな段階で複数回表示する必要があります
- コンテキストに応じて表示または非表示にする詳細
- プラットフォームやチャネルによって異なる可能性のある見出し、ラベル、説明
あなたのデザインシステムはどのくらい詳細ですか?あなたのデザインシステムは基本をカバーしているかもしれませんが、より複雑なパターンはカバーしていません。未熟な設計システムは、いくつかの問題によって制限されています。
- それらは審美的なガイダンスに焦点を合わせていますが、相互作用パターンを詳細にカバーしていません。
- それらは他の組織からコピーされており、組織の顧客の具体的なニーズをサポートするように調整されるのではなく、見た目だけが変更されています。
- それらは一般的すぎて、特定のユーザータスクのサポートに焦点を合わせていません。
- これらは、新規ユーザーのオンボーディングやユーザーの問題の解決など、繰り返し発生するUIパターンを管理しません。
設計システムをアップグレードします。成熟したデザインシステムは、ボックスやボタンのスタイルを設定する方法以上のものを示しています。新しいチャネルに対応する場合は、設計システムを拡張してそれらをカバーする必要があります。目標は、重要なタスクをサポートする設計モジュールを開発し、さまざまなチャネルを使用するときにユーザーが対話するさまざまなコンテンツを提示することです。
成熟度は、必要な基礎作業の量に影響します。コンテンツモデルまたはデザインシステムの成熟度が低いほど、より多くの労力を費やす必要があります。
コンテンツとデザインフレームワークの堅牢性をクロスチェックします。コンテンツモデルとデザインシステムが新しいプロジェクトのニーズに対応できることを確認します。プロジェクトで新しい機能があまり導入されていないように見える場合でも、ユーザーシナリオを実行して、適切なコンテンツとデザイン機能が利用できることを確認します。ユーザーインタラクションが想定される場合、特に重要です:ユーザーは関連情報を持っており、それを操作できますか?プロジェクトを推進する主要な顧客メトリックと、必要なコンテンツとインタラクションサポートについて考えてください。収容されていますか?
以下の表は、現在の成熟度と埋める必要のあるギャップの大まかなガイドをチームに提供します。
成熟度レベル | エンタープライズコンテンツまたはデザインフレームワークのステータス | 成熟するために必要な目標とステップ |
不在 | フレームワークが存在しません
| 目標:新しい包括的なフレームワーク
|
限定 | フレームワークは現在のニーズには不十分です
| 目標:改善および拡張されたフレームワーク
|
創発 | フレームワークは以前のニーズには十分ですが、将来のニーズには十分ではありません
| 目標:より包括的なフレームワーク
|
包括的 | フレームワークは、予測される将来のニーズを処理できます
| 目標:既存のフレームワークは、将来の準備のためにストレステストされています
|
ステップ3:フレームワークの準備状況を判断する
コンテンツモデルと設計システムの成熟度を確認した後、チームは両方が新しいプロジェクトの準備ができているかどうかを判断する必要があります。基盤が整うまで、適応型ソリューションを構築することはできません。 。
大規模で複雑なプロジェクトの場合、デジタルチームは、コンテンツモデルと設計システムの両方の基盤を準備するまで、詳細な設計とコンテンツ作成の作業を延期する必要があります。
準備したの?それぞれの堅牢性を評価して、チームが詳細設計に移行する準備ができているかどうかを判断します。繰り返し必要となるコンテンツやデザインパターンには細心の注意を払ってください。詳細な設計が開始されたら、チームはコンテンツモデルのどこから情報が取得され、設計システムに従ってどのように表示されるかを知る必要があります。重大なギャップや不明な点がある場合は、基本システムを強化する必要があることを示しています。
準備は、すべての必需品を指定したかどうかに依存します。
- コンテンツ要素(コンテンツモデル内で定義)
- 設計要素(設計システムのコンポーネント)
コンテンツモデルとデザインシステムは独立して管理されており、以前は調整されていなかった可能性があるため、一方または両方が将来のプロジェクトに完全に対応できない可能性があります。
コンテンツ構造の準備 | 設計システムの準備 | ソリューションを構築する準備 |
すべての重要なコンテンツタイプと要素がコンテンツモデル内に配置されていますか? | コンテンツ要素にマッピングできるように、必要なすべての設計コンポーネントを利用できますか? | チームは必要なコンテンツ要素をデザイン要素に接続できますか? |
はい | はい | 準備はできていますか:
|
はい | 番号 | 準備はできていますか:
まだ準備ができていないもの:
|
番号 | はい | 準備はできていますか:
まだ準備ができていないもの:
|
番号 | 番号 | まだ準備ができていないもの:
|
まったく新しいコンテンツドメインまたは新しいプラットフォームの設計をカバーするグリーンフィールドプロジェクトでは、通常、大規模な準備作業が必要になります。
ステップ4:弱点を強化する
理想的には、現在のコンテンツモデルとデザインシステムは、以前に行ったような日常的なプロジェクトを処理できます。ただし、将来に備えていない可能性があります。新しいプロジェクトで現在のシステムでカバーされていない新しいシナリオが導入された場合は、フレームワークをさらに開発する必要があります。
重要な新しいプロジェクトを開始するとき、最優先事項は、コンテンツモデルと設計システムを強化して、予想されるシナリオに対応できるようにすることです。詳細なコンテンツとUIデザインでは、あまり明白ではない特定の要件が明らかになる場合がありますが、詳細な作業を開始する前に、「グローバル」コンテンツとデザインパターンに可能な限り対処する方法を計画することをお勧めします。
将来のコンテンツとUIのニーズに合わせて拡張できる基盤を構築します。その結果、チームの詳細な設計作業がより効率的で保守しやすくなります。