UXデザインの「複雑さ」を説明して文書化する方法
システムの背後にある実際のコードに関してソフトウェアの複雑さを分析するにはさまざまな方法がありますが、UXデザインに関しては、ソフトウェアの複雑さについて人々と話し合うのに苦労しました。
人々はデザインを単純化し、ワークフローの複雑さを軽減することについてよく話しますが、私の経験では、ページに到達するためのクリック数の削減やナビゲーションが簡単。
私が見ることができることから、ソフトウェアシステムまたはアプリケーションの設計を複雑にするいくつかの要素があり、これは情報アーキテクチャ、ユーザーインターフェイス設計、対話設計、ワークフローなどを含む設計のあらゆる側面に適用できます。
密度-これは、特定のコンテキスト/ビュー内でユーザーに提示されるコンテンツの量を指します。したがって、プロセス内に多数の要素または多くのステップを含む高密度のIA、UIはすべて、密度によって複雑さに影響します。
Diversity-これは、単語や言語の使用、類似のコンテンツを表すユーザーインターフェイス要素のタイプ、またはユーザーのタイプなど、デザイン内に存在するバリエーションまたは多様性の量を指しますなどに対応します。より自然に設計する必要があるため、すべてを一貫して一貫性のあるものにすることに伴う複雑さが増します。
設計言語/システム-これは、ソフトウェアを作成するためにすべての設計要素を組み合わせた論理と構造を作成するために使用される原則とプロセスを指します。したがって、シンプルで理解しやすく、保守/更新が簡単で、モジュール性が高く拡張可能なシステムは、開発されるソフトウェアに固有の複雑さの多くを軽減します。
これらの3つの側面からUXデザインの複雑さを分析する独自の方法を考え出しましたが、設計者がデザインの複雑さを確認して軽減できる標準が他にあるのだろうか？
個人的には、UXの複雑さを文書化する作業は、退屈なものだとすれば、簡単だと思います。私の観点からは、非常に一般的な次元の「サイズ」または膨らみを正直に説明するのと同じくらい簡単です。
パターンの複雑さ-区別は意味を伝えます。同じ機能を共有しているが、視覚的な扱いが異なる要素は、認知上のオーバーヘッドを追加するだけです。
概念の複雑さ-ある種の分析レポートを生成する段階的なプロセスを検討してください。ディメンションを選択し、1つ以上のメトリック、日付範囲を選択して、実行します。これは、最終ステップを含めて合計4つのアクションです。 5ステップも要求するUIデザインはすでに肥大化しています。
システムテキストの複雑さ-これは常に、代表的な聴衆と比較して検討する必要があります。用語とラベル、および言語は、ユーザーの期待と言葉に一致する必要があります。メーカー中心の専門用語には、翻訳とオンボーディングが必要です。
視覚的な複雑さ-いくつの視覚スタイルが機能していますか？タイプトリートメント、別名タイプフェイス、重量、トリートメント、色のユニークな組み合わせ？グラフィックの審美的アプローチの数（フラット対レイズなど）
これらのことを数え始めるだけです。ユーザーがデザインの複雑さをすばやく評価する必要はありません。おやすみの睡眠とおそらくコーヒーが必要です。
それが本当に「混乱する」ことについてであるとき、あなたは「複雑な」を選択する危険にさらされていますか？私は非常に複雑なソフトウェアを使用しましたが、それは非常に使いやすいですが、非常にわかりにくいソフトウェアを使用しただけです（使用できませんでした）。おそらくあなたはこれを間違った方法で見ていますか？
私はUX負債に関して利害関係者と話します（これは、開発者がアジャイルで話しているもの-技術的負債からの借用です）
- 混乱しているものは、UX Debtに追加してください。
- 簡素化することでUXの負債が減ります。
理想的には、UX負債を最小限に抑える必要があります。
UX負債にプラスまたはマイナスの影響を与えるあらゆる種類のUXメトリクスと人間の心理学および心理学の事柄（@Andrew Martinが言及した認知負荷と選択麻痺、またはフィッツの法則など）を選択できます。
UXPAはUX Debtに関する記事を書きました： http://uxpamagazine.org/ux-debt-in-the-enterprise/
「技術的負債」という用語は、開発プロセス中に取られたショートカットが原因で技術を維持するために増加するコストを説明するために使用される比喩としてワードカニンガムによって造られました。 Joshua Kerievskyは後に、「ユーザーエクスペリエンス（UX）負債」という用語を使用して、メタファーをユーザーエクスペリエンスデザインに拡張しました。 Kerievsky氏は、技術的な負債と同様に、UXの負債は最終的には通常、顧客満足度の低下と顧客の欠陥の可能性という形で発生すると説明しました。
UXPAの記事には、便利なUX Debt Calculatorが含まれています。
UXPinはUX Debtについても書きました： https://www.uxpin.com/studio/blog/3-step-guide-erasing-ux-debt/
製品の動作やパフォーマンスに一貫性がない場合は、短期的な利益のために長期的な犠牲を払っている可能性があります。 UXの負債を積み上げました。
たとえば、企業が市場シェアを獲得するために機能の「クリティカルマス」をリリースすることは珍しくありません。チームは最初にユーザーの迅速な獲得を心配し、後のスプリントのためにクリーンアップ作業をスケジュールします。
UXの借金に関しては、すべての答えをすぐに知ることはできません。そして、次のリリースまでにすべてを修正することはないでしょう。しかし、だからといってあきらめる必要はありません。製品管理に心臓発作を起こさない計画を立てることができれば、最終的には借金をなくすことができます。
UXPinは、Andrew WriteによるサンディエゴでのIA Summit 2014でのUX Debtについての講演を引用しました。これが彼のスライドです http://www.slideshare.net/andr3wjwright/ias14-uxdebt
彼はUX Debtを2つのカテゴリーに分類しています。
意図的なUX負債
あなたのプロジェクトがそれを正しく行うための時間、お金、またはリソースを持っていない時があるでしょう。何かを犠牲にする必要があり、ユーザーが気付く可能性は十分にあります。ユーザーエクスペリエンスに影響を与える積極的に手を抜くときはいつでも、あなたはユーザーとの間に必ず入ります。
意図しないUX負債
しかし、すべての負債が意図的であるとは限りません。優れたUXの最も重要なルールの1つは、自分がユーザーではないことを覚えておくことです。しかし、ユーザーは常に自分自身であるとは限りません。つまり、ユーザーは常に変化します。今日彼らのために働くことは、数ヶ月または1年ではないかもしれません。また、製品を構築する前にユーザーの理解に熱心でなければ、ユーザーと一緒に意図せずに赤字になる可能性もあります。たとえば、幅広のネットを投げて一般的なペルソナを作成すると、視聴者が持っている特定の特性を見逃してしまう危険があります。たとえば、一般の人々の大部分が最新のスターウォーズの映画にかなり興奮しているように見えるからといって、視聴者も同じだというわけではありません。そして、その仮定をすることは、あなたが本当に彼らをまったく知らないように感じるだけです。
次元性
それはあなたが誰と話しているかによります。私は最良の方法は、彼らの経験から同様の比喩を見つけることです。
私の特定のケースでは、私が一緒に働くほとんどの人は、何らかの工学的または数学的な知識を持っています。そしてproblem spaceのメタファーが役立ちます...そして、あなたがそれで作業できるようになると、問題空間のdimensionityは、複雑さを論じるときに使用するのに役立つメトリックです。
警告：差し迫った複雑な説明！
これは、最初に説明するのが最も簡単なメタファーではありませんが、理解し始めると、複雑さ、それがどのように成長し、影響を与えるかを説明するのに最適な方法です。
マトリックスまたはグラフでdimensionとして設計しているものを見るときに、ユーザーが考慮または決定する必要があるすべてのことを考えてください。これらの寸法は、ボリューム内の直交軸を定義します。これをproblem spaceと呼びます。ユーザーが選択できる、または選択したいすべての可能なオプションは、問題スペースにあります。のように、互いに直角な軸。最大3つの軸で、これは視覚化するのに十分簡単ですが、その後はhardになります。
変数または選択肢が1つしかない場合、問題のスペースは行です線形の選択は簡単です。それらはAまたはBのいずれか、またはAからBへの直線上の点です。
2つの変数または選択肢がある場合、問題の空間は2D形状です通常は簡単です。あなたは、正方形の角か、グリッド内のすべてのセルを見ている。
つの変数または選択肢がある場合、それは3D問題空間です。
ほとんどの人は、すでに理解しているこの特定の例を扱う場合は問題ありませんが、このような追加の次元を追加すると、ユーザーが使用できる組み合わせの数（問題の空間のボリューム）が線形ではなく指数関数的に増加します。また、2D画面で表現するのも困難です。
それよりも多くの次元がある場合、人生は複雑になります。
高次元についてどうするか
デザインを操作し、複雑さを特定して軽減しようとするとき、問題空間に存在する次元の数を調べることから始めます。ユーザーが行うすべての選択と、それらの選択を表すために必要なすべての変数を計算します。これにより、問題空間にいくつの次元があるかがわかります。原則として、「次元数はいくつですか？」に対する答え。最初は「多すぎる」です。
次に、それらのディメンションの値間の強い相関を探します。次のようなもの：
- 「Xが高い場合、Yも常に高く、Xが低い場合、Yも低い」
- 「Xが高い場合、Yは常に低く、Xが低い場合、Yは常に高い」
- 「これらのXの値は、Yが1の場合にのみ存在し、Xの値はYが0の場合にのみ存在します。
- 「X、Y、またはZの1つだけが一度にtrueになることができます」
- 「これらの設定は、その設定がTRUEの場合にのみ値を持ちます」
これらの種類の強い相関が存在する場合ユーザーに伝えることができる方法の場合、ユーザーにこれらの各ディメンションを提示する必要はありません。代わりに、これらの2つの代わりに単一の組み合わせディメンションをユーザーに提示することができます-値mustが直接関連または反対である場合、それは実質的にユーザーの1つの決定であり、そのように提示するのが最適です。
それでも複雑すぎる場合はどうなりますか？
その削減と除算のラウンドを実行したら、少し弱い相関を検討し始めます。 2つの可能な選択肢の間にかなり強い相関関係があるが、1人または2人のユーザーまたはユースケースがその相関関係に適合しない場合、質問は「なぜ適合しないのですか？」そして、「これは彼らにとって適切なツール/機能/製品ですか？」。通常、それは私たちがユーザー/製品に適合していないこと、彼らが誤った操作を行っていること、または何かを見落としたため、それをカバーするために別の次元を再度追加する必要があることを意味します。
これらはすべて知っておくと良いことです。調査すると、通常はeveryone幸せにならないかもしれませんが、全体として最も幸せになるという結論につながります。
強力なメトリック
それはあなたが望んでいることとはかなり違うかもしれませんが、製品の任意の領域のdimensionityを計算することは、複雑さの便利な指標になる可能性があります。次元が高くなりすぎる場合は、何らかの方法で再考する必要があるか、ユーザーが苦労している理由のコンテキストを提供している可能性があることを示しています。
このアプローチはすべての問題を解決するわけではないか、すでに世界に出回っている製品の既存の問題を見つけるのに役立つかもしれません...しかし、それはあなたがすでに知っている問題を文脈に入れて前進するのに役立つかもしれません。また、統計やユーザーテストの指標と比較するための指標として、デザインレビュー/批評プロセスに組み込むこともできます。
また、使用するUIコンポーネントの選択については特に触れないことにも気づくでしょう。これは、通常は複雑さがかかるレベルではないためです。それは、ユーザーが行う必要がある選択と、ユーザーがそれらを選択するために頭に持っている必要がある情報についてです。ユーザーが決定を表現するために使用するコントロールを選択することは重要ですが、行われる決定の数を最小限に抑えることはかなり重要です！
うまくいけば、それが役立ちます。それがあまり明確でない場合、私はこれからのアイデアの一部を（かなり可能性がかなり低い） ここのブログ投稿 に示します。
[〜＃〜] ui [〜＃〜]デザインへの影響
（質問作成者のリクエストにより追加）これをUIデザインに適用する場合、最初にdimensionityを削減するために作業したときに、UIデザインの質問が非常に単純になり、数が少なくなることが一般にわかりました問題空間の。
決定の数が減ると、UI設計プロセスがすぐに簡単になります。
また、これらの設定のグループが相互にまったく影響を及ぼさないことを確認した場合（それらに対する変更は問題空間で互いに完全に分離されています）...それは、それらが個別のコントロールまたはコントロールのグループである必要があることを示唆しています-さらに削減複雑さ。
上記の定義を使用して、dimensionityを減らすと、コントロールのdensityがすぐに減少します。コントロール数が少ないと、UIのデザインに移動する余地が増えます。
コントロールのdensityを減らすことで、diversity問題の少ないコントロール-コントロールが少ないほど、ユーザーがコンポーネントを操作できるようにする一連の共通のUIコンポーネントの構築に焦点を当てることがはるかに簡単になり、良いものを得るための障壁が低くなります設計言語/システム。
要約すると、次元数を減らすと、強力なUIデザインを作成するための多くの障壁が取り除かれます。それはあなたのために設計作業をしませんが、それはあなたがする必要があることの量と複雑さを減らします、そしてそれを行うプロセスはしばしばあなたがそうでなければ考慮しなかったかもしれないUIアプローチを示唆します。