UXスタイルガイドのテクニック
私は最近、大規模なWebベースの金融ツールの大幅な再設計を開始しました。今後の開発を支援するために、フォーム、ページレイアウト、アニメーションなどのベストプラクティスを概説するUXスタイルガイドを生成することを計画しています...
既存のアプリケーションは、グループ化や編成がほとんどない、ごちゃまぜのフォームの寄せ集めです。いくつかの主要なカテゴリ（オブジェクトCRUDフォーム、静的データ、ユーザーセッション管理コントロールなど）が表示されますが、型に合わない非常にカスタムな機能がたくさんあります。
私が協力している会社は海外での開発であり、このドキュメントは将来の開発をサポートすることを目的としています。私はこれまでで最も素晴らしいUXを設計するつもりはありません。物事を機能的にしたいだけです。設計をリモートチームに伝えるための最良の方法は何ですか？
これが私の質問です：
このような大きな乱雑なプロジェクトに取り組むための最良の方法は何ですか？（まずメジャーグループ、次に各カスタム関数に焦点を当てますか？カスタム関数をドキュメントに含めますか？）
スタイルガイドの例
アプリケーションに適用可能なスタイルガイドの例については、通常のプラットフォームスタイルガイド（例： Windows 、 Apple 、 Gnome ）を使用して組織、問題、および必要なトピック。これらのガイドの多くのトピックはフォーム指向のUIに関連していませんが、コントロール、メッセージ、およびダイアログボックスのガイドラインのほとんどはフォームに賛同しています。 Webサイトのガイドラインもあります（例： sability.gov ）。ただし、これらは一般的にアプリケーションにとってはあまり役に立ちません。
何を含めるか
基本的なアプローチについては、回答を参照してください 組織の設計ガイドラインをどのように作成しましたか？ 特定の質問に答えるために、「要素」またはUIの一部（レコード、フィールド、レイアウト、フォーム、コマンド、フィードバック）、および「関数」（「パターン」と呼ばれることもあります）。これらは、ユーザーのタスク（ログイン、クエリ、レポート、元に戻すなど）の一般的な手順のために複数の要素を標準UIに組み立てます。 、ソート、ズーム、ヘルプ）。両方をスタイルガイドでカバーします。
スタイルガイドの目的は、すべてを自分で設計する必要がないようにすることです。そのため、カスタム関数が1つのフォームにのみ存在する場合は、スタイルガイドに含めないでください。ただし、ツールまたはスイート全体で一般的に使用される機能のコンポーネントまたは抽象化を含めることができます。
成果物
理想的には、スタイルガイドの最終的な形式は、ツール/スイートユーザーではなく、スタイル付きガイドを使用してツールを作成する開発者とデザイナーである、ユーザーにとって最適に機能するものである必要があります。スタイルガイドは、仕事を難しくするのではなく、簡単にする必要があります。ユーザーが特定のケースに適したガイドラインを見つけたり、それらを学習して理解したり、実装したりすることが難しい場合は、ユーザーはそれを行いません。 UXスキルを適用して、ガイドラインと成果物を作成し、デザイナーと開発者にインタビューして観察し、何が有効かを調べます（この場合、開発者への電話インタビューに限定される場合があります。何もしないよりはましです）。
これは、製品が複数のメディアを使用する可能性があることを意味します。おそらく、「主要な」製品は、ハイパーリンクされたドキュメントの一種であり、参照資料にとって明らかに有利です。ただし、要約クイックリファレンスガイドまたはチェックリスト、ガイドラインを宣伝して主要な機能を強調するための印刷可能なポスター、スタイルガイド互換のテンプレート/パターン/ CSSのライブラリ、およびセミナーやワークショップ（リモートで実施される場合もあります）がある場合もあります。個人的にガイドラインを紹介し、デザイナーと開発者にとっての利点を示します。率直に言って、ガイドラインの作成はほんの始まりにすぎません。ほとんどの作業はガイドラインの促進と実施です。そのための時間、予算、組織的なサポートを得るようにしてください。
受け入れられる回答があることは知っています。通常、マイケルにはまったく同意しますが、それでも2日間は私の心を悩ませます。
開発者として、私はApple HIGを嫌っていました
何をすべきか、どうやって行うかを教えてくれませんでした。
Windowsガイドラインは「空」であると感じられましたが、実際には、Windowsでは誰もフォローしていないように見えたため、そうであった可能性があります。
私が実際にWindows GUIと本当に親密な関係を持っている必要があったことを覚えておいてください：短いWindowsプログラムをでも書けるようにする必要がありました紙の上に。
すべてのウィジェット、その仕組み、目的、および呼び出し方法を知っていました。文字通り、心から。
それは強制結婚のようなものでした。
それでも、私は見事なものを作成する方法を知りませんでした、そしてHIGはそれをする方法を私に教えませんでした。
それがHIGでない場合、OS Xアプリケーションが均一に優れている理由は何ですか？
もちろん、Apple製品自体は見事に設計されており、誰もがをコピーしようとしただけです。1つのコピーがうまくいったとき、彼らは良いものをコピーしましたそこからのパーツでもあります。しかし、開発者はパターンを理解しました。なぜなら、彼らはアプリ自体を使用したからです。 。
（開発者がシステムを使用していない場合-あなたが他の場所で言及したように、それが銀行ソフトウェアである-いくつかの悪いものに備える）
おそらく、良いメタファーも役立ちました：うまく設計されたウィジェットは、レゴブロックのように互いに接続されていました。
しかしまた：テンプレートがありました：言うことができます：それはドキュメントベースのウェブアプリです。これはコアデータWebアプリです。 2006年から2007年のように、WebにはCoreData + WebViewチュートリアルが満載されていると思います。そのようなアプリが文字通りたくさん見られただけです。
元の70年代のデザインパターンはrecipesです。「この問題がある場合は、これを実行してください」：の方法を確立したら、アプローチ問題、あなたは勝利の道を歩んでいます。
ビジュアル言語はまだ言語です
そして、ウィジェットはその語彙です。
私にとって、bootstrapは次のようになります：
開発者は、この言語で書かれた完全な手紙を書くように求められます。
さらに悪いことに、開発者はこの言語に興味がありません。
彼は楽しみのためにこれを学んでいない、それを使うように言われた。いくつかの合理化は役立ちますが、Webページの言語の場合、別のドメインでのアウトソーシング、ユーザーの連絡なし、開発者は気にしません。
したがって、通常、ここで発生するのは、開発者が語彙を開き、パッチをまとめて、コードを送信することです。
単純な語彙の代わりに完全なフレーズブックが必要です。
繰り返しますが、ここでは手紙が書かれます。中国語で。
いつフレーズを使用するかを伝える必要があります。 examplesを表示する必要があります。おそらく、同じ問題ドメインに対して同じ言語で記述された既存のアプリケーションからです。
暗黙的であっても、すべてのビジュアル言語には基本的なパターン言語があります
Alexanderの classic は良い読み物です。彼はエンジニアリング思考にパターンを導入した人物であり、ソフトウェアエンジニアリングを通じてUXにも上陸しました。少し外れたトピックですが、彼の IEEEトーク を読む価値があります。
UXスタイルガイドで達成しようとすることは、アレクサンダーがパターン言語で達成しようとしたことと非常によく似ています。彼はジェネリックを定義し、決定をユーザーの手に委ねようとしました。
（注：開発者の手ではなく、ユーザーの手に）
しかし、私はまだレシピが重要だと思います。デザインパターンカタログは、依然としてフレーズのカタログです。それは、単純な語彙ではなく、Oxford Dictionary（定義、いつ使用するか、例を含む）に似ている可能性があります。
それはHIGから完全に欠けていました。あなたはそこに立っていて、一般的なガイドラインがありました、そしてあなたは「OK、それで私はどのように始めますか？」のようでした
OS HIGはガイドではありません。OSHIGが一般的なケースに書かれているからです。アプリの描画からmp3プレーヤー、メールリーダーから病院のカタログシステムまで、理論的にはすべてをOSで実行できます。
Twitter Bootstrapについても同じことが言えます。これは、一般的なデザイン言語です。
詳細を見つける必要があります：どこでコンテンツを調整できますか？
編集：
詳細を言うときに私は何を話しているのですか？
まず、アプリケーションのパターンを確実に特定します。
通常、次の2種類のパターンがあります。
- アーキテクチャパターン、つまり、ほとんどの種類のアプリケーションが存在します（それらのほとんどはCRUDであると述べました）
- ウィジェットパターン、つまり、ウィジェットまたはウィジェットの相互作用として定義できるいくつかの特定のUXデザインパターンを実際に見つけ、それに対応するウィジェットライブラリを定義します。
また、通常は最初のカテゴリに強く関連している3番目のカテゴリを指定する必要があります。
- レイアウト
Webインターフェイスの設計 Webアプリケーションの 典型的なレイアウトを収集する で素晴らしい仕事をしました。とにかく私は本をお勧めします。
あなたはあなた自身のケースにこれを蒸留する必要があります。特に、これらのレイアウトから実際にメリットが得られるアプリケーションモジュールを見つけ、完全に設計する必要があります。
次に、開発者を選択します。どのような種類のアプリケーションを作成していますか？ダッシュボード？フォームシステム？これはフォームシステムのレイアウトです。これらは必須要素です。これらはオプション要素（+いつ使用するか）です。これは、これらがどのように連携するかを示しています。
開発者にユーザーフローを実際に考えるように教えるのは良い考えですが、UX指向の完全なプロセスを考案するのは簡単なケースではないでしょう。あなたがアウトソーシングしている場合。
開発者は、それを完全に台無しにするよりも、それを使用して自分で何かを作成する努力が少ない場合、これらを使用します。つまり、使用する完全なボイラープレートコードがあり、それらが取得できるだけであれば、問題なく動作します。
また、それらに一連の経験則を提供します：「アクセシビリティは視覚障害とコントラストと色覚異常の人にとって重要である」と言う代わりに、はるかに簡単です「すべてのページは黒の上に白でなければならず、赤と青の組み合わせは許可されていません」。
確かに、それほどファンタジーではありませんが、つまり、十分なソリューションを構築しているのでしょうか、それとも、開発者から本格的なUXデザイナーを作り出そうとしているのでしょうか。
欠点は、開発者が数年後でもこれらの経験則に反響し、それが暴かれたとは聞いていないことです。例としては、7 + -1の規則（まだを教えるで大学に！）や、基本的には X Myths いいえ、彼らは説明や制約を読みません。
しかし、これらは他の誰かの問題になると思います...
海外開発は、しばしば「貧しい」開発のコードです。これらの問題を解決するスタイルガイドはありません。しかし、それは別のトピックです。
機能するものについては、チームごと、プロジェクトごとに大きく異なります。より複雑なインタラクションなどを備えたより複雑なWebアプリケーションを構築しているとき、私はパターン/コンポーネントライブラリに進むためのより良い方法を見つけています。
これらは生きたドキュメントであり、UX、Dev、およびBusinessの中央リポジトリとして設計されています。このアイデアは、誰もが利用できる中央ハブを作成することです。
ドキュメント化が必要なコンポーネントを特定します。例でフォームに言及すると、フォームには多数の個別コンポーネントが含まれる可能性があります。たとえば、オプション選択を考えてみましょう。ドキュメントには、次のような情報が含まれる場合があります。
- パターンの名前
- 使用する（使用する場合、使用しない場合）
- 視覚スタイル（色、フォント、サイズ）
- 相互作用のドキュメント（コンポーネントの動作を説明）
- 代替バージョン
- サンプルHTML/CSS/JS（開発チーム向け）
- ワイヤーフレームパターンのサンプル（UXチーム用）
- エラー状態
- アクセシビリティ要件
欠点は？パターンライブラリを上手く管理できる製品はまだ見つけていません。 SharePoint、Axure、Wordで試してみましたが、すべて欠点があります。私が見たオンラインツールの点で最良のオプションは、可能性があるように見えますが、領域が不足しているpatternry.comです。
これらすべてを排除し、開発をアウトソーシングしているという事実を組み合わせ、チームと組織がそれをサポートできる場合、本当に最高の成果物はプレゼンテーション層のコードです。紙のドキュメントがなくても、海外での開発から完全な翻訳が得られるので、自分でできることが多ければ多いほど、結局はUXを制御できるようになります。
私は最近以下のものに出くわし、私が自分で書いているものの例としてそれを使用する許可を彼らに尋ねました。許可が付与されました:)
フレームワークを使用することをお勧めします。私は Twitter Bootstrap を使用しています。独自のスタイルガイドがあり、少ない労力で均一なレベルを保証します。