スタイルガイドにしてはいけないことがあるのはなぜですか？
。NET アプリケーションのスタイルガイドを作成する必要があります。現在、約6人の開発者が、スタイルの面で好きなだけを行っています。同様のボタンが別の場所にあり、別のコントロールが使用されているなどです。それは混乱です。
私は他のスタイルガイドをいくつか調べましたが、それらはしばしば（常に？） not が何をすべきかを示しています。リード開発者は、「禁止事項」を省略し、「許可事項」のみを含めた方がスタイルガイドの受け取りが良くなると述べました。
なぜスタイルガイドにもやるべきでないことがリストされているのですか？
ストーリーの片側のみを提供する場合、リスナーが残りの半分を自分で記入できるようにします。これは強力なストーリーテリングツールになる可能性があります...
...しかし、状況を解釈に任せたくない場合は、ストーリーの両方側）を提供する必要があります。
何か新しいことをする方法を学ぶとき、あなたは「[私の新しいスキル]のしなければならないこと」を説明するガイドを見つけます。ストーリーの両面を提供することで、適切な動作を強化し、「正しい」と言っていることが真実であることを読者に説明し、「ここに、してはいけないことのいくつかの例を示します。理由」 。
「しないでください」がなければ、読者は提案に違反することを支持する理由を簡単に定式化できます。これは「スタイルガイド」であり、「スタイルmandate」ではないことに注意してください。読者は簡単に言うことができます：「彼らはそれを提案しましたが、これはうまくいくと思います、そして彼らは私にnotそれをする！.
しないの例（または複数の例）を提供すると、大きな影響を与えるためにいくつかのことが行われます。
- 彼らは、そうでなければ別の人々によって異なって解釈され得るギャップを埋めます。
- それらは、「見た目が良い」と「見た目が悪い」とを視覚的にフィードバックします。
- 彼らは説明なぜそれを正しく行う必要があるのか、そしてそれを正しく行わないとエクスペリエンスにどのように影響するのかを説明します。
- 彼らは読者にあなたが話していることを知っている！を示します。これはあなたの主観的な好みでいっぱいのスタイルガイドではなく、物語全体を通して読者に「これが正しい」理由を理解させますそして「それは悪い」。
主要ブランドのヒューマンインターフェイスガイドライン（スタイルガイド）をご覧ください。それらはすべて[〜＃〜] dos [〜＃〜]およびDO NOTSを含み、理由を説明し、および/または適切な代替を提供します：
iOS： 
Android： 
OSX： 
Windows： 
UXでのDoと同じくらい重要ではありません
設計フレームワークは前向きな実践と原則（すべきこと）の説明に焦点を当てるべきですが、一般的な落とし穴、アンチパターン、およびエラーを回避するためのガイダンスを提供することが重要です。
いくつかのベストプラクティスは、ポジティブよりもネガティブで明確に表現する方が簡単です。たとえば、どれが理解しやすいですか？
- Doユーザーがコンテンツを読んでいるときにコンテンツが移動しないようにします。また、doは、重要であると想定されるコンテンツが画面上に同時に表示されることを保証します（つまり、表示されている要素と非表示の要素に誤って偏ることがないようにします） ）。
- カルーセルを使用しないでください。
前向きなガイダンス（＃1）に従うことで、カルーセルの使用を回避する必要があります。しかし、そのためには、デザイナーが抽象的なガイドラインをよく理解し、ガイドラインを特定のウィジェットに適用する方法を理解する必要があります。
カルーセルは人気のある具体的な要素であるため、アンチパターンを特に「禁止」としてカバーすることは非常に役立ちます。 2つは相互に排他的ではありません。たとえば、肯定的な原則を明確に示し、回避すべき一般的なアンチパターンを指摘することもできます。
この原則はUXに固有のものではありません。これについて開発者と話し合っているので、ほとんどの開発ガイドラインでも、すべきこととすべきでないことを組み合わせて使用していることを指摘しておくと役立ちます。たとえば、 zen of python には、次の禁止事項が含まれています。
Errors should never pass silently.
In the face of ambiguity, refuse the temptation to guess.
...そして Android設計原則 には、これらの欠点が含まれています。
Never lose my stuff
Don't interrupt me unless it's important
リーダーと通信するための重要なメッセージはdoではなく、-do n'tでもありません。 2つの間のdifferenceです。
2つを並べて表示することで、この違いを可能な限り可能な限り明確に伝えます。 2つのうちの1つだけを表示すると、実際にどのような違いがあったかは推測されません。
また、誰かがミスをして、ガイドを参照するときにも役立ちます。ガイドにしないでくださいの例があり、ガイドが行ったことと正確に一致している場合、修正はより明確になります。
DOの例が製品にプラスの影響を与えるよりも、実際に製品にマイナスの影響を与える可能性のあるDO N'T DOの例がいくつかあることがわかりました。よく考えられたナビゲーションシステムがあり、1つの画面から別の画面への流れが完全に理にかなっている場合でも、色のコントラストやフォントの選択が悪いと、製品の電源がすぐに切れます。
ソフトウェア開発では、DO N'T DOの例を「アンチパターン」と呼びます。してはいけないことを示すことで、過去に見た例を特定し、重大な間違いを防ぐことができるという利点があります。
適切な使用法と不適切な使用法の例を示すことは、頭に浮かぶいくつかの理由から素晴らしいことです。
- 悪い行動に対して並置された良い行動の強化。
don'tがないと、実装時に開発者が離れすぎてしまう可能性があります。 - 一部の人々は視覚的な学習者です。 例：「行の高さは1.5である必要がある」と言っても、他の行の高さによる読みやすさの例が示されていないと理解できないわけではありません。スタイルガイドは、ガイドラインを実施する機会ですが、意思決定の価値を他の人にも教えます。
Don't'sインタラクションを検討し、一貫性を確保したいことを証明する資料を作成します。開発者が意図的にまたは別の方法でdon'tを実装する場合、ポイントへのバックアップとして参照する具体的なものがあります。
私は自分のアプリケーションでスタイルガイドを自分で使用しています。UIだけでなく、決定の背後にある根拠も文書化していることが、最も強力な利点の1つであることがわかりました。お役に立てれば。
スタイルガイドに「黒のみ」や「4pxの丸みを帯びた角」などの適切な「do's」がある場合、実際には必要ありません。デザイナーの観点から見ると、このアプローチは創造性を制限する可能性がありますが、アプリケーションのインターフェースの一貫性を確実に向上させます。
多くの人々は自然に素晴らしいアイデアをたくさん持っているし、それほど素晴らしいアイデアもたくさん持っている。開発者が物事を行うためのさまざまな方法のリストを与えられても、リストが実行する必要があるすべてを行う方法を記述していない場合、開発者はリストにないものを行う方法を発明する必要があります。問題がすぐに明らかにならない場合、何かを行う方法についての最初のアイデアがたまたま悪いものである開発者は、その悪いアイデアを開発する時間を浪費する可能性があります。魅力的であるように見えるかもしれないが実際にはそうではない多くのアイデアを知っている開発者は、悪いアイデアをより迅速に認識することができ、したがって、それらに多くの時間を費やすことを避けることができます。
より一般的には、何かの良い点を本当に理解するには、代替案の悪い点を理解する必要があります。多くの場合、歴史の最も興味深い教訓は、何が成功したかを知ることからではなく、代わりに、回避すべき偽の経路が存在することを知ることから得られます。