Uxデザイン
ワイヤーフレームの死。ストレートからハイフィデリティ！
UXデザインは魅力的な分野です。それをうまく行うには、開業医はさまざまなトピックやスキルに精通している必要があります。ユーザー中心の設計手法を実践し、日常の製品設計の課題に対する使いやすく革新的なソリューションを作成するために、UX実践者の技術と理解には、基本的な描画から物語/旅の設計、認知心理学までのすべてが含まれます。
さまざまなツールが使用され、アーティファクトが生成され、調査結果が明らかになりました。 UX/UI design プロセス、およびそれらはドキュメントの品揃えまたはプロトタイプでさえキャプチャされます。私たちの最も有名なパンとバターのアーティファクトは、古き良きワイヤーフレームです。
設計原理の定義
ワイヤーフレーム（通常、迅速な評価のために作成されたデザインのモノクロスケルトン）は優れています。これにより、関係のない多くの関係者からの入力を、誰もが確認できる1つのドキュメントに変換できます。多くの異なる職務がワイヤーフレームを評価します。ビジネスアナリスト、プロジェクトマネージャー、マーケティングエグゼクティブ、あらゆる種類のデザイナーや開発者、その他のさまざまなベンダーやサービスプロバイダー、さらには製品テストの対象者。ワイヤーフレームを使用すると、誰もが個々のニーズにどのように対処するかを確認でき、重い物を持ち上げる必要が生じる前に、チーム全体ですべての問題を解決する機会が得られます。
長所と短所がありますが、場合によっては、ワイヤーフレーミングフェーズを完全にスキップすることが理にかなっています。発見直後またはプロトタイピングの準備中に、UXとビジュアルデザインを忠実度の高いレベルで処理することで、多くの時間を節約できます。これにより、ユーザーテストの参加者からクライアントや同僚まで、製品の機能とルックアンドフィールの両方を同時に評価する機会が他の人に与えられます。
ワイヤーフレームが問題になることがある理由、それらをスキップすることが理にかなっている場合、およびワイヤーフレームを適応させる方法を調べてみましょう。 ワイヤーフレームなしのプロセス ワークフローに。
ワイヤーフレームの問題
ウォーターフォール環境であろうとアジャイル環境であろうと、典型的な設計プロセスには、調査、定義、アイデア作成、プロトタイピング、テスト、および展開のフェーズと、途中で利害関係者とレビューするための多くのタッチポイントが含まれます。
ワイヤーフレーム設計がボトルネックになる可能性がある場合の例について、設計プロセスを見てみましょう。
理由1：クライアントは自分が見ているものを理解していない
設計プロセスは通常、問題に関する何らかの調査から始まります。デスクリサーチ、利害関係者インタビュー、およびユーザーインタビューは、より深い理解を得るために行われる可能性のある活動のほんの一部です。調査後、設計チームは最適なソリューションを見つけるために、いくつかのアイデアや概念の評価を開始します。
コンセプトがより具体化されると、設計チームはレビューセッション中に一連のワイヤーフレームをクライアントと共有することがよくあります。
問題は、ワイヤーフレームが非常に抽象的なことです。
彼らは何かを説明します お気に入り 物事、しかしではない 電流 構築されるもの。この段階では、ワイヤーフレームには、プレースホルダーイメージと、次の例のようなあらゆる種類のTK（今後）、FPO（配置のみ）、およびTBD（未定）が含まれます。
注釈の膨大なリストに示される機能、ビジネス要件、およびエラー処理に関する詳細がおそらくあります。通常、これらを詳細に調べるのに十分な時間はないため、クライアントは自分でそれらを読む必要があります。
ワイヤーフレームのレビューでは、説明されている概念に焦点を当て、それがビジネスとユーザーの問題を解決しているように見えるかどうかを評価するようにクライアントに依頼します。ただし、私たちには関係がないと思われることについては、まだ質問があります。クライアントは、ワイヤーフレームが「最終コピー」であるかどうか、またはヒーロー画像に表示される写真の例を見ることができるかどうか、またはビジュアルデザイン、UIプロトタイピング、または開発で処理されるものについての別の質問を知りたいと考えています。
ワイヤーフレームは、クライアントや内部の利害関係者でさえ効果的に評価するには抽象的すぎる可能性があります。ワイヤーフレームは、デザインが完成したときにどのようになるかを人々に伝えますが、それでも、頭の中でデザインをまとめるには、精神的に多くの作業を行う必要があります。私たちのクライアントは視覚的な思想家である場合とそうでない場合があり、青写真を見て成功する製品やサイトを想像することを期待するのは多すぎるかもしれません。
点をつなぎ、思慮深く議論し、よく考えられたフィードバックを提供する方がはるかに簡単であるため、注釈付きのビジュアルデザインのレビューを特に要求したクライアントが数人いました。
理由2：ユーザーテストに常に適しているとは限りません
コンセプト全体の実現可能性からトランザクションで表示する詳細レベルまですべてをテストするための優れた方法であるため、いくつかのユーザーテストが設計プロセスにスケジュールされていることを願っています。
これらの種類のものをテストする1つの典型的な方法は、プロトタイピングを使用することです。
ワイヤーフレームは、プロトタイピングに使用できます。設計チームはテストフローと機能のみに制限されており、視覚的なデザインレイヤーがないため、ユーザーの行動に影響を与える視覚的なスタイルは簡単に無視できます。
これは賢明ですか？ UX、ビジュアル、コピーのデザインはすべて互いに影響を及ぼします。それらを分解して、テスト環境で分離することは困難です。科学的研究と同様に、単独でテストされた1つの関数の結果は、それが実際にどのように動作するかを制御したり、予測したりすることはできません。
場合によっては、これらすべてを総合的にテストする方が効果的です。
適切な例：多言語の製品またはサービス。言語は、全体的なデザインに影響を与える可能性のある異なる文法、アルファベット、および文字幅を持っている場合があります。
さらに、コピーコンテンツはUXに影響を与えるため、翻訳自体がUXに影響を与える可能性があります。
たとえば、さまざまな概念を現地の言語で説明する必要があるため、いくつかの異なる情報アーキテクチャをテストする必要があるという課題がありました。 UIで実際のコピーをテストしなければ、コピーライティングと翻訳への影響を発見することはできなかったでしょう。
ローカル言語で同様の概念を説明するにはさらに多くの単語が必要であり、その言語に必要な冗長な表現に対応するためにボタンのサイズと形状をグローバルに変更する必要があることがわかりました。 UIで実際のビジュアルコンポーネントをテストする際にテキストの問題に焦点を当てなければ、ボタンがモバイル画面の全幅を占める必要があることを発見できなかったでしょう。これは、今後のUXデザインに影響を与えました。
重要なポイント：特に多言語プロジェクトの場合、最初から忠実度の高いUIを準備することは理にかなっています。
理由3：開発者とQAの人生を地獄にする
ビジュアルデザインの段階で必然的に起こることは、すべてが動き回ることです。積み重ねられた画像はタイルになります。中央揃えのテキストは左揃えになります。アコーディオントリガーアイコンは+でしたおよび-ですが、現在は2つのシェブロンになっています。
これはの正常な部分です ビジュアルデザイン 処理する。また、ワイヤーフレームが「サインオフ」されているため、ビジュアルデザインに加えられた変更がワイヤーフレームに反映されないのも正常です。
人々のクレジットカード番号をオンラインで取得する方法
すべてのビジュアルが承認されたら、すべてを開発者に引き渡します。ほとんどの場合、詳細な注釈付きワイヤーフレームのセットと美しいビジュアルデザインのセットがスタイルガイドとともに提供されます。これら2つのドキュメントを相互参照し、すべてを実現するのは彼ら次第です。
これは、設計プロセスが実際に失敗する可能性がある領域です。開発者に参照するには多すぎるドキュメントを提供し、どの情報が優先されるかを決定するのは開発者に任せています。これにより、サポートコールとQAに必要な時間が長くなり、製品やアップデートを市場に投入するのにかかる時間に自然に影響します。
なぜ与えないのですか 開発者 1 すべてを含む正確な文書？ほとんどのクライアントは、作業の完全なリファレンスとして使用するコピーも歓迎します。
解決策：ワイヤーフレームをスキップする
明らかに、完全なワイヤーフレームフェーズが必要な場合とそうでない場合があります。ハイフィデリティに直行すると、ワイヤーフレームフェーズが完全に切り替わる場合もあります。
これらのいずれかに該当する場合は、ワイヤーフレームフェーズをスキップすることを検討してください。
しっかりとした参考資料があります。
実施されている既存の作業を見てください。利用可能な詳細なUIリファレンスがすでにある可能性があります。既存のウェブサイトを更新したり、既存のアプリに新しい機能を追加したりする場合は、現在のウェブサイトとアプリを調べて、再利用するパターンとスタイルを見つけてください。
既存の作業のソースファイルにアクセスできればさらに良いでしょう。一部の機能や要素は、いわば開発プロセス中に翻訳で失われる可能性があります。ソースファイルを参照して、その機能がどのように実行されるべきかを確認できます。
既存の製品またはサイトに加えて（または存在しない場合）、スタイルガイドまたはパターンライブラリが配置されているかどうかを確認します。クライアントはすでにいくつかのブランディングとビジュアルデザインの仕事にお金を払っているかもしれません、そしてこれらのリソースはあなたのプロジェクトのために再び再利用されるかもしれません。
忠実度の高い出力が可能な限り正確になるように、できるだけ多くのスタイルとパターンを使用してください。
プロジェクト管理ソフトウェア比較チャート
途中で、多くの反復的なプロトタイピングとテストをスケジュールしました。
数週間にわたるプロトタイピングとテストの労力を節約してください。初めてドキュメントを慎重に設定し、繰り返されるスタイル、パターン、および 記号 、高忠実度でインクリメンタル更新を簡単に作成し、プロトタイピングワークフローに直接公開できます。ワイヤーフレーミングは必要ありません。
大きなプラスとして、1つの石で2羽の鳥を殺すことができます。 UXフィードバックと一緒に視覚的およびUIフィードバックを取得し、これらすべての変更を一度に行うことができます。
あなたのテスト参加者は非常に文字通りです。
クライアントや同僚が具体的な例を必要とする場合があるのと同様に、プロジェクトの対象読者も同様です。
最近のあるギグでは、識字率の低いターゲットオーディエンス向けの金融スクリーンをデザインしました。読解だけが問題ではありませんでした—抽象的な概念はしばしば対処するのが非常に困難でした。このターゲットオーディエンスは通常、具体的な例を使用して財務概念について話し合う必要がありました。そうでなければ、彼らは実際に会話を追うことができませんでした。
財務の概念を理解するために、このオーディエンスのテスト参加者は、実際に取引しているように感じる必要がありました。また、製品がどのように機能するかを理解するには、実際のアプリケーションのように見える必要がありました。
このような聴衆のためのワイヤーフレームを忘れてください！あなたは彼らが何であるかを説明することに多くの時間を費やすことになります—そしてあなたの聴衆は彼らが彼らの生活の中でそれほどなじみのないものを使うことに関係することができないので彼らが仕事に集中することも彼らが彼らについてどのように感じるかについても集中しません。
クライアントの時間や予算は限られています。
時間、リソース、予算がすべてあなたに有利になることはめったにありません。多くの場合、範囲と価格を絞り込もうとしたり、スクランブルしてどこでスクランブルして保存し、クライアントに優れたサービスを提供できるかを確認しようとしていることに気付くことがあります。
SQL Server2012でのクエリの最適化
完全なUXワークアップを行う余裕がない（または購入する可能性が低い）クライアントがいる場合は、ワイヤーフレーミング時間を短縮することをお勧めしますか？必要に応じて内部でいくつか作成しますが、クライアントのためにプロジェクトを動かし続けます。実際の具体的なデザインをテストし、クライアントに実際の作業に反応させます。
ワイヤーフレームフェーズを強制終了する方法
この部分は、個人のワークフローとクライアントの特定のニーズに依存するため、かなり主観的です。
そうは言っても、これはプロセスの「テンプレート」であり、最初はワークフローに適応させてから、この方法で作業する練習を重ねるにつれて微調整することができます。
ステップ1：通常の調査と発見のプロセスから始めます。
インタビュー、フィールド観察、机上調査、競合分析-あなたが通常行うこと（または行う予定があること）が何であれ、通常どおりにこのフェーズを完了します。
ステップ2：途中で少しスケッチします。
調査を行っていると、便利なレイアウトやパターン、魅力的なフローなどのアイデアが得られるでしょう。通常の方法でこれらを記録します。私はノートにサムネイルスケッチを作成し、その横にメモを書くのが好きです。ホワイトボードにスケッチしたり、興味深いUIパターンのスクリーンショットを撮ったりすることをお勧めします。良いアイデアを思い出すのに役立つものは何でも、それを実行してください。
ステップ3：忠実度の高いドキュメントを準備する
選択したデザインツールを開き、ドキュメントを適切に設定します。アートボードのサイズをいくつか選択して、繰り返し可能な形状、グループ、およびシンボルの作成を開始します。
時間をかけてブランドのカラーパレットを個別の見本として保存し、タイプスタイルを作成して整理し、必要に応じてすべての形状に適用できる標準のドロップシャドウとフィルターを作成します。
あなたのシンボルを正しくするために多くの時間を費やしてください。状態に応じて、4つの異なる色を持つことができるボタンがあるかもしれません。可能であれば、シンボルオーバーライドを利用して、必要に応じてさまざまな色やテキストラベルを簡単に適用できるようにします。
カスタムアイコンを使用している場合は、それらを個別のシンボルとして正方形のアートボード（または適切な形状）に保存します。そうすれば、適切な間隔と配置を維持しながら、それらを簡単に拡大および縮小できます。
ステップ4：設計を開始します。
この方法で作業し、スタイルガイドがどこに保持されているか（どこに保持されていないか）を確認することに慣れているため、最初のラウンドは少し荒いかもしれません。まだ定義されたスタイルがないパターンのソリューションを作成するだけでなく、すべてのスタイルを正しくするためにかなりの調整を行うことを期待してください。
このプロセス全体を通して、適切な「コピーの方向性」を使用するか、ある場合は実際のコピーを使用してください。 「ページタイトルはここにあります」というタイトルを付けないでください。視聴者に何を感じさせる だろう それが本物だったらここに行きなさい。
同様に、電話番号555-1212でジョンスミスと言う名前のリストを作成しないでください。ランダムリストジェネレーターまたはプラグインを使用して、異なる名前と番号を作成するか、表示する必要のあるデータセットを作成します。これはやり過ぎのように思えるかもしれませんが、レイアウトと文字幅の問題を解決し、視聴者がこれら5つのエントリがすべて異なることを理解するのに役立ちます。
ux / uiデザイナーポートフォリオ
ステップ5：設計をいつ停止するかを知る。
本当に時間がかかりすぎるため、現時点では注意を払うべきではない詳細がいくつかあります。おそらく、ヒーローに入る正確な画像を選択するか、ダウンロード状態を示すカスタムアイコンをデザインすることです。これらは、プレースホルダー画像またはアイコンを使用して、後日実際の画像または図像をテストすることを選択する場合があります。
プロジェクトの目的やプロジェクトの進捗状況によって異なるため、ここで何が適切かを確認する必要があります。
作業を適切に評価するために、ユーザーテストの参加者が何を必要としているかによって異なる場合があることに注意してください。私が上で述べた識字率の低いターゲットオーディエンスにとって、あまり詳細なことは何もありませんでした。参加者ごとに、本名と電話番号を使用してプロトタイプのバリエーションを作成し、アプリケーションが実際に「彼ら」であるかのように感じられるようにしました。彼らが想定しなければならないことが少なければ少ないほど、彼らは従うのがより簡単になり、私の結果はより良くなりました。
ステップ6：高品質のフィードバックとテスト結果をお楽しみください。
選択したプロトタイピングツールにデザインを公開し、テストのためにフィールドに持ち込みます。機能だけでなく、フィードバックを得ることができるようになりました。色のコントラストや読みやすさの問題など、潜在的な視覚的な問題を発見したり、コピーの方向や翻訳の問題を発見したりできます。また、ユーザーがルックアンドフィールやブランディングについて抱く可能性のあるポジティブまたはネガティブな感情を引き出すこともできます。
これらはすべて、ビジュアルデザインの段階に達したときにとにかくフィードバックを得るつもりだったものです。今すぐすべてのフィードバックを受け取ってみませんか？ビジュアルに関するフィードバックの一部はUXに直接影響する可能性があり、その逆もあり得ます。そのため、可能であれば、これらすべてを同時に解決することをお勧めします。
まとめ
間違いなく、プロジェクトを成功させるために完全なワイヤーフレームフェーズが必要な場合が多くあります。レスポンシブWebアプリケーションのような複雑な設計では、ワイヤーフレームに個別に専念する必要があります。完全なビジュアルレイヤーがすでに概念化されて適用されている場合よりも、ワイヤーフレームの段階ですべてのビジネス要件、エッジケース、およびエラー処理を解決するための時間と費用を節約できます。
ただし、適切な場合には、忠実度を高くすることでプロセスを改善できます。
- 利害関係者のフィードバックを改善する 。クライアント、開発者、他の設計者、およびターゲットオーディエンスのテスト参加者は、得られるものを正確に確認できるため、より高品質のフィードバックを提供できます。
- プロトタイピングワークフローをスピードアップ 。デザインをすぐにテストできるようになるだけでなく、UX、コピー、ビジュアルなど、さまざまなことについて一度にフィードバックを得ることができます。
- クライアントと開発者に単一のドキュメントを配信する 。ボタンがどのように機能するかを理解するために、相互参照してさまざまなドキュメントを確認する必要がなくなります。これは、クライアントが社内の利害関係者と作業について話し合い、さらに多くのフィードバックを得るのに最適な方法でもあります。
- 時間とお金を節約する 。そして、それはほとんど常に良いことです！
参照する既存の設計資料があるプロジェクトがある場合、または作業の忠実度が低いか高い場合に視聴者に大きな違いをもたらすプロジェクトがある場合は、このアプローチを試してみてください。
•••
