1.0UX TIMEShttps://uxdaystokyo.com/articles大本 あかねhttps://uxdaystokyo.com/articles/author/akaneohmoto/rich600338<blockquote class="wp-embedded-content" data-secret="aFk4IXwEFB"><a href="https://uxdaystokyo.com/articles/evidence-driven/">専門家の思い込み、ヒューリスティック評価がデザインを阻む。エビデンスに基づく改善方法とは？</a></blockquote><iframe sandbox="allow-scripts" security="restricted" src="https://uxdaystokyo.com/articles/evidence-driven/embed/#?secret=aFk4IXwEFB" width="600" height="338" title="“専門家の思い込み、ヒューリスティック評価がデザインを阻む。エビデンスに基づく改善方法とは？” — UX TIMES" data-secret="aFk4IXwEFB" frameborder="0" marginwidth="0" marginheight="0" scrolling="no" class="wp-embedded-content"></iframe><script> /*! This file is auto-generated */ !function(d,l){"use strict";l.querySelector&&d.addEventListener&&"undefined"!=typeof URL&&(d.wp=d.wp||{},d.wp.receiveEmbedMessage||(d.wp.receiveEmbedMessage=function(e){var t=e.data;if((t||t.secret||t.message||t.value)&&!/[^a-zA-Z0-9]/.test(t.secret)){for(var s,r,n,a=l.querySelectorAll('iframe[data-secret="'+t.secret+'"]'),o=l.querySelectorAll('blockquote[data-secret="'+t.secret+'"]'),c=new RegExp("^https?:$","i"),i=0;i<o.length;i++)o[i].style.display="none";for(i=0;i<a.length;i++)s=a[i],e.source===s.contentWindow&&(s.removeAttribute("style"),"height"===t.message?(1e3<(r=parseInt(t.value,10))?r=1e3:~~r<200&&(r=200),s.height=r):"link"===t.message&&(r=new URL(s.getAttribute("src")),n=new URL(t.value),c.test(n.protocol))&&n.host===r.host&&l.activeElement===s&&(d.top.location.href=t.value))}},d.addEventListener("message",d.wp.receiveEmbedMessage,!1),l.addEventListener("DOMContentLoaded",function(){for(var e,t,s=l.querySelectorAll("iframe.wp-embedded-content"),r=0;r<s.length;r++)(t=(e=s[r]).getAttribute("data-secret"))||(t=Math.random().toString(36).substring(2,12),e.src+="#?secret="+t,e.setAttribute("data-secret",t)),e.contentWindow.postMessage({message:"ready",secret:t},"*")},!1)))}(window,document); //# sourceURL=https://uxdaystokyo.com/articles/wp-includes/js/wp-embed.min.js </script> https://uxdaystokyo.com/articles/wp-content/uploads/2025/03/better2.png1280850「経験豊富な専門家こそ、ヒューリスティック評価の落とし穴にはまりやすい」——そう語るのはエリン氏。彼女自身、かつてベストプラクティスだと信じていた手法が、実際の現場では通用しなかったという苦い経験を持っています。 では、どうすればデザインを本当に改善できるのでしょうか？ その答えは「専門家の直感」ではなく、「テストによるエビデンスー”エビデンスドリブン”」にあります。ユーザーの実際の行動を分析し、事実に基づいた改善を重ねることこそが、優れたデザインへの鍵。 本記事では、エビデンスを活用したデザイン改善の重要性と、その実践方法について詳しく解説します。 『Design for Impact: Your Guide to Designing Effective Product Experiments（直訳：インパクトのあるデザイン: 効果的なプロダクト実験をデザインするためのガイド）』の著者 原文：https://medium.com/demagsign/when-good-design-isnt-actually-better-3352fa3e14ab 専門家の意見はいつも正しいとは限らない デザイナーとして働いていると、「自分は専門家だ」と自負し、自分のアイデアを強引に進めてしまうことがあります。私も学校でデザインを学び、長年の経験を積む中で、「これこそがベストプラクティスだ」「このデザインパターンが正解だ」と信じていました。しかし、実際には、それらが間違っていたと嫌になるほど知ることになりました。この厳しい現実の学びは、8年もの間、途切れなく続いたプロダクトのテストを通じて得られたものでした。 Booking.comでプリンシパルデザイナーとして働いていた時、私の手がけた改善はすべて AB テストで検証されていました。論理的に良く見える改善でも、実際には悪い結果を生むことがあるということを学びました。 私たちは日々提案しているデザインの価値を、具体的な数字で証明しなければなりません。単に「より良いものを作った」という主張だけでは通用しません。私のデザインの価値の証明には、確かなエビデンスが必要でした。それは、とても大きな試練だったのです。 エビデンスのヒエラルキー 多くのデザイナーは、エビデンスのピラミッドの下位2層だけで活動しています。 **エビデンスの階層（Hierarchy of Evidence）**では、最下層に「専門家の意見」があり、その上に「観察研究」が続きます。さらに上位には「ランダム化比較テスト（ABテスト）」、そして頂点には「システマティックレビュー」が位置します。上位に行くほどエビデンスの信頼性が高くなり、下位ほどバイアスの影響を受けやすいことがわかります。 図：科学の世界では、「エビデンスの階層（HIERARCHY of EVIDENCE）」が用いられます。しかし、この考え方はデザインにも応用すべき ABテストは、高品質なエビデンスのゴールドスタンダードとされています。この考え方は、デザインにも十分に応用できます。私はBooking.comでの経験を通じて、「専門家の意見」や「観察研究」が必ずしも正しいとは限らないことを学びました。 Booking.comの数年間で、私の「専門家の意見」や観察研究を試してきました。その中で気づいたのは、「良いデザイン」というのは、実はその場の文脈に大きく左右されるということです。 デザイン変更がどのくらい改善につながるかを、あらゆる状況で予測するのはほとんど不可能です。なぜなら、たとえそのアイデアがしっかりとした論理に基づいてたとしても、人々が物を使う方法は、驚くほど不合理なことが多いからです。つまり、予測が難しい人々のために価値ある解決策を作ろうとすると、それまでの考えや論理がすべて役に立たなくなることもあるのです。 サービスを提供し、新しい発見をし、価値を生み出すという謙虚な行為のことを「イン(IN)」といいます。INさせる行為はすべて、コンバージョン設計において、デザイン(Design)の実践と科学(Science)、そしてビジネス(Business)を組み合わせで実現できます。コンバージョン設計は、デザイン、科学、ビジネスが交わる地点に位置しています。この関係は、ベン図として表現されています。（図2参照） 図2: デザイン(Design)、科学(Science)、ビジネス(Business)を組み合わせることで、真の改善を実現するデザイン(Conversion)が可能になる 失敗からの学び ここでは、私が経験した特に恥ずかしい失敗を2つ紹介します。「なんてこった！」と思わず叫びたくなるような苦い経験から、デザインは他者に奉仕する謙虚な発見のプロセスであると学びました。 「論理的」なデザイン変更が招いた大失敗 ある日、私は「非劣性デザインバグ修正」として、 ボタンと ボタンの順序を入れ替える変更を行いました。（図参照） 脚注：「非劣性デザインバグ修正（non-regression bug fix）」とは、ソフトウェア開発において、修正したデザインバグや問題が再び発生しないようにすることを指します 図 3: 変更前では 「お気に入りに追加(Add to favorites)」 が、プライマリ アクション 「今すぐ購入(Buy now)」 の前（上）に表示される 変更後では、ボタンの順序を入れ替えて、「今すぐ購入(Buy now)」が最初になり、「お気に入りに追加(Add to favorites)」が2番目になるようにしました。 デザイナーとしての論理は、”メインのコールトゥアクション（CTA）はセカンダリーコールよりも先に提示されるべきだ。”というものでした。しかし、ABテストの結果を見て愕然としました。コンバージョン率が急激に低下していたのです。 最初は「ランダムな揺らぎ」だろうと軽く考えていました。しかし、事態は悪化するばかりでした。困り果てた私は同僚に相談しました。すると上司のスチュアートがやってきて、「それはデザインバグではありません」と言いました。もう一人のデザイナー、アンドリューがテストを重ねた結果、そのボタン配置が最も効果的であることが証明されていたのでした。 アンドリューが言いました「ああ、そうだ。そいくつかの異なる場所でテストしましたが、ボタンを動かすと、コンバージョンタンクがやってくるんです。」と彼は言いました。 ※コンバージョンタンク：コンバージョン率（ユーザーが望ましいアクションを取る割合）が大幅に低下することを比喩的に表現しています。 自分の「論理的」なヒューリスティック評価は、ユーザーの行動（エビデンス）によって完敗しました。この経験から、迅速に修正すべきと思えるデザインバグであっても、慎重に検証する必要があると学びました。ユーザーは、私たちの想像を超える使い方をするからです。 アンドリューのテストデータを確認するうちに、私が「非論理的」だと考えていたデザインの仮説を理解しました。バグだと思っていたものが、実は想像以上に便利なデザインだったのです。その効果が本物であり、何より、それが「デザインのバグではない」と確信してからは変更をやめました。 結局、学んできた定石は、別の検証で正しさが証明されただけ——そう理解したのです。 「優れたUX」と「デザインバグ」の概念は、それを経験するユーザーによって変わることに気づきました。また、一見「論理的」に見えることでも、実際のユーザーの使い方を考えると非論理的になり得るのです。 こうしたテスト結果を重ねるうちに、私はより謙虚になりました。デザインバグだと決めつけ、即座に修正すべきだと判断しないことの重要性を実感しています。なぜなら、ユーザーは私たちの想像を超える使い方をするからです。この経験を通じて、「非劣性のデザインバグ修正」が必ずしも正解とは限らないことを学びました。 エビデンスドリブンでのデザイン実装方法 鮮明な画像が必ずしも良いとは限らない場合 ある日のユーザビリティテスト中に、男性が画像を拡大しようとしているのを見かけました。彼は詳細を確認したかったのですが、拡大した結果、ぼやけた画像が表示され、がっかりした様子でページをスクロールし続けました。 その行動から「画像の解像度を上げればいいのでは？」と考えた私は、写真の解像度を引き上げ、より高品質な画像を提供するテストを行いました。しかし、コンバージョン率は下がったのです。 原因を調査した結果、鮮明な画像が「視認性を高める」一方で、ホテルの細かい欠点も目立つようになり、ユーザーの購入意欲が下がってしまっていたのです。私たちは、ただ解像度を上げるのではなく、どの情報を伝えるべきかを再考する必要がありました。 この経験から学んだのは、「データを根拠にした仮説検証の重要性」です。直感や論理だけで変更を加えるのではなく、実際のユーザー行動を観察し、効果を測定しながら最適な選択をすることが不可欠です。 検索結果ページの画像表示 検索結果ページは情報密度が高く、すべての情報に意味を持たせるべき画面です。しかし、写真の周囲にはCSSのpaddingで20pxの余白が設定されていました。さらに、写真のサイズが固定されていたため、右側のコンテンツが増えるにつれて、写真の下に不要な空白スペースが生じていました。 また、画像は150×150pxの小さいサイズを表示していたため、画像の解像度が低く、ズームインした時に画像がモザイク状に荒く表示されていました。加えて、写真のトリミングが不適切で、第一印象を左右する重要なページで、視覚的に重要な情報が多くの切り取られていました。 図4:被験者が拡大しようとした画像：画像がぼやけている ユーザーが求めている画像を最適に出す方法を検証 最適な画像を検証するために利用したサイズと寸法 最大幅の画像は高さはほとんど変化せず、ほぼ長方形の形状を保っていたため、トリミング可能な状態でした。コーディングを進める中で、最大幅の画像を調整し、いろいろなトリミング方法を試しました。 CSSプロパティ「background-size: cover」について理解しておこう 2010年代初頭にCSS3が広まり始めていました。特に注目されたのは「background-size: cover」というCSS3プロパティです。「background-size: cover」は、仕様に関する議論に10年を費やしていましたが、タブレットやスマートフォンでは安定して実装され表示されるようになりました。従来のCSSプロパティである「background-size: contain」に代わる新たなデザインの登場です。 図6:「background-size: contain」と「background-size: cover」の挙動の違い 「contain」は、画像全体が常に表示されるように調整されます。そのため、画像を表示させるコンテンツ領域（コンテナ）と画角が異なれば余白が生じます。一方、「cover」は、画像を比率を保ったまま（拉げることなく）拡大・縮小し、コンテンツ領域の背景全体を覆うようにします。つまり、画像の形状に関係なくコンテナのサイズに合わせて拡大されます。 実際のデザインでの採用 図 7: （左：オリジナル）コンテンツ領域が画像よりも高くなった場合、画像の下に空白が表示される　(右：改善版)コンテンツ領域にあわせて画像も高くなるように拡大される 当時利用されていたデザインは、写真のコンテナはカードのサイズに比例して大きくなるようにコーディングされていました。オリジナルの画像はそのままのサイズで、拡大されることはありませんでした。position:topの設定はされていたので、下に余白が残るデザインになっていました。改善後は、「background-size: cover」を使って全体に表示されるように調整しました。これは、無駄な余白の問題に対する完璧な解決策でした。 図 8: 左側がオリジナルの画像、右側が派生させた別バージョンの画像 最終的な画像サイズは300pxに 次に、新しいデザインを実装し、最大幅300pxの写真を入れました。一見すると、彼らは素晴らしく見えました。画像の幅が300pxだったのに、幅が170pxに縮小されたため、元の画像よりも解像度が高くなりました。しかし、ズームインすると、画面が粗くなってしまいました。 そこで、最大幅500pxの写真を入れたところ、素晴らしいクオリティが得られました。拡大しても詳細が鮮明に表示されました。そして、500pxが最終のテストバージョンとなりました。 私は個人的に、300px幅の画像よりも500px幅の画像の方が見栄えが良いと思っていました。しかし、自分の好みにこだわりすぎた結果、多くの人が画像の表示までに時間がかかり、快適に写真を閲覧できなくなってしまいました。実際、多くのユーザーは解像度の高い画像を求めていなかったのです。 そこで、500px幅の写真を300px幅の写真に置き換え、再びユーザー体験を改善する方向に舵を切りました。その結果、500pxの画像よりページの読み込み時間を短縮し、バウンス率（離脱率）を減らすことに成功しました。元々の170pxの画像より画像の品質は向上しています。 各デバイスのテストも怠らず、品質チェックをしよう！ テスト結果から、300px幅の画像で検証したCSSでの実装を、モバイルウェブやアプリにも同じように実装してほしいと担当者に言いました。 「やあ、みんな！これ、いいと思うんだけど…検索結果ページでも試してみませんか？」と提案しました。モバイルチームのデザイナーやエンジニアたちは興奮しながらこのアイデアを受け入れ、すぐに実行に移しました。しかし、iOSとAndroidのアプリでは同様の結果を得ましたが、モバイルウェブではなぜかうまくいきませんでした。 「いったいどういうことだ？どうしてそんなことが起こり得るんだ？」と私は考え、その担当者に実装した人のところに行き、何をテストしたのかを確認させてもらうよう頼みました。 彼らは私に実装内容を見せてくれて、少し異なるCSSプロパティを使用していました。その結果、画像は大きくならないし、更に、コンテナのサイズに合わせて拡大されていなかったのです。 「だから失敗したのか…」と、うろたえながら考えました。そこで、そのモバイルウェブの人に私の実装方法に合わせてコードを修正してもらえないか頼んだところ、「忙しすぎて無理だ」と言われてしまいました。私はせっかちで好奇心旺盛な性格なので、彼らの許可を得て修正しました。実装すると同じように表示されました。この経験から、結果、エビデンスに従って原因を探る必要があること、どのデバイスでも徹底した品質チェック(QA)が必要があることが明確になりました。 テスト結果のエビデンスから学んだこと 私は、テストを通じて2つのことを学びました。デザイナーは「品質」について、一般のユーザーとは異なる視点を持っているということです。本当に「優れているデザイン」は、デザイナーが理想とする解決策との間にある中間点に存在します。 そして、何かを改善しようとして失敗する方法は、成功する方法よりもはるかに多く存在するということです。テストの設計が、成功か失敗かを決定づけるということです。 失敗談から効果的なテストまでを1冊の書籍に 記事に興味を湧いたら、著書『Design for Impact: Your Guide to Designing Effective Product Experiments』を気に入っていただけるかもしれません。Rosenfeld Mediaで出版され、オンラインで購入可能です。現場で利用できるエビデンスから紐解く実装方法を紹介しています。 「Design for Impact」著者 Erin WeigelUX DAYS TOKYO 2025に来日！ 2010年の時点で、エリン氏はエビデンスに基づいたCV向上の改善策を実施していました。ABテストを闇雲に行うのではなく、ユーザーの定性データや行動、技術面まで考慮し、最適なデザインを導き出す方法を模索し成果を上げてきています。それから15年経った現在は更にノウハウが蓄積されているでしょう。現場での良くある間違いなども含めて彼女から多くのことを学ぶことができるでしょう。 彼女の言う通り、成功に至るまでには多くの失敗が伴います。しかし、デザイン改善で成功へと導く方法を理解できれば、あなたのプロジェクトは次のステージへ進むでしょう。 https://youtu.be/lgSKd46jpcc