迷われるUIデザイン。誰の前提か。
ボタンの文言を直した。余白を整えた。導線も並べ替えた。なのに、レビューではまた同じ場所が論点になる。ユーザーテストでも、また迷われる。
この感覚、ありませんか。正直、私は何度もあります。
結論から言うと、今回書きたいのはこの話です。直しているのに良くならないとき、直すべきはUIではないことが多い。レビューの前に、前提の問いを並べたほうがいい。チェックリストというより、自分への問いです。答えが出なくてもいい。先に聞くかどうかが大事だと思っています。
直しているものが、ズレている
「UIが悪い」と言われると、UIを直したくなります。当たり前です。指摘された場所を直す。それが仕事のように見える。
でも、直しても良くならないときは、だいたいパターンがあります。直しているのは画面です。残っているのは前提のズレです。誰が何を決めきれなかったのか。ユーザーに何を判断させてしまっているのか。組織が先に決めていないのに、画面だけ親切にしようとしているのか。
ここが残ったまま余白を直しても、次のレビューでも同じ違和感が出ます。見た目は少し良くなる。でも、迷いの根は動かない。
レビューの前に聞きたいこと
私が画面を開く前に、自分に聞くのはだいたいこのあたりです。全部に答えられる必要はありません。答えられないこと自体が、情報です。
いま直そうとしているのは、誰の前提か
「ここがわかりにくい」と言われたとき、わかりにくいのはUIでしょうか。それとも、前提が共有されていないでしょうか。
たとえば、「この画面で何を達成すれば成功か」がチームで揃っていない。なのに、ボタンのラベルだけ議論している。このとき直しているのはUIです。でも、ズレているのは前提です。
私は最近、指摘を聞いた瞬間にこう聞くようにしています。「それは、画面の話ですか。それとも、何を優先するかの話ですか。」この一文だけで、議論の場所が変わることがあります。
ユーザーがやりたいことを、組織が先に決めているか
親切なUIに見えるものが、実は未決の責任を画面に押しつけていないか。選択肢が多い。説明文が長い。注意書きが増える。確認モーダルが何枚もある。見た目の問題というより、決めていないものをユーザーに投げている感じです。
だから、聞くのはこれです。「この画面で、ユーザーに決めてもらっていることは何か。」「それは、本来プロダクト側が先に決めるべきことではないか。」答えが「はい、決めていない」なら、ボタンを直す前に戻ったほうがいいです。
「迷わせない」がゴールになっていないか
迷わせないUIは、だいたい正しい方向です。ただ、それがゴールになると、判断ごと消えるUIになることがあります。全部が誘導される。全部が最適ルートになる。寄り道がない。選ぶ余地がない。迷いは減ります。でも、ユーザーが自分で納得して進んだ感じも減ることがあります。
私はここで一度、立ち止まります。「いま消そうとしている迷いは、本当に消すべき迷いなのか。」「残したほうがいい判断は、どこか。」迷わせないことと、考えさせないことは、近いようで違います。
説明文が増えているなら、前提を疑う
ヘルプテキスト。注釈。ツールチップ。「※」の注意書き。増えること自体が悪いわけではありません。ただ、説明が増えるほど、前提のズレを疑ったほうがいい、と私は思っています。
説明で補っているのは、何でしょうか。言葉が足りないのか。概念が共有されていないのか。それとも、この画面に載せるべきじゃない情報を載せているのか。説明を足す前に聞くのは、「この一文がないと伝わらないなら、そもそも設計の前提がずれていないか。」です。
「なんか変だな」を、スキル不足に帰していないか
レビューで「なんか変だな」が出たとき、自分のデザイン力の問題に落とし込みたくなります。ここ、危ないです。「なんか変だな」は、だいたい正しい。でも、正しさの中身は見た目だけとは限りません。
情報の優先順位が、業務と合っていない。この画面で答えるべき問いに、答えられない。成功の定義が、チームで違う。スキル不足に帰すと、直す場所を間違えます。余白や色をいじって終わる。違和感の本体は残る。
だから、先に聞くのはこれです。「この違和感は、見た目の話か。問いが読めない話か。」
答えが出なくてもいい
正直、すぐに答えが出ることは少ないです。「誰の前提か」と聞いても、会議の途中ではっきりしないことが多い。組織の未決が、そのまま画面に出ていることもある。
それでも、聞く意味はあると思っています。答えが出ない問いを、UIの修正タスクに変換しなくなるからです。「文言を直す」前に、「決める人がいない」と名前がつく。「余白を整える」前に、「優先順位が未決」と見える。直す場所が、少し手前に戻ります。
レビューは、完成度を測る場だけではありません。前提のズレを見つける場でもあります。画面を開く前に問いを並べておくと、指摘の受け方も変わります。全部を自分のUI責任にしない。全部を他人のせいにもしない。どこが未決かを一緒に見られる。
まとめ
直しているのに良くならないとき、私はUIを開く前にこう聞いています。
いま直そうとしているのは、誰の前提か
ユーザーに決めてもらっていることは、組織が先に決めるべきではないか
「迷わせない」が、判断ごと消すゴールになっていないか
説明文が増えているなら、前提がずれていないか
「なんか変だな」を、スキル不足に帰していないか
全部に答えられなくていいです。答えられない問いがあること自体が、次に直すべき場所のヒントになります。
UIを直す前に、問いを直す。その順番を守れると、少なくとも「直したのに同じ話が戻ってくる」回数は減る気がしています。
読んでくださってありがとうございました。
この記事が「なるほど」と思えたら、「スキ」や「フォロー」もらえるとうれしいです。チームにもシェアしてもらえると、次の記事のモチベーションになります。
プロモーション
iCAREでは、一緒に成長しながら新しいチャレンジに挑戦できる仲間を募集しています。
まずは、カジュアル面談のお申し込み からお気軽にお話ししてみませんか？
皆さまのご応募を、心よりお待ちしています。
XでもUIデザインやプロダクト開発に関する投稿をしています。ご興味がありましたら、ぜひフォローしていただけると嬉しいです。
いいなと思ったら応援しよう！
よろしければ応援お願いします！いただいたチップはUIデザインプロダクト開発に関するnote作成に使わせていただきます！