UIデザイナーとして意識している仕事の進め方
取引先で、ジュニアデザイナー向けに資料を作る中、わたしが意識している仕事の進め方を改めて言語化しておこうと考えた。
本から学んだこともあれば、上司や同僚との壁打ち、仕事の中での経験や挫折を元に価値観を作り上げてきた。もちろん、あらゆる場面で正しいはずはなく、あくまでも個人の見解である。
発散と収束を繰り返す
プロダクト開発におけるデザイナーの強みは、素早く目に見える形に落とし込み、周囲を巻き込みながら共通認識を築き上げられるところである。
仕事で何らかの問題解決を行う際、多くの場合、直線的な議論しかなされない。例えば、とある問題があった時「それはこうすれば良いのでは」と誰かが言う。その意見に対して、賛成や反対を表明する。
直線的な議論のデメリットは、問題解決が短絡的に行われ、必ずしもベストな選択肢を検討できない点にある。また、人間の短期メモリーには限界があるため、複数の選択肢を並列に検討できず視野が狭まってしまう。
プロダクト開発でもよく見かける光景であるが、とある問題があった際に「ここにこういうボタンを置けばいい」と誰かが言い、そのまま採用される。本当にそれがベストだろうか？
考えられる選択肢をブレストし、それぞれのplus/consを検討し、その文脈において適切な答えを導き出さなければならない。そのためには、発散と収束。そして、目に見える形にしてみるのが重要だ。
解決すべき課題を見極める
デザイナーやエンジニアと共に仕事をすることに慣れていない人は、ソリューションをそのまま依頼してしまう。
例えば、ここにこういう機能を付けてください。この要素を赤くしてください。といった具合だ。なぜその機能を付けるのだろうか。そもそも、必要なのだろうか。他の選択は考えられないだろうか。
文字を赤くする、という内容ひとつ取っても、安易にその通りにすべきではない。たいていの場合、その要素を目立たせたいという意図があったりするのだが、文字を赤くする以外にもアプローチは考えられる。
フォントを変えたり、動きを付けたり、余白のバランスを調整したり、周りの要素のプライオリティを下げることで、相対的にその要素を目立たせることもできる。
解決すべき課題が何なのか、常に意識して、ステークホルダーと認識を合わせよう。ソリューションをそのまま依頼してくる人は、何も悪気があってやっているわけではない。中にはマイクロマネジメント気質の人もいるが、たいてい「課題を挙げるなら解決策もセットで提案しないと」と、よかれと思ってそうしている場合も多い。
リスペクトを払いつつ、まず解決したい課題を共有してくれた方が、力になれる可能性が高まるとコミュニケーションしてみよう。
事実と解釈、仮説を使い分ける
活発な現場では、様々な課題や改善策、ジャストアイデアが飛び交う。こういう体験の方が良いのではないか。この機能はああすべきではないか。この見せ方ではユーザーに伝わりづらいのではないか。
UIデザインの文脈では、明らかなアンチパターンを踏んでいるようであれば、ヒューリスティック評価ですぐに検知し、変えてしまって良いだろう。
そうではない場合、それはそもそも課題なのか。出てきた話が何を元にしているのか。事実と解釈、仮説を意識して見分けたり、使い分けることが重要だ。
複数のユーザーがこのような意見を口にした
社内のAさんが個人的にそう感じている
偉い人の鶴の一声
ユーザーの声であれば、例えば3人くらいの人が同じ箇所でつまづくようであれば、かなりの高確率で課題が潜んでいる。
ただし、社内で意見が割れるようであれば、いくら話し合っても水掛け論の域を出ない場合は多い。答えは会議室にはないのだ。
データやユーザーの行動を観察し、その事実を元に解釈し、仮説を導き出そう。社内で誰々が言っていたから、偉い人がこう言ったから、は論外である。
作っているものの限界を知る
ここでの「作っているもの」とは、具体的にはFigmaのようなデザインツールで作ったビジュアルである。
デザインツールで作ったビジュアルは、精密な仕様書や設計書にはなりえない。紙ものや画像中心のLPであれば、実装されたものと一対一に近い形で、何とか紐付けて管理できるかもしれない。しかし、無数の状態を持つアプリケーションでは、実質的に不可能である。
よって、仕様書や設計書というよりも、青写真と捉える方が健全ではないだろうか。こういう風にしたい、こういう体験を実現したい、という共通認識を築き上げる手段のひとつとして見るのである。
よって極論としては、何かを作るときに、必ずしもデザインツールでビジュアルを作らなくても良い。とはいえ、ホワイトボードやエクセルで作ったポンチ絵や、会話だけの脳内補完では、関係者の認識はだいたいずれる。目に見える形にして初めて気付くことは多い。
また、青写真として捉えることで、よくある「デザインしたものと実装されたものが違う」という課題も、違った視点から見られる。前提として、デザインツールで作ったビジュアルは、アプリケーションの持つ無数の状態の中から、特定の時間軸だけを切り取ったスケッチに過ぎないからだ。
だからこそ、デザインと実装されたものがずれるのは当たり前である。（もちろん、それ以前の問題であるケースもあるが）
よって、ただ「違うから修正してください」と言う話ではなく、青写真を元にして実装されたものをベースに、一緒にディティールを詰めていく。そんなイメージで向き合うと良いだろう。
あなたの幸運を全力で祈ります!