製品の分類法をどのように作成しますか？
幅広い質問があります。それは「分類法」の定義です。何かの分類法を実際に作成するとはどういうことですか...次に、それを例に適用したいと思います。このプロジェクトが、書籍を販売するeコマースWebサイトの再設計であるとしましょう。製品の分類法を作成する必要があります。これを達成するために、UXerとしてどのようなステップを踏む必要がありますか？
分類法について最初に覚えておかなければならないのは、要素のセットごとに1つの正しい分類法が存在することは決してないということです。
製品セット{紙、綿生地、古い木製の直線}を想像してください。仕立て屋にとって、分類法内の分類は次のとおりです。製紙業者の場合、分類は次のとおりです。{綿布、古い木製の線}->製紙の原料、{紙}->最終製品。
つまり、分類は製品についてではなく、ユーザーについてです。各ユーザーは独自の「正しい」分類法を持っています。より正確には、ユーザーと達成しなければならないタスクの組み合わせごとに独自の正しい分類法があります（釘を持っていると、すべてが「ハンマーのように見えます」および「いまいましい、役に立たない」カテゴリ）。それで、もし皆が異なる分類法を持っているなら、世界はどのように機能しますか？優れたソリューションに近づけるには、いくつかの要因があります。
- ユーザーとそのニーズが類似しているほど、分類間で重複が多くなります
- サイトは1つの分類に限定されません
- 分類法をナビゲートすることは、製品を発見する唯一の方法ではありません
ユーザーエクスペリエンススペシャリストとして、最初に、ユーザーの個々の正しい分類法の最適な重複を提供する複合分類法を作成する必要があります。これは、ユーザーのニーズを発見するための通常の方法で実行できます。今回は、特に分類法に焦点を当てています。ここでそれらを列挙することはできません。これは、1つの本では使い果たせないトピックです。
2番目に考慮すべきことは、多くの場合、単一の製品にはいくつかの優れたカテゴリがあり、それぞれが独自の分類法に従っていることです。一度に使用するだけで十分です。生地のウェブサイトでは、同じ生地が「目的別の生地->衣類の生地->冬の生地」、「素材別の生地->天然生地->ウールミックス生地」、「色別の生地->織りパターン」に表示されます。生地->ヘリンボーン柄生地」。ユーザーは、各ルートから開始してナビゲートできます。 Amazonも同じようなことをしています。本が見つかったすべてのカテゴリを見てください。
3つ目は、サイトにアクセスするすべてのユーザーの個々の分類法をすべて網羅する複合分類法を作成することはできません。また、ユーザーは、自分の分類法とは大きく異なる分類法で分類された製品を見つけるために、多くの時間を必要とします（そして、頻繁に失敗します）。したがって、分類法に加えて適切な検索を提供します。
定義
単語分類法は、18世紀に生物の階層を作成した CarlLinnæus の研究に由来します。 分類群という言葉は、生物のグループを意味します。
それ以来、Wordは、主に厳密な階層構造を持つ分類スキーマを説明するために使用されてきました。定義は存在しますが、この用語はしばしば乱用されます。
ただし、情報アーキテクチャ内では、多くの人が以下に同意します 定義 ：
制御された語彙を階層構造に編成する、ニーズに基づく分類スキーム。
詳細については：
- ニーズに基づく分類スキーム-ユーザーのニーズに基づいてエンティティを分類します（ここでは、件名やトピックではなく、ニーズという用語を使用します関心も機能します）。
- 統制語彙-用語（ラベル）は慎重に選択されています。
- 階層構造-親子関係を含む構造。
または簡単に言えば、UX分類法は次のとおりです。
ユーザーのニーズを反映する、ユーザーが期待する用語のツリー構造。
チャレンジ
UX分類学者は4つの重要な課題に直面しています。
- アイテム-何が分類されていますか？これは明らかな場合もあれば、調査やデータ収集によって明らかになる場合もあります。
- ニーズ-ユーザーのニーズは何ですか？興味？彼らはどのようにドメインにアプローチしますか？たとえば、サイトXのクロスショッパーはアイテムタイプよりもブランドを優先しますか？
- 用語-ユーザーが使用する用語は何ですか？たとえば、電気エンジニアがポテンショメータと呼んでいるのに対し、オーディオエンジニアはポットまたはノブまたはロータリーフェーダーと呼んでいます。どちらがより一般的ですか？ ノブという用語は、ドメイン語彙内であいまいですか？
- Groups-カテゴリとは何か、エンティティが属するカテゴリ。封筒は事務用品または紙製品の下にありますか？
UXアクティビティ
従来のUXデザインの感覚では、プロセスには次のものが含まれます。
研究
上記の課題に取り組むために、いくつかのアクティビティを実行できます（分類する項目がすでに特定されていると想定しています）。
- Open Card Sorting-ユーザーは、カードにドメインアイテムを説明する用語を入力するよう求められます。その後、ユーザーはカードを整理するよう求められます。この演習では、用語と階層の両方を明らかにします。
- カードの並べ替えを閉じる-ユーザーは、すでに用語が含まれているカードを並べ替えるように求められます。階層のみを表示します。
- インタビュー-使用する用語を選択できます。指示された質問は、ユーザーのニーズを明らかにすることができます。
- User Observations-用語とニーズを明らかにできます。
- 競合他社の分析-他の人はどのようにドメインを構築しましたか？彼らはどんな言葉を使いましたか？
設計
これは、あなた（そしておそらく他の専門家）が座って、さまざまなスキームを評価し、用語を検討しながら血を吸う場所です。
ここでは、いくつかのことが考慮されます。例えば：
- 幅vs深さ-階層は広い（多くの兄弟カテゴリ）または深い（多くのレベル）ですか？幅は認知負荷（15の異なるカテゴリから選択する必要があります）を課す可能性があり、深度は相互作用を煩わしくする可能性があります（7回のクリックで目的のものに到達します）。コントロール内にある場合、これもコンテキストに依存します。小さなディスプレイ（モバイル）は奥行きを要求し、大きなディスプレイ（デスクトップワイドスクリーン）は幅を要求します。
- Order-論理的に順序付けられたアイテム/グループです。たとえば、上記の4つの課題で、ニーズ/アイテム/グループ/用語はもっと意味がありませんか？
- Poly-parenting-アイテムは複数のカテゴリに表示されますか？そうすることはユーザーを助けることができますが、いくつかの複雑さを伴います（たとえば、パンくずリストは問題があります）。
- 単一の子-子を1つだけ持つ親を表すために来ます。これは明確な禁止事項ではありません。複数のアイテムをグループ化します。グループに項目が1つしかない場合は、グループを削除するか、項目を追加します（類推によって-兄弟がない場合、本に小見出しを作成する意味は何ですか？）。構造化を始めたばかりの多くの人々は、そのような関係を作成します。
テスト中
階層内のアイテムを見つけるようにユーザーに依頼します。
問題のない解決策はほとんど不可能であることを覚えておくことは重要です。これについては、以下のまだ別の設計問題セクションで詳しく説明しています。
プロセス
次のタスクモデルは、プロセスの主要なアクション、製品、および評価ポイントを示しています。
- まず、整理に必要なすべてのアイテム/オブジェクトを詳しく説明します。私たちはこれらを「葉」と呼ぶことがあります-子を持たない階層ノード。
- 次に、アイテムをグループ（カテゴリ）にグループ化します。
- 次に、グループを上位レベルのグループにグループ化します。
- 理想的には、この結果は複数の階層になります。
- 次に、最適なオプションを選択するまで、さまざまなオプションを評価、テスト、および調整します。
例として、UXフィールドの分類法を作成するとします。非常に部分的なアイテムの在庫（ただし、この例では十分です）は次のようになります。
次に、アイテムのグループ化を開始します。
次の分類も同様に可能であることに注意してください。
あなたはすでに最後の階層からかなり多くを学ぶことができます。例えば：
- ユーザーの監視はリサーチの下にありますが、テストと呼ばれるグループの一部にもなります。
- セマンティックメモリおよび短期メモリは実際の兄弟ではありません-前者は実際にはエピソードメモリでグループ化され、後者は長期メモリでグループ化されます。したがって、さらにグループ化を行う必要があります。
- それを短期記憶または作業記憶と呼びましょうか？
- 人間の記憶に人間が必要ですか？ メモリで十分ではないでしょうか？
- プロトタイピングは本当にデザインだけですか、それとも（部分的な）実装の一部になることができますか？
次のステップはグループをグループ化することになるため、次のような結果になる可能性があります。
これで、分類法をテストできます。
- 分析
- ペルソナの作成
- エピソード記憶
- ビジュアルメモリ（メモリの下に別のサブグループが必要になります）
- タスクマトリックスの作成
さらに別の設計上の問題
分類法の作成に関する問題の1つは、ほとんど常に複雑な問題を表すことです。そのため、最善の解決策はありません。最善の妥協策だけです。
設計問題と同様に、発散収束戦略は多くの場合、最良の結果をもたらします。言い換えると、1つのソリューションに焦点を当てるのではなく、さまざまなソリューションから導き出すことが重要です。
実際には、プロセスはマクロカテゴリにあまり早くコミットすべきではありません。そうすると、分類に欠陥が生じる可能性があります。別の試みが行われると、特定の計画が他の計画よりも問題にうまく着陸する可能性があります。
代替（将来）アプローチ
階層を作成する際の問題は、分類するエンティティにはほとんど常に複数のプロパティ/変数があるため、複数のグループに属している可能性があることです。
ontologiesとtopic-mapsの両方がこの問題を解決します。しかし、これらはより複雑で、ナビゲーションに適していません。ただし、分類法を作成するときに、ハイブリッドアプローチをとることができます。アイデアは、各項目のプロパティ（ファセット/クラス/タグ）を綴り、可能なカテゴリで作成されたプロパティリストから作成することです。そのようです：
これは明らかにより複雑ですが、階層的な分類法とトピックマップ/オントロジーの両方を作成するために使用できます。後者がより広く普及するようになり（そしておそらくSEOの要件）、この道を進むのにお金がかかるかもしれません。
簡単にするために、分類は分類です。何かの分類法を作成するということは、そのシステムのユーザーが認めるであろう共通点を見つけ、それに応じてそれらを分類することを意味します。
UX関連のすべての要素と同様に、ユーザーから始めます。あなたの質問はより具体的に尋ねるようですeコマースサイトの書籍を分類するにはどうすればよいですか？まあ、「ユーザー中心の分類法」は単にペルソナに基づいて作成された分類です、web analytics、ser Testingおよびcard sortingで、明らかに大きな打者に名前を付けます。必要な情報を蓄積するには、これらの従来の方法に従う必要があります。この情報が収集されると、次のようなAmazonのくずに似た分類法を作成するための情報が準備されます。
もちろん将来の校正ラベル付けガイドラインまたは制限分類法を作成するなどの考慮事項があります-特にユーザーが作成したコンテンツサイト-Pinterestを考えて、新しいコンテンツは分類されずに送信されません（コンテンツを見つけられるようにしますか？）。
要約すると、ユーザーベースのフレームワークがなければ、それは暗闇の中でのショットなので、実際に研究データを求めています。 2つの異なるeコマースの書店が、ペルソナ/分析/在庫に基づいて分類する方法の例（Amazon v。Oyster-サブスクリプションモデル）：
ペルソナ/アナリティクスは、AmazonのEditor's PicksとOyster's Picks/Popular on Oysterにつながる可能性があります。オイスターは在庫が大幅に少ないため、自然に幅広い分類フィルタリングなしが含まれます。たとえば、オイスターにはBusiness Essentialsカテゴリしかありませんが、Amazonのビジネスセクションと可能なフィルタリングの量を見てください。
あなたが話しているのは、情報アーキテクチャであり、コンテンツの意味のある価値ある構造を作成する技術です。私はいくつかの分類法に取り組んできましたが、上手くいくテクニックとうまくいかないテクニックがあります。たとえば、カードの並べ替えは何度か使用しようとしましたが、信頼性が低いことがわかりました。
私がよく使用する手順は次のとおりです。
- 分類するアイテムと既存の階層を収集します。私は、コミュニケーションのためのイラストとしてトップレベルのスプレッドシートでこれを行う傾向があります。
- 販売されたアイテムのスペクトル全体で主要なアイテムのリストを特定します。これには、ニッチなアイテムを分類するのが難しいまでのベストセラーが含まれるはずです。すべてのアイテムをテストすることはできませんが、作成した分類法をテストするには20以上のアイテムが必要です。
- マーチャンダイザーの実際の経験があれば、それを含めて、サイトの使用状況データを収集します。
- 既存のサイトと競合他社のユーザー調査/テストを行います。競合他社のサイトをテストすることは、物事を見つける優れた方法であり、合法です。あなたはそれらを言う必要はありません。私は何度もカードの仕分けを試みましたが、それが信頼できる方法であることはまだわかりません。
- 知っていることに基づいて仮説の階層を構築します（これもスプレッドシートとして行います）。マーチャンダイザーがいる場合は、これを渡します。
- 仮説をテストします。 「Treejacker」などのツールを使用すると、分類法だけをテストできます。 10ユーザーで十分です。
- 仮説を調整して再テストします。
- それをライブにして、可能であれば、ツリーのどの部分が不確かかを多変量テストします。
その他のヒント。
- アイテムは複数の場所に表示できます。マルチマーチャンダイジングは結構です。
- ファセットは大規模なショップにとって不可欠であり、多くの場合、分類法に取って代わります。
- タグ付けに注意してください。タグは分類ラベルやファセットと同じではありません。
- ほとんどの優れたショッピング分類は、広く浅いものです。
- しかし、何かに7回のクリックが必要な場合でも、ユーザーがそのルートをすばやくたどっていれば、問題はありません。たとえば、Wineは多くの場合、多くのアイテムよりもはるかに多くのファセットを持っています。本によっては、さらに多くの面が必要になる場合もあります。
- ギフトやプロモーションは、ほとんどの場合、構造のどこかに追加する必要があります。
最後に手に入れる：
それはだれがそれを使用しているかに大きく依存します。
多くのお客様は、ウェブサイトの構造をツリーに反映するだけの分類法をウェブサイトに使用しています。
これは、決して実行可能な解決策ではありません。
これへのアプローチはフィルターでした。
製品カテゴリやサイトマップなどの一般的なソリューションから始めます。
次に、ユーザーが必要なものを参照できるようにし、不要なものをすべてフィルタリングして、それらのフィルターを保存できるようにします。時にはこれで十分です。
彼らが十分な時間これを行った後、私たちは彼らのフィルターをチェックし、それらから新しい情報を抽出しようとします。それらのフィルターが異なるブランチからのアイテムをグループ化するかどうかとその理由を確認します。
このアプローチは通常、より明確な注文につながります。
ここで定義されている分類法 http://en.wikipedia.org/wiki/Taxonomy は、事物または概念の分類に関する研究です。製品の分類は、分類と定義の製品階層になります。
企業構造の分類、地理的な場所なども同様に定義されます。
それらを階層ツリーの形式で定義でき、そのラベルはセマンティクスとそれらのレベル（ツリー内）を説明し、グループ化の方法を定義します。
このリンクはアイデアを与えるはずです（階層定義がモバイルまたはタッチベースのデバイスで行われていないと仮定）
http://support.f5.com/kb/en-us/products/wa/manuals/product/wa9_4policy/WA_Policy_9_4-05-1.html
このプロジェクトは、書籍を販売するeコマースWebサイトの再設計です。製品の分類法を作成する必要があります。これを達成するために、UXerとしてどのようなステップを踏む必要がありますか？
https://vimeo.com/222586117 では、分類法の使用方法と、分類法を1つに統合する方法について説明しています。
古い分類法を新しい分類法にマップしたい場合で、すでに新しい分類法を設計している場合は、両方を treemerge.io にインポートして、視覚的にマッピングを作成できます。次に、スクリプトを実行して、マッピングを使用してすべての書籍アイテムを新しいカテゴリに割り当てることができます。