私たちは現在、ワークフローを修正している小規模なWebデザインチームであり、ワイヤーフレームをどのように処理するか疑問に思っていました。
ワイヤーフレームを使用していますか?使用している場合、どれくらい抽象的または具体的ですか?実際のコンテンツ(テキスト、画像など)を使用しようとしていますか、それとも長方形とブラインドテキストだけを使用していますか?なぜそうするのですか?
質問は非常に広範に感じますが、できる限り最善の方法で取り組みます。
詳細な回答:
言うまでもありませんが、これはプロセスの最も重要な部分です。要件の収集は、要件を一覧表示する単なる方法ではありません。要件を理解することは非常に重要です。顧客がドメインをどれだけ理解しているか、エンドユーザーであるワイヤーフレームを理解するのに十分な能力があるか、エンドユーザーが何を求めているかを把握する...
最初のフェーズで収集できる情報の量に文字通り制限はありません。なぜこれが問題に関係があるのか疑問に思っているのなら、それが理由です。
ワイヤーフレームがどのように抽象的または特定的である必要があるかを理解するのに役立ちます。
プロジェクトのサイズに基づいて、各ステップの大きさを定義します。そして、それは最初のステップであるべきものを定義します。
小規模なプロジェクトの場合、Balsamiqを使用してローファイのモックを準備し、すべての関係者に画面上の項目とインタラクションフローについて同意させてから、直接プロトタイプを作成しますXDまたはダミーデータを含むPOC(顧客からいくつかのデータを取得してください)
大きなプロジェクトの場合、手描きのワイヤーフレーム、最初にローファイワイヤーフレーム(Basamiqなどを使用)、次にハイファイワイヤーフレーム/プロトタイプ( InvisionまたはAdobe XDを使用して)、最終的には作業用POCを使用することもできます。
ワイヤーフレームやモックアップに使用する方法やツールが何であれ、更新が簡単であることを確認してください。適切な適合が見つかるまで繰り返し続け、1回の反復であまりにも多くの変更をダンプしないようにします。そして、各イテレーションを個別のバージョンとして記録し、すべてのバージョンを保持することを忘れないでください!私を信じて、私は難しい方法を学びました。
私の経験では、それは次の条件によって異なります。
a)プロジェクトの大きさ、または複雑さ
b)プロジェクトに取り組んでいる人の数、またはワイヤーフレームを使用する人の数
私たちのケースでは、次のことが示されています。
スケッチ、クラフト、インビジョンは、ここで機能する優れたスタックです。
私が考えることができる最も詳細なプロセスは次のようになります:
handrawn⟹handrawnハイフィデリティ⟹デジタルロー⟹デジタルハイ⟹クリック可能⟹ビジュアルデザイン
2つの考慮事項:
ワイヤーフレームの主なユーザーグループは、おそらく開発者です。したがって、実際には、ワイヤーフレームは必要なものをすべて提供する必要があります。一部の企業では、レイアウト、サイズ、色などを提供する設計ドキュメントがないため、開発者はhi-fi仕様を必要とします。ビジュアルデザインチームがhi-fiのグラフィカルな詳細を提供している場合は、ワイヤーフレームがよりボックス状になることがあります。必要なものをWFが提供しているかどうかについて、開発者とよく話し合ってください。
ワイヤーフレームをクライアントに提示しますか? lo-fiワイヤーフレームは、クライアントを機能性に集中させるのにより効果的です。機能やナビゲーションを提示しようとしているときに、クライアントがワイヤーフレームのフォントや色について文句を言うのはイライラします。
要するに、ワイヤーフレームが彼らが提供する必要がある目的を果たすようにしてください。
私は常にワイヤーフレームを作成しています。 最初に要素の基本構造とソリューションのフローに高いレベルの信頼がなければ、ビジュアルデザインとインタラクティブ機能の作成に時間とリソースを投資したくありません。ワイヤーフレームを作成する方がはるかに高速です。 、それをテストし、変更し、反復して、設計されたインタラクティブなプロトタイプを使用して繰り返しテストおよび変更するよりも、自信が持てるまで繰り返します。
ワイヤーフレームの忠実度(画像vsプレースホルダーなど)になると、反復プロセス中に変化します。一般的に、私は非常に低fiを開始し、インタラクティブ性とビジュアルデザインを追加するときまで詳細を追加します。 。完成した製品ではなく、大まかなコンセプトが表示されていることをユーザーや利害関係者に明確に伝えることが、特に低fiワイヤーフレームでの混乱を軽減するための鍵です。
ワイヤーフレームについて最も重要なことは、しっかりとした調査に基づいている必要があるということです。ユーザーが誰であるかを本当に理解すると、ユーザーが何をしようとしているのか、どのようにしているかがわかります現在それを行っていますが、それがどのように改善される可能性があるのか、ソリューションの目標到達プロセスは本当に狭くなり、ワイヤーフレーミングプロセスは迅速に進みます。
ですから、数年後、できる限りワイヤーフレームを削除する(または大幅に削減する)ことをお勧めします。ここにいくつかの理由があります:
誰もがワイヤーフレームがあなたの主要な成果物であると考えています。ワイヤーフレームの背後で発生する必要な作業を理解している人はほとんどいません。ロジック、コンテンツのマッピング、情報の計画、意図など。
ワイヤーフレームはデザイナーを制限します。私はデザイナーがワイヤーフレームを実際には必要としないことを発見しました。彼らが必要とするのは、それぞれの背後にあるロジックであり、インターフェースとデザインを自由に実装できるようにすることです。
クライアントは、ラベル付けとコンテンツに追いつきます。ワイヤーフレームのプレースホルダーであるものについて話し合うことは、多くの時間を浪費します。
無駄な努力。簡単に言えば、すべての欠点とプロジェクトの実行に必要な時間を考慮すると、ワイヤーフレームは時間の価値がありません。
私が提案すること:
私は他の回答を簡単に読みましたが、他の誰かが私がこれからしようとしていることを言ったとは思わないので、私はニコラスに同意しません。
私がワイヤーフレームのレベルで取り組んできたビジネスでは、開発チームの信頼と、デザイナーがいるかどうかに大きく依存します。ほぼ完全なデザイン。
私は両方をやった。
このようにして、アジャイルから100万マイルも離れていません。
なぜニコラスに同意しないのですか?.