UIデザイン批評を実行する方法

公開: 2022-03-10
簡単な要約↬批判は簡単です。 誰もが意見を持っているようですが、著者のハーラン・エリソンが指摘しているように、「あなたには意見を述べる権利がありません。 あなたはあなたの情報に基づいた意見を得る権利があります。」 ただし、情報を得るには、調査が必要です。 デザイン批評は、製品探索の重要な部分です。 作成者がチームの他のメンバーやクライアントと作成について話し合い、説明する設計批評は、設計者にバッジを付けたり、設計者が下したすべての決定を正当化するように促したりすることではありません。 それはただの批判です。 優れたデザイン批評は、デザインを調査し、それが機能している場所と改善できる場所を見つけることを目的としています。 うまくいけば、デザイン批評はチームの全員が聞いたことがあるかのように感じ、クライアントが貴重なフィードバックを与えることを可能にします。

批判は簡単です。 誰もが意見を持っているようですが、著者のハーラン・エリソンが指摘しているように、「あなたには意見を述べる権利がありません。 あなたはあなたの情報に基づいた意見を得る権利があります。」 ただし、情報を得るには、調査が必要です。 デザイン批評は、製品探索の重要な部分です。

作成者がチームの他のメンバーやクライアントと作成について話し合い、説明する設計批評は、設計者にバッジを付けたり、設計者が下したすべての決定を正当化するように促したりすることではありません。 それはただの批判です。 優れたデザイン批評は、デザインを調査し、それが機能している場所と改善できる場所を見つけることを目的としています。 うまくいけば、デザイン批評はチームの全員が聞いたことがあるかのように感じ、クライアントが貴重なフィードバックを与えることを可能にします。

SmashingMagの詳細

  • Webデザイン批評:ハウツー
  • あなたの恐れに立ち向かう:研究のために人々に近づく
  • 批判を設計するために効果的に対応する方法
  • レインボースプレッドシート:コラボレーティブリーンUXリサーチツール

あなたが批評を実行している人である場合、建設的な批評を得るのは、特にデザイン批評の形式の経験がないグループでは、しばしば挑戦です。 アジャイル環境では、多くの場合、コーダー、プロジェクトマネージャー、プロダクトマネージャー、その他の分野の人々がフィードバックを提供します。どこにでも早く行きたい場合は、期待にすばやく対応する方法を知っておく必要があります。 。

ジャンプした後もっと! 以下を読み続けてください↓

優れたUI批評を実行するための原則

私自身の経験から、ユーザーインターフェイス(UI)の設計批評は、製品の設計および開発プロセス全体を通して、少なくとも毎週、場合によっては毎日、特定の時間に実行する必要があることがわかりました。 それらは製品設計を軌道に乗せ、インタラクティブなアジャイルまたはリーンUX製品環境ではさらに重要になります。この環境では、設計は展開前に複数の反復を経ます。 UIデザインの批評を実行することは挑戦であり、決定を説明するだけでなく、他のアイデアに注意深く耳を傾ける必要があります。

画像の説明。
批評はあなたのチームが一緒に作成することを可能にします。 (画像:ジェイミー・カミングス)(拡大版を見る)

すべての批評の最初に、「ルール」ではなく明確な原則を確立することが不可欠です。 独断的で制限を感じるルールとは異なり、原則は誰もが期待を理解するのに役立ちますが、それでも必要な自由形式の議論を可能にします。

これらの期待の中で最も重要なのは、なぜあなたが実際にあなたが見ているものを批評しているのかについて全員が同意することです。 JasonUlaszekは次のことを推奨しています。

批評しているデザインの背後にある目的や意図について尋ねることから始めます。 なぜこの情報を求めているのですか? 私たちがそれを求めることを可能にするどのような期待が設定されていますか? 私たちはそれで何をしますか? これらの質問に答えることができれば、要素の必要性を解釈するさまざまなオプションと、各オプションのそれぞれの長所と短所について説明します。

批評
見せて伝える準備をしてください。 (画像:Jason CranfordTeague)(拡大版を表示)

このガイドラインを守るために、UIデザインに関係するかどうかに関係なく、デザイン批評に適用する可能性のある標準的な原則に従うことをお勧めします。

  • 敬意をはらう。 。 決まり文句に聞こえるかもしれませんが、批評の全員がテーブルの他の人の意見やスキルを尊重しない場合、批評はすぐに敵意に陥ります。
  • 役割を指定します。 。 始める前に、批評中に誰がどの役割を担うかを明確にします。 誰もが取り残されていると感じないように、これらを批評から批評へと混ぜ合わせるのが最善であり、3つの主な役割が異なる人々である場合に最適です(しかし、それは常に実用的ではありません)。
    • プレゼンター。 これは、デザインとその背後にある考え方を提示する責任者です。 この人はすべての質問に答えるか、それらに答えることができる批評の他の人々にそれらを導きます。
    • モデレーター。 可能であれば、この役割は、設計に直接責任を負わない人、多くの場合、プロジェクトまたは製品マネージャーによって実行されるのが最善です。 モデレーターは、全員がトピックにとどまり、全員の意見が聞かれることを保証します。
    • メモを取る人。 この人物は、議論された内容を記録することに焦点を当てており、批評の最後に持ち帰り(別の原則、以下にリスト)が明確に定義されていることを確認するために特に重要です。 メモを取る人は、チームの他のメンバーに彼らが言ったことを明確にすることに傾倒するかもしれませんが、議論から除外されるべきではありません。
  • プロジェクトと批評の目標を前もって述べてください。 。 プロジェクトの目標と、この特定の批評がカバーする内容をすべての人にすばやく思い出させます。 議論の主な目的を損なう他の考慮事項に範囲を忍び込ませるのではなく、批評を目前のタスクに集中させてください。
  • オーディエンスを確認します。 。 批評の人々が製品のターゲットオーディエンスではないことを強調するために、誰であるかをすべての人に思い出させてください。
  • 「答え」を考え出すことは避けてください。 参加者は、問題を解決したいという強い願望を感じ、批評の中で「答え」を考え出します。 ただし、実際の会議で最善の解決策が見つかることはめったにありません。 批評のポイントは、問題を調査し、設計者が取り上げて検討するための複数の潜在的な解決策について話し合うことです。
  • 持ち帰りに同意します。 。 批評ですべてが述べられた後、メモを取る人は、参加したすべての人の持ち帰りタスクを確認して、次の批評のために全員が同じページにいることを確認する必要があります。

残念ながら、多くの場合、UIデザインの批評は視覚に重点を置いており、インタラクティブで時間的ではないデザインの性質に十分に焦点を当てていません。 UIデザインの批評については、次の要素を追加します。

  • プレゼンテーションメディアを特定します。 。 オーディエンスを特定するとともに、製品の作成に使用されているプラ​​ットフォームとテクノロジーを確認します。 これはiPhoneアプリですか? ウェブサイト? AngularJSを使用していますか? C#? うまくいかない解決策を提案しないように、これらがすべて考慮されていることを確認してください。
  • プロセスフローの概要を説明します。 。 ロードマップを知る必要があります。 UIデザインの場合、それがユーザーエクスペリエンスのプロセスフローになります。 これは、ストーリーボード、ジャーニーマップ、またはプロセスを説明するその他の方法の形で提供される場合がありますが、UIを検討する前に、誰もがそれに精通している必要があります。
  • 製品のデモを行いますが、伝える以上のものを示します。 。 私はこれを十分に強調することはできません。優れたユーザーエクスペリエンスは、伝えるよりもはるかに多くのことを示しています。 エンドユーザーは、最小限の説明で製品がどのように機能するかを正確に知る必要があります。 デモでも、説明はできるだけ少なくする必要があります。 言われているように、優れたUIは冗談のようなものです。説明する必要がある場合、それはあまり良くありません。

適切な質問をする

たくさんの質問や声明が、デザイン批評における強力な協力に反しています。 ここに、チームに提案できる、戦闘的ではなく協調的な方法でデザインを探索するためのオープンな対話を見つけたいくつかの質問があります。

さらに質問する。
重要なのは、正しい質問をすることです。 (画像:ジョナサン・シムコー)(拡大版を見る)

「どのようにしてその解決策を思いついたのですか?」

批評や会話を始めるのに最適な場所は、デザイナーに、なぜではなく、どのように何かをしたのかを尋ねることです。 正当化する必要なしに、概念の起源の探求をどのように誘うかを尋ねながら、なぜすぐに彼らを防御に置くのかを尋ねます。

画像の説明。
答えを見つけるのは簡単です。 適切な質問をするのは難しいです。 (画像:Jason CranfordTeague)(拡大版を表示)

「なぜ」の質問は、それを1つの可能性として説明するのではなく、何かが「真実」であることを証明しようとする方向に私たちを駆り立てます。 アーロン・モートンによると:

「なぜ」は、何かが真実である理由の説明である物語を引き出します。 何も思い通りに機能しない理由を尋ねると、ストーリーを作成する可能性が高くなりますが、それは真実である場合とそうでない場合があります。 これは気分を悪くするのに危険な領域です。

「なぜ」を尋ねる代わりに、「どのように」質問をして、その存在を擁護するのではなく、創造のプロセスについての物語を引き出すことを検討してください。 そこから、デザイナーが以前にどのような可能性を検討したかを尋ね、それから彼らが検討しなかったかもしれない代替案を探求することができます。 ただし、提案を行う前に、設計者がすでに試したことに注意深く耳を傾けてください。 彼らは何かを見落としているかもしれませんが、そうだと思って会話に参加しないでください。

「そのようにするためのアイデアはどこで得ましたか?」

トーマス・エジソンは、「天才は1パーセントのインスピレーションと99パーセントの発汗です」と有名に言いました。 しかし、彼は主にニコラ・テスラから1パーセントを盗んだ。 それから再び、ピカソは「良い芸術家は借り、偉大な芸術家は盗む」と言いました(しかし彼はおそらくその線を盗んだでしょう)。

PixarAnimationの社長であるEdCatmullの著書Creativity、Incの中心的なアイデアは、優れたアイデアを持つよりも優れたチームを持つことが重要であるということです。

適切な人と適切な化学を取得することは、適切なアイデアを取得することよりも重要です。

私たちは、真空の中でアイデアを思いつくことはめったにありません。私たちがどこからインスピレーションを得たかを考えることは、私たち自身の革新を推進することができます。 さらに良いことに、チームの設定で私たちのインスピレーションをまとめることで、新しいアイデアを生み出すことができます。

注意の言葉:非難したり、見下したりしないように注意してください。つまり、彼らがアイデアを盗んだことを暗示しています。 ただし、イノベーションを押しつぶすことなく、デザイナーにアイデアの動機とその由来についての理解を深めてもらいたいと考えています。

「それはいつ起こる必要がありますか?」

コメディの場合と同様に、タイミングは時間的なデザインのすべてであり、イベントは適切なタイミングで適切な順序で発生する必要があります。 しかし、私たちが設計しているとき、私たちが座ってそれを説明しなければならないまで、その順序は必ずしも明白ではありません。

優れたUIは優れたストーリーのようなものであり、慎重にペースを調整する必要があります。 フォームを使い始めるのに十分な情報はどれくらいですか? ユーザーが理解できる適切なコンテキストでデータを表示していますか? これは結論を明らかにするのに適切な瞬間ですか?

非営利団体がニュースを通じて人々とつながるのを支援するスタートアップ、PublicGoodのCEOであるJasonKuneshは、次のように語っています。

お客様にとって、適切なタイミングでの素晴らしいやり取りは、製品やサービスの幸せなファンと接続する機会の喪失の違いです。 カジュアルなやり取りを永続的な関係に変えるには、人々が準備ができたときに届く一連の小さな前向きなやり取りとメッセージに依存します。

批評プロセスの一部は、これが行動を実行する、質問をする、またはデータを提示するのに適切な瞬間であるかどうかをあらゆる機会に尋ねることによって、インターフェースのタイミングのしわを取り除くことです。

「モーションを使用して視覚的な手がかりを追加できますか?」

この質問は、UIデザインを長年支配してきた静的な性質に慣れている多くのデザイナーを驚かせるでしょう。 ただし、動き、アニメーション、トランジションは、エクスペリエンスデザインの標準になりつつあります。 デザインでは、色と同じくらい動きを考慮することがすぐに重要になります。

アニメーションUI。
最新のUIデザインでは、動きは色と同じくらい重要です。 (画像:Jakub Antalik)(拡大版を表示)

UIアニメーションの専門家であるレイチェルネイバーズによると:

フラットなデザインの台頭とそれに伴うUXのつまずきにより、サイトのコンポーネントから視覚的な手がかりを取り除くことがいかに危険であるかを見てきました。 アニメーションは逆の効果に使用できます。

動きや変更は、不透明度や色の変更、ページ全体に伸びるサルの腕、ユーザーがタスクを完了すると昇る太陽などの単純なものである可能性があります。 UIデザインに瞬間的な動きを追加することについて質問すると、デザイナーは多くの場合、適切な方法で視点を変えるようになります。 設計者に、離散的な瞬間を超えて考え、空間だけでなく時間内に設計について話し合うように促します。

「どうすればもっと簡単にできますか?」

シンプルさは難しいです。 追加は削除するよりも常に簡単なようです。多くのUIは、私が「吹雪の中のスノーフレーク」シンドロームと呼んでいるものに悩まされています。確かに、すべてのスノーフレークはユニークですが、吹雪の中では気付かないでしょう。 UIデザインでは、リンク、ボタン、コントロール、画像でいっぱいのインターフェイスがよく見られます。 クライアントは、実際に必要なものを見つけることができないほど、聴衆が必要とする可能性のあるすべてのものを含める必要があると考えることがよくあります。

単純。
ノイズと混乱を減らします。 (画像:ベンチ)(拡大版を表示)

Do n't Make MeThinkの著者であるSteveKrugに簡単な質問をしました。

とても役に立つ質問だと思います。 今では誰もが夢中になっている教訓だと思っていたのですが、そうではなかったと思います。 私はいつも、ソリューションの一部ではないページや画面上のものは、ユーザーの本当の目標にとってはノイズであり、船外に投げ出される可能性があると言いたいです。

デザインのすべてのステップで、私たちは自分自身に問いかける必要があります。どうすれば、より少ない思考で同じ力を維持できるものを作成できるでしょうか。 批評では、これは何かをもっと簡単にする方法を尋ねることによって最もよく表現されます。 デザインの明確さを維持することは重要ですが、クリック数、テキスト数、フォームフィールド数を減らしてください。 仕事を成し遂げるために必要な最低限のことをしなさい、そうすればあなたのユーザーはあなたに感謝するでしょう。

"次は何が起こる?"

優れたデザイン批評は、優れたインタビューと多くの共通点があります。どちらも探索に関するものです。 最高のインタビュアーの1人であるスタッズターケルは次のように述べています。

[インタビュー]は異端審問ではありません。 それは探求であり、通常は過去への探求です。 ですから、最も穏やかな質問が最良の質問であり、最も穏やかな質問は「そして何が起こったのか」ということだと思います。

これをUIデザインに適用する場合、私たちは常にデザイナーに次に何が起こるかを考えるように依頼する必要があります。 この質問は、彼らが終わりであると考えたものを超えて考えるように彼らを誘います。 ユーザーは常に次の場所に行く必要があります。

UIを想定する上での最大の課題の1つは、ユーザーに求めている「ハッピーパス」だけでなく、考えられるすべてのパスを検討することです。 ボタンをクリックするとどうなりますか? エラーが発生した場合はどうなりますか? フォームを送信するとどうなりますか? 考えられるすべてのシナリオを検討するまで、次に何が起こるかを尋ねます。そうしないと、ユーザーがハングしたままになるリスクがあり、これは常に悪い経験になります。

質問して答えるだけではいけません

これらの質問をするとき、またはそのことについて他の質問をするときは、自分自身に答えられるように単純に質問しないでください。 誰かがあなたの答えを聞いたり、あなたの考えを理解したりするのではなく、単に自分の声を聞くためにあなたに質問をするとき、それは迷惑です。

空白のノートブック。
メモを取り、聞く準備をしてください。 (画像:ルイス・レレナ)(拡大版を見る)

あなたがそれらの人々の一人であるならば、すぐにそれを切り取ってください。 与えられた答えに広く心を開いて、すべての質問をしてください。 次に、聞きたい回答ではなく、それらの回答に基づいて回答を作成します。

優れたUI批評はどのように見えるか

批評は、参加者のスキル、目標、責任によって大きく異なります。 ただし、優れた批評は常に製品の特定の側面に焦点を当て、提示されたソリューションを徹底的に調査します。

UIの批評は、製品が現在どのように見えるかだけでなく、時間の経過とともにどのように機能するか、そしてこれがユーザーのニーズに最も適しているかどうかにも焦点を当てています。 参加者は、ユーザーのニーズを考慮するのではなく、なぜ何かが期待どおりに行われなかったのか疑問に思うことがよくあります。 UX forGoodのJasonUlaszekも同意し、彼自身の批評について次のように語っています。

私たちの議論で客観的であり続け、デザインの使用を任された個人(つまりユーザー)のメンタルモデルを検討することは、私たちが解決策をどのように議論するかにおいて重要です。

セルベースのアニメーションのように、最終的なフィルムの1秒に相当するものを作成するのに数週間から数か月かかる可能性があることを常に念頭に置いてください。ユーザーのレーダー。

CCTVカム。
チーム全体が同じ方向を向いている必要があります。 (画像:Matthew Wiebe)(拡大版を表示)

私がこれについて彼に尋ねたとき、スティーブ・クリュッグはこれを言っていました:

私たちは「優れた文学」(または少なくとも「製品パンフレット」)を考えていますが、ユーザーの現実は「時速60マイルの看板」にはるかに近いものです。 UI設計者にとって、開発に懸命に取り組んできたインターフェイスを人々がどれだけ速くズームしているのか、または過去に行っているのか、そして実際にそれをどれだけ取り入れているのかを理解するのは非常に困難です。

優れたUI批評は、すべての要素を検討するのに時間がかかりますが、これはユーザーがデザインを見る方法ではないことを認識しています。 批評の参加者が、色、タイポグラフィ、またはエクスペリエンスデザインについて直接話すための正式なトレーニングを受けていない場合でも、すべてのUIデザインでこれらの重要な要素を考慮することができます。

  • 一貫性。 設計とその実装は製品全体で一貫していますか? これには、色、タイポグラフィ、コントロール、画像、およびインターフェイスで複数回使用されるデザイン要素(静的またはインタラクティブ)が含まれます。
  • コンテキスト。 ユーザーが製品を使用しているときに、ユーザーのコンテキストを一貫して尊重しましたか? あなたはその文脈にいない可能性が高いので、常にこの質問をすることが重要ですが、設計またはテスト中にそれをシミュレートするだけです。
  • 。 ブランドとデザインには、明確で一貫性のある認識可能な声がありますか?
  • トランジション。 UIの重要な変更に、状態から状態への遷移を使用していますか? モダンなデザインは、ビジュアル以上のものです。 ユーザーの操作中にすべてのインターフェース要素がどのように移動および変化するかを検討してください。
  • シンプルさ。 仕事を成し遂げるためにできる限りシンプルなデザインですか?

敵対的な批判を避ける

批評は、チームのメンバーが、何らかの理由で、その作成に至る思考プロセスに耳を傾けることなく、その作品を批判する傾向があるという、厄介な方法で行われる可能性があります。 彼らはユーザーを考慮するのではなく、デザインに独自のバイアスをもたらし、彼らはしばしば彼らがどれほど賢いかを見せようとします。

批評が過度に攻撃的になるときはいつでもわかります。デザイナーは、彼らがどのように彼らに到達したかを説明し、代替案を議論するのではなく、彼らの決定について厄介になる傾向があります。 攻撃的な批判を避けるための鍵は、明確な原則を設定し、自由形式の建設的な質問をすることです。 アイデアは、デザインの戦いに勝つことではなく、共同でデザインを強化することであることを忘れないでください。

攻撃的な批判は役に立たず、通常は有害だと思います。 敵対的な批評は、デザイナーに防御的な姿勢を強要し、彼らにそれを拡大する力を与えるのではなく、彼らが行ったことに彼らを定着させます。 設計は、非常に大部分が直感的であり、必ずしも容易に認定できるとは限らず、定量化もはるかに困難です。

しかし、それは批評が純粋にデザイナーの意見に関するものであることを意味するものではありません。 それは、長年の研究を通じて得られたデザイナーの十分な情報に基づいた意見についてです。 AgenticのWebプロデューサーPhillipDjwaは、鍵は…

…私の経験から話してください、そして一般化しようとしないでください。 たとえば、「オープニングバナーがブランドを十分に伝えているのだろうか」と尋ねます。 代わりに、「うわー、人々は私たちがどんなブランド価値を持っているかを決して理解しないでしょう。」

最後の言葉:批評はユーザビリティテストではありません

ペルソナを使用するか、自分自身の偏見を利用することで、自分が聴衆のために話していると思い込ませるのは簡単です。 あなたがいくつのペルソナを作成したり、批評したりしても、あなたはあなたの聴衆ではありません。 スティーブ・クリュッグは私に言います:

これが、すべての設計者が、自分が作成したもの(ユーザビリティテスト)を使用しようとする人々を監視するために時間を費やす必要があると思う理由の1つです。

ツールチェスト。
デザイン批評は、UXツールチェストの1つのツールにすぎません。 (画像:Todd Quackenbush)(拡大版を表示)

レーザーレベルと水準器のように、ユーザビリティテストは内部の批評よりも正確で正確ですが、一般的に時間と費用がかかります。 定期的な設計批評は、プロジェクトを目標どおりに維持するために非常に貴重ですが、現場に出て実際のユーザーでテストすることに取って代わることはできません。 そうでなければ、あなたがしているのは自分自身と話すことだけです。