GUIを指定する通常の方法は何ですか？
特定のアプリケーションのGUIの設計上の決定と対話パターンを指定するための典型的な、または最も効果的な方法は何ですか？
私は、正確なGUIまたはユーザーインターフェイス仕様の部分が何であるかを本当に知らないことに気付き始めました。
- 設計上の決定、特に開発者とのコミュニケーションに必要な決定を文書化するにはどうすればよいですか？
- ボタンを押す/ジェスチャーまたはその他の操作の後に何が起こるかを文書化するにはどうすればよいですか？
Communicating Design を読むことをお勧めします。これは、UIが通常どのように文書化されているかの詳細について説明しています。
一般に、ドキュメントのレイヤーがあります：
- システムに連絡する人（コンテキスト図やペルソナ）
- 彼らがシステムを使用する目的（ユースケースリスト、おそらくユーザーストーリー）
- 各ユースケースの使用の流れは何ですか（flow diagram）
- 各ステップでの画面の外観（wireframes）
- 採用されている視覚的および相互作用のパターンは何ですか（パターンライブラリ）
- 使用される実際のビジュアル言語は何ですか（ウィジェットライブラリ、実際のレイアウト）
おそらく、フロー図、ワイヤーフレーム、ウィジェットがおそらく最も重要なものでしょう。
これらはお互いの上に構築されています。ペルソナには目標があり、これらの目標に到達するために、システムは特定の事柄（ユースケース）にシステムを使用します。システムには、一種のフローまたはプロセス（フロー図）、画面自体があります。どういうわけか（ワイヤフレーム）を見る必要があり、それらの間（パターン）に一種の一貫性があるはずです。これらは実装する必要があります（ウィジェットとレイアウト）。
有名な組織内パターンライブラリについては、 Yahooパターンライブラリ をご覧ください。
ワイヤーフレームについては、Balsamiq Mockups、Konigi Wireframes、 Wireframe Showcase をご覧ください。
面白いのは、私たちが構築するシステムについてユーザー中心であるということですが、私たちが生み出すアーティファクトについてはそれほどではありません。
設計の決定と相互作用パターンを指定する最も効果的な方法は、誰と通信するか、およびその理由によって異なります。正しい方法はありません-特定の状況では正しい方法しかありません。
たとえば、他の製品開発チームと同じ場所にいる場合、コミュニケーションの最善の方法は...まあ...話したり、開発者とペアを組んだり、またはホワイトボード。
まだ作成されていないアウトソーシングチームのために何かを作成する場合、別のプロジェクトに取り掛かるときには、アーティファクトの完全なスイートのようなものを探している可能性があります。から http://unify.eightshapes.com/
他のプロジェクトと同様にドキュメントを扱います-エンドユーザーが必要とすることを行います。
これらはまさにあなたが求めているものではありませんが、あなたが達成しようとしていることに役立つかもしれません-
ワイヤーフレーミング- サンプルワイヤーフレーミングツール のリストを示します。ほとんどがワイヤーフレーム化はウェブデザインのために行われますが、それでもいくつかのアイデアは有用かもしれません。
プロファイティング-これを試すことができます プロファイリングツール とthe鉛筆 両方のようなものです。
少し外れたトピックかもしれませんが、 この議論 も少し洞察を与えることができます。