組織の設計ガイドラインをどのように作成しましたか？
私は新しく採用されたUXスペシャリストとして、組織内の開発者とQAテスター向けの設計ガイドラインを作成する予定です。
問題は、これにアプローチするための最良の方法が何であるかわかりません。最初から書き始めましょうか。それとも、デザインパターンライブラリからデータを収集しますか？よくわかりません。
助言がありますか？
入力を感謝します:)
スタイルガイドを作成するために統合する4つの情報源があります。
既存のアプリケーションと組織のドキュメント
組織が現在作成しているアプリケーションと、ユーザーが使用している他の製品を確認します。次の2つを探しています。
アプリケーション間の類似点と相違点。ガイドラインになる必要があるデファクトスタンダードであるもの（特定の機能のアイコンなど）と、標準化が必要なもの（アプリによっては2つの異なるアイコンを持つ同じ機能など）を特定します。
明らかで、悪いデザインの疑いがあります。ガイドラインで排除したいユーザビリティの問題を引き起こすと思われる繰り返しの設計機能を特定します。また、ユーザーを支援する巧妙なデザインにも注目してください。
これには、企業のドキュメントを確認し、マーケティング担当者と面談して、ブランドを確立するために標準化する必要がある純粋に美的な機能を特定することも含まれます。
既存の設計標準
ガイドラインでは、Windows UXガイドラインなどの既存の標準や設計パターンを引用できますが、それらを読んだり、使用したりする人を当てにすることはできません。それでも、アプリケーションのレビューで明らかになった特別な注意を必要とする重大な露骨な違反を除き、ガイドラインの既存の標準のみを引用し、再現しないでください。
ほとんどの場合、組織が作成するアプリケーションの種類に関連するガイドラインを解釈する必要があります。たとえば、Usability.GovのWebガイドラインでは、「Put 同じ場所にある重要なクリック可能なアイテム で、ページの上部に近く、場所をより正確に推定できる」としています。ガイドラインでは、サイドバーメニューまたはトップマージンメニューのどちらを使用するか、サイドバーメニューに表示するリンク（またはリンクの種類）、およびそれらの順序を具体的に指定できます。
プラットフォームと技術機能
ガイドラインは、組織が使用するテクノロジーと一致している必要があります。特にWebアプリの場合、何ができるかは、開発者が使用している正確な開発プラットフォームによって異なります。たとえば、開発者のライブラリにエキスパンダーが含まれていない場合、エキスパンダーをいつどのように使用するかを指定しても意味がありません。テクノロジーの詳細に慣れていない場合は、開発者に会って、何が可能で何が不可能かについて話し合ってください。あなたは彼らが何ができるかで驚かれるかもしれません。
ユーザー調査結果
特定のガイドラインについて、調査とユーザビリティテストを行う必要がある場合があります。これらは、アプリケーションの最初のレビューで問題になると思われたが確信が持てないもの、または実装するのが難しい（しかし不可能ではない）ものである可能性があります。努力する価値があると確信したい場合があります。既存のアプリケーションを使用しているユーザーを観察するか、新しいアプリケーションまたはテクノロジーのプロトタイプまたはデモでテストします。
ガイドラインを作成するときは、ガイドライン自体の使いやすさを考慮してください。
ハイライトの短い要約を提供します（例：典型的なウィンドウの注釈付きイラスト）。ほとんどの人があなたのガイドライン全体を読むつもりはないので、彼らが最も重要なポイントを取得するために目を通すことができる何かをすばやく提供してください。
デザイナーや開発者が考えるように、それを整理、リンク、および/または索引付けします。特定の設計または開発タスクについて、読者は関連するガイドラインにすばやくアクセスし、チェックリストのようにそれらを通過できる必要があります。ガイドラインを整理する方法についての手掛かりとして、組織がどのように機能するかを確認してください。
イラスト付きの例をたくさん提供してください。これは読者の注意を引き、一目でわかる情報を提供し、テキストの解釈を助けます。そして、正直に言うと、自分で作成するよりも何かをコピーする方が簡単です。デザイナーや開発者が例をコピーすることを期待できる場合、例が説明したいガイドラインだけでなく、allガイドラインに完全に準拠していることを確認してください。悪い例が悪い例として明確にラベル付けされていることを確認してください。
デザイナーと開発者でテストしてください。いくつかの簡単な設計作業を行い、関連するすべてのガイドラインを見つけて使用できるかどうかを確認します。彼らがそれを見つけるのにどれほど有用で役立つかについて彼らからフィードバックを得る。使いづらい場合は使用しません。
開発者とデザイナーが仕事に取り掛かるときが来たら、それについての質問に答えるために手元にいてください。自分をガイドラインの第一人者として宣伝します。
HFIのEric Schafferは、適切なタイトルの付いた優れたステップバイステップガイド 効果的なGUI標準を開発する方法 を書いています。
マイケルの答えは素晴らしいと思います。ただし、1つの注意点：組織の文化の進化と変更は、ガイドラインの確立と同じくらい重要です。これは、時間の経過とともにゆっくりとしか発生しません。同僚に時々画面の悪いデザインのスナップショットを電子メールで送信する（できれば、自分の同僚ではなく他の人が好き）、プレゼンテーション付きの茶色のバッグランチを持っている、など。火星から来るいくつかの制約。
これはあなたの組織に当てはまるかもしれないし、当てはまらないかもしれませんが、言及する価値があると私は思いました。
会社用にこのようなドキュメントを作成しました。最初は、どこから始めればよいかを見つけるのが本当に大変でした。
サンプルを検索しましたが、何も役に立たないことがわかりました。それから私はどのようにデザインしていたのか考え始めます。次に、リストとして書き留めました...（Webアプリの場合）
- 画面解像度（クライアントの年齢スケールによる）
- 読みやすさ（フォントサイズ-コントラスト-行の高さ...）
- 使いやすい（タブ順、テキストボックスの使用、順序、グループ化、プログレッシブエンクロージャーなど）
- 安全保障
- コンテンツの重要性
- 一貫性
- ロゴ、メニュー項目、外部リンク、バナーの場所
- CSSの使用例（外部、インライン...、メディアタイプ）
- ブラウザの互換性
- 文字コード
- フレームの使用法
- ヘッダー、カテゴリ、サブ。
- 要素の整列
- ナビゲーション（パンくずリスト、残りのステップ...）
- コントロールの使用（例：ラジオボタンは、テキストをクリックしながら選択するには、ラベルタグの内側にある必要があります...）
- テーブルの使用法（ヘッダー、本文、フッター、キャプション、並べ替え、フィルター、ページング...）
- アイコン....
もちろん、リストの項目をもっと見つけることができますが、これは私が従った方法です。また、「コーポレートアイデンティティ」のドキュメントも非常に役立ちます。世界的に有名な企業や大学がウェブ上でドキュメントを共有しています。
それが役に立てば幸い。
私にとっては良いデザインガイドラインですが、これはgoogle sprintの小冊子から借りたものであり、質問に答える必要があります。
組織として、私たちはデザインの観点から何を支持していますか？
気づいたら、airbnb、uber、gmail、Twitterなど、成功しているすべてのアプリにauthenticがあり、ユーザーが間違いなく認識できるスタイルを持っています提供されているサービスの目的と一致し、それが目的を果たしているたとえば、黒の気の利いた高級感のあるUberは、「お金よりも時間を重視する人」に適しています。 Airbnb：暖かさ、清潔さ、安全感、Gmail ...
私の意見では、ガイドライン本の最初のページはその基本的な質問に答えるべきです、そうでなければ、UXがどれほど優れていても、UIガイドラインがどれほど詳細に説明されていても（AppleのiOSヒューマンインターフェイス Guidelines です）参照）の場合、設計者はどちらの方向に進むべきかわかりません。