UIデザインに最適なUI仕様ですか？
ワイヤーフレームデザイン+要素の説明である仕様をUIデザイナー/アーティストに渡す際に問題が発生しました。
発生する傾向があったのは、作成された最初の数画面が確かにルーズワイヤーフレーム仕様の無料の解釈でしたが、プロジェクトの中間段階に近づくにつれて、設計はワイヤーフレーム設計を反映する傾向がありました（実際のレイアウトとして意図されたものではありませんでした）。 、新しい画面ごとに反復回数が増加します。
これは、アートだけでなくデザインの必要性を前に非常に明確にしているにもかかわらずです。
最近、そもそもワイヤーフレームを行うのは間違ったアプローチかもしれないと提案されました。各画面の要素の階層を作成し、それをデザイナーに任せるように言われました。
私の質問は次のとおりです。優れたユーザーエクスペリエンスを備えた優れたUIを作成するために設計者に最大限の支援を提供するには、どのタイプの仕様が最適ですか？
改訂された仕様の基礎として使用できるサンプルドキュメントはありますか？
編集：
明確にすると、この質問は主に契約フリーランサーの仕様に関するものです。 DA01が言うように、最初から一緒に作業し、反復を続けるのが最善です。ただし、UIデザインの契約をしている場合は、世界の反対側にいる可能性もあり、ルールはかなり異なる傾向があります。
あなたの役割は何ですか？情報アーキテクト？ビジネスアナリスト？
あなたの話に基づいて、私は次の1つ以上が起こっていると思います：
あなたは最適なレイアウトとワークフローを生み出すことに非常に才能があるので、デザイナーは常にあなたのデザインに戻ることになります。
仕様（「ワイヤーフレーム+要素の説明」が含まれている）には、設計者が独自のワークフローとタスク分析を行うのに十分なユースケースドキュメントと高レベルの情報が含まれていません。
あなたの設計者は、ワークフローとタスク分析に関する強い専門知識を持っていません。
その他のプロジェクト管理の問題。 （十分な時間がない、レビューの欠如など）
犯人が何であれ、答えはあなたがデザイナーに作成したワイヤーフレームを差し控えることではありません。ワイヤーフレームを作成しました。問題の解決に役立ちました。これらのワイヤーフレームは、設計者にとっても同様に価値があります。課題は、デザイナーが独自の分析を実行できる環境を作成することです。 （上記4項目を参照）
結局のところ、あなたは彼らに純粋な視覚的デザインとインタラクションデザイン以上のものをするように求めています。
編集：
固定価格の契約プロジェクトの場合、設計者が与えたものをできる限り再利用することにより、特に常にそうではない分析などについて、設計者がプロジェクトに費やす時間を最小限に抑えるための多くのインセンティブがあります。クライアントに提示する具体的な資産を生み出す。
したがって、ワイヤーフレーム/ワークフローを個別の成果物として具体的に要求する必要があります。これにより、設計者がこの特定のスキルセットを持っているかどうかを評価することもできます。また、ビジュアルデザインフェーズに進む前に満足できるワイヤフレーム/ワークフローに同意することで、デザイナーがデザインに戻る問題を回避できます。
（しかし、もしあなたのデザイナーがもっとお金を稼ぐ機会を与えているなら、問題＃3も良い可能性です）
反復回数の増加につながる
それが最善の方法だと思います。繰り返す、繰り返す、繰り返す。
プロセスを円滑にするために、クライアント/ビジネス、UX、UIデザイン、IXデザイン、UI開発をすべて並行して機能させるようにしてください（同じページでバックエンドの開発を行うことができる場合はさらにお勧めします）。
チーム全体が並行して作業している場合、UIフレームワークのUI設計に渡されるウォーターフレームのようなワイヤーフレームのモデルと比較して、プロセスが大幅に合理化され、UI開発者に渡され、次にバックエンドに渡されます。後者のプロセスは、フィードバックなしで他のチームメンバーに影響を与えることが決定されるため、最後まで多くの不明点を残し、必然的に全員が早い段階で見逃していた調整を行うために最後近くでスクランブルをかけています。
結局のところ、何が「最良」かは、自由に利用できる特定のチーム構造とビジネスプロセスに完全に依存します。プロジェクトごとに異なります。人々が並行して作業できるようになればなるほど、一般的にはスムーズになります。
改訂された仕様の基礎として使用できるサンプルドキュメントはありますか？
上記に関連して、もう1つの課題は、設計段階でのドキュメント化がプロジェクトのタイムラインを合理化することはめったにないということです。反復についての議論は、誰もが実際にユーザーエクスペリエンスの改善に集中しており、厄介なドキュメントを作成して維持する必要があることに集中していないということです。
もちろん、ドキュメントは重要ですが、可能な限り無駄を省きます。多くの仕様通信は、おそらく口頭で行われます。上記の主要チームと頻繁にミーティングを行います。リビジョンをノックアウト仕様書内ではなくコード内とすると、通常ははるかにスムーズに進みます。*
*「はい」という大きな注意が必要ですが、一部の組織では、通常はより大きな組織でも...上記で述べたことのすべてが実用的な解決策ではない可能性があることも完全に理解しています。多くの組織は依然としてウォーターフォール/非反復開発に取り残されており、アウトソーシング開発などの追加のハードルをミックスに投入しています。そのような状況で私が提供できるのは、巨大な「幸運！」だけです。 ;）
より良いモバイルエクスペリエンスを実現するためのスケッチング は非常に役立ちます。
要するに、スケッチにはいくつかの段階があります：
- Divergent sketching–ブレーンストーミング、結果は緩やかなスケッチになります
- 収束スケッチ–アイデアを組み合わせ、最高のものを磨き、結果として詳細なスケッチを作成し、仕様として使用し、次のように実装できます。プロトタイプ
- UIフローの作成、は仕様として使用でき、プロトタイプとして実装できます
一般的なスケッチセッションの詳細な手順については、記事をご覧ください。したがって、スケッチは優れた仕様ツールです。十分詳細に記述してください。
これは関係者のスキルセットに依存します。リーンUXを検討する価値があるかもしれません。現在のところ、最近の本であるO'reillyの本でさえも非常にスケッチ（ http://shop.oreilly.com/product/0636920021827.do ）であるという定義はありませんが、一言で言えばシェル、それはすべてのチームメンバーが関与し、アイデア生成の可視性を持っていること、およびアイデアを伝えるために成果物に依存していないことを確認することです。詳細な仕様は非常に時間がかかり、経験上、長い反復や迅速な高速反復では維持が困難です。
朝の毎日の短い会議（アジャイルで使用される）は、ウォールーム（リーンUXよりも10年以上前のアイデア）で作業し、ホワイトボードをオリジンとして使用しているように、コミュニケーションを確保するための良い方法です。プロセスのアウトプットのいくつかのための生活場所。 2000年に、英国のBootsのプロジェクトに、ページステータスのあるスプレッドシート、ホワイトボード上のサイトマップ、HTMLワイヤフレームを組み合わせて使用しました。リンクとコンテンツストラテジストを使用してHTMLページに添付されたデザインは、コピーを置くことができましたワイヤーフレームの現場-開発者は、これらすべてを使用してサイトの最終バージョンを作成しましたが、当時のサイトと比較して、やり取りの量はそれほど多くありませんでした。
これはすべて、チームメンバーの性質と場所に依存します。要するに、仕様がうまくいかない場合は、それから何を取り出すことができるか、紙の通信を対面（または私が聞いたように「高帯域幅」）通信にどこに変換できるかを確認してください。