この投稿は、[ユーザー向け]インターフェースの開発に関する参照規約に関するものです。
開発者は、他の皆のような人々です。 事務言語で書かれたインターフェースについてタルムードを読むことは、おそらく非常に楽しい娯楽ではありません。 インターフェイスの専門家が技術仕様を作成し、顧客に引き渡します。 そして彼らは、設計されたインターフェースをどのように開発し修正するかについての参照条件（または仕様）を読むように頼みます。
設計されたインターフェイスの開発に関する参照条件には何が含まれますか？
通常、請負業者は作業指示書の詳細レベルに同意できます。
- これは、キーおよび典型的なインターフェース画面、画面要素（またはページ）、および特定の画面でのこれらの要素のあいまいな動作を説明する文書です。
- または、インターフェイス画面のページごとの「コレクション」の方法論を含み、画面間の接続を説明するドキュメント。 また、そのようなTKは、これまたはインターフェイス構築のロジックが適用される理由を説明できます。
- または、一般的に、ドキュメンタリー：インターフェイスに関するすべてを説明する人間工学に基づいたガイド（そして、確かに、誰もそれを読むことはありません）。
TKは2つの質問に答えるのに役立ちます
1.インターフェイスはSOで作られていますか？
2.それを使用でき、実際の開発にどのように適用できますか？
そして、ここで経験の要因が生じます。 経験豊富な開発者は実装を見て、すでに独自のビジョン、システムの実装に関する知識を持っています。 そして、ここで彼は「自転車を発明し」、せがむように求められます-仕事の声明を読むために。
TKは、理想的なものに関する素晴らしい参考資料です。
しかし、「すでにすべてを知っている」という状況を別の視点から見ることもできます。
TKについて話し合う必要があります：どこで歩くことができ、どこで-望ましくないのか、そしてその理由。 TORでは、インターフェースはユーザーにとって便利なインターフェースのアドバイスを提供します。
実生活で
インターフェイスコンセプトの開発の段階で、設計段階の前にTKについて話し合うことをお勧めします。
- できれば、実際に適用可能な技術的制限、予算オプション、および開発リソースについて議論する必要があります（そうでなければ、100万個または多くの作業を発明できます）。
- 最大限に、既存および将来の顧客の疑わしい難しさについて話し合います。彼らはコンセプトで説明したように開発した製品を使用しますか、制限はありますか、実装は可能ですか？
利益 ：開発者はより関与し、やる気があります。彼は、新しい（または変更された）インターフェース、自分の意見、および経験では適用できないものについて、実行者に警告するだけです。
最初の質問は、「インターフェイスはSO-DONEですか？」です。
SOは、ユーザーの要件（ユーザーが最初に来る）、ビジネス要件、開発要件を満たすことです。
- ビジネス要件は、プロジェクトの初期段階で議論され、修正されます。
- 開発要件は、初期段階および反復中（できればインターフェースの概念を開発する段階、および作業のドラフトを渡す段階）で、技術的な能力と制限の形で修正されます。
- インターフェースのユーザー要件-初期段階（ユーザーとのインタビュー）、コンセプト開発の段階（プロファイル、シナリオ、ナビゲーション構造、設計タスク設定時のインターフェースページの説明）。
2番目の質問は、「設計されたインターフェイスを開発に使用できますか」です。
設計されたインターフェイスは、ユーザーと対話するときに実際のシステムインターフェイスがどのように動作するかの例です。
なぜこれが彼の振る舞いなのか-繰り返しますが、それは参照条件で書かれています。 TKを作成するとき、スペシャリストはプロトタイプ全体のコンテキストでは明らかではない要素に焦点を合わせます。 特に：
-キー画面（ユーザーとの対話時に発生するインターフェイスの優先ページとプライベートページ）。
-標準画面（同様の機能と目的を持つ）。
設計されたインターフェイスが、開発とは異なる方法でユーザーと対話する場合（「...これを適用/実行することは不可能です」）、ユーザーにとってより便利であるか、開発者と技術的な制限について議論する際の計算ミスです。
したがって、ワーキンググループに開発者が存在することが望ましく、必須であり、設計の反復の結果に精通することが重要です。
しかし、理想はありません
もちろん、ユーザーは何かを尋ねたり、求めたりします（あるいはまったく尋ねないかもしれません。結局のところ、ユーザーはすべてを表明しませんが、不便に慣れて気づかないようにします）-しかし、技術的にはこれは現実的ではありません。
または、広告は_ボタンが配置されるべきまさにこの場所に表示する必要があります。そうしないと、ビジネスが曲がります。つまり、広告を表示する必要があります。
現実の世界についての逸脱は可能であり、議論する必要があるのはまさにこれらの逸脱です 。 これは、ToRで提供されます（設計されたインターフェイスの送信時に調整されます）か、開発および実装中に検出されます。
ただし、実装プロセス中に設計されたインターフェイスを変更する必要がある場合、ToRでこれを提供することもできます。このため、ToRでインターフェイスの概念を構築するプロセスの説明を含める必要があります。
そして、将来、新しいユーザー要件が発生した場合、概念をアップグレードする必要があります。
-システムの新しいユーザーを追加および説明します-そのようなユーザーが表示された場合。
-ユーザーの新しい目標を説明してください。
-ユーザースクリプトを追加または変更します。
-スクリプトの通過中に表示される画面のユーザー要件、ビジネス要件、技術的制限を書き留めて修正します。
-キーページと標準ページのリスト、およびナビゲーション構造とインターフェイスメニューを更新します。
-将来、開発された製品がすべての要件を満たしているかどうかを確認できるように、参照条件と設計されたインターフェイスを変更します。
なぜTKを読むのですか？
0.読むだけでなく、参加する。
1.開発経験は良好であり、満足しているユーザーはより重要です（顧客または従業員=>もたらすお金、時間の節約、またはその両方）。
2.開発者ではなく、ユーザー（クライアント）の経験に基づいて、ユーザーとシステムの非自明な相互作用によるエラーを防ぐため。
3. TKは、開発された製品がユーザーの要件に準拠しているかどうかをチェックするためのチェックリストとして使用する必要があります。
4. TKは、すべての関係者に害を与えずに、どのような場合にどのような順序でインターフェイスを変更するかを説明します。
そして、これはただ一つの側面図です。
TK-開発者の読者の意見を聞きたいです。