『UIデザインみんなで考え、カイゼンする。』の1〜4章も読んでみた

2019年3月25日 14:11

　引き続き1−4章も読んでみた！！！ふぁww

読んでみたざっくりとした感想

　ユーザーの実態に基づいた体験デザインをどのようにチームメンバーと連携しながらプロダクトに落としていくかというようなことが記してあった。また、UIというタイトルでありながらもインターフェースだけでなく体験ベースでUIに落とすプロセスについて述べられているのでとても好きだなあと思った。実際自分でもUXDとUIDの境目ってあるの？一貫性が大事だから突き抜けた方がいいのでは？いやでも分業した方がいい？フェーズ分けないとだよね？とか試行錯誤していた部分だったのでとても勉強になった。今回は自分の体験も織り交ぜて共感しながら書いてみようと思う。

1章について

　常に「誰のためのデザインなのか？」を問うような内容だった。UI切り口の本なのに、体験ベースで思考されており頭に入ってきやすかった。

　「ユーザーがサービスに対して何を求めているのか」が重要であると記してあった。そこについては常に思考するべきだとは思っていたが、やっていくうちに「そもそもユーザーはこのサービスを求めているのか？」というようなことを考えることが増えた。ユーザーの体験価値とプロダクトの価値の結びつきを意識しながら常にユーザーの思考に基づいたアップデートをかけていく必要があるのではと思っている。ただ、管理コストがかかるので、今フォーカスするべき箇所を見極め判断する必要があるのだけど...

　定量・定性の両方からアプローチすることが多いのでは？と記してあった。まさに定性で闇雲に調査する時間などない現実では定量のログから体験として課題が大きそうな数値を抽出し、課題の解像度を上げるために定性調査をするということをやっていたのでまさに！と思った。

　定性からのアプローチをするときに、「ユーザーを理解する」ことが大切と言うようなことが記してあった。とても大切な視点だし、絶対に忘れちゃいけないと思う。現実、施策ありきでユーザーへの体験を提案しがちなことが多い気がするが、それで本当にユーザーが使ってくれるのか？というのは疑問である。私が「これほしいでしょ、イケてるでしょ、使えば？」って言われても「いや、別に必要ないし・・」って思ったら使わないなあみたいな感じ。それって、サービス、プロダクトによる体験価値が検証しきれてないとも言い換えられると思う。

　じゃあユーザーの気持ちを知ろうじゃないのととことん調査するとする。そこで多分ありがちなのが、気づいたらユーザーに感情移入しすぎててペルソナが自分に憑依しちゃうということ。真剣になればなるほど、自分の感情とユーザーの感情が混ざってしまうのだ。これは人間なのでどうしても共感すると自分の言葉で表現したくなりがちだと思う。そこをぐっとこらえて「ユーザーだったら」という視点で常にとらえられる能力がとても大切だと思う。「ユーザーはこう思うはず！」と思ったその気持ちを一旦俯瞰して「なんで？」と自分に問うクセをつけていきたいと思っている。自分のためのデザインになっていないように気をつけたい。ユーザーのコンテキストはユーザーのコンテキストなのである。

　課題が抽出できたところで、ユーザーにとっての体験価値を提供できる理想の状態との乖離がどれだけあるのかを知る必要があり、現在ある乖離と新たに生まれた乖離をいかにしてなくしていくかが肝になってくるのかなと読み取った。

　この改善のサイクルを早く的確に回せると、ユーザーの体験価値を常に提供し続けられているということになるのでは？と思っている。その状態を保つためにどうすれば良さそうかと言うようなことも記してあった。

　「そのプロジェクトごとに適したプロセスがある」「チームの誰もがデザインに向き合う」

　そり過ぎてソリになった。せっかくチーム内にそれぞれ得意な領域の違うメンバーが揃っているのだから、いかにしてユーザーの体験価値を提供できるかを早期にいろんな視点で見て対応していくことが私の理想だなと思っている。私はデザイナーという肩書きの領域が得意なので担当しているが、フロントエンド、サーバーサイドの設計のことまで私が書いて意味があるのかということである。誰がどの領域で最適な設計ができるかなんて明白だよなあなんて。

　各領域のメンバーと一緒にユーザーの体験価値を追求していくために必要なことは「同じ目線でユーザーを見ること」と言うようなことが記してあった。そのために、ユーザーの実態を調査するフェーズから、事実をチーム全体に共有する必要があり、チーム内のメンバーはユーザーの実態に関心を持つ必要がある。過去に事実として私自身がエンジニアの方やステークホルダー、ビジネスサイドの方などから下記のようなコメントを貰ったことがある。

「前提がわからないとどんな仕組みが良さそうか案をだしてなんて言われても本当にこれでいいのか不安になるし判断できないよ。」

「いや、ユーザーはこう思ってないはず、多分こう思うはずだよ。だからこの仕様のほうがいいよ。」

　私はこのようなコメントをもらったとき、理由ってなんなんだろう？なんでみんなわかってくれないんだろう？と思ってしまっていた。そこで、「もし私が逆の立場だったらどう思うだろう」と思った。「こーいう結果だったからこれについてみんなで考えましょう」って言われても、結果だけ見せられてもプロセスがわからないと詳細に設計できないかもなと気づいた。そこからなるべくチーム全体に調査の尺度や結果、考察した内容からアプローチ方法まで事細かに共有するようにドキュメント化したり、模造紙にシナリオを張り出して可視化していつでも誰でも見れるようにした。まあ、ここまでしてようやくスムーズに進むようになったんだが、いろいろ言いたい人は内容も見ずに言いたい放題い言いがちで、そういう人はもう言いたいだけの人だなって割り切ることにした。もうこれ以上頑張る必要はないと思う()

　要するに、自分が目立ちたいとか成果を出したいとかそういう個人的な目的じゃなくてチームメンバー全員で「ユーザーの本質的な体験価値」を追求できてこそよりよいものになると考えている。

2章について

　2章には実際にモノに落としていくときのプロセスについて手法やツールを用いながら記してあった。詳しくは読んでみると良さそう(それはそう)

　「ユーザーがどのように感じるか？不快に感じないか？」などを考慮する必要があると言うようなことが記してあった。それはそうで、「なんか嫌だな、めんどくさいな」と思ったらそのプロダクトを触りたくないよなと私なら思うなと思ったからだ。ここについては認知心理学の学問がとても参考になる。人間の思考のプロセスに基づいた認知の仕方を考慮できるのでベースとしてとても役に立つ。

　とはいえ、理想ばかり掲げていても現実としてはステークホルダーやクライアントの要望や制約を考慮する必要があるケースが多いとのこと。たしかに、私もそうだなあと思いながら読んでいた。理想と現実のバランスのとり方については私も常に考えあぐねていることである。例えるなら下記の様に捉えれられると最近思っている。

理想＝エンドユーザー

現実＝市場

　使われるものをつくらないと使われないが、そもそも市場にマッチしていないと売れるものも売れないという現実...ビジネスサイドとの連携がうまくなりたいと思う今日このごろなのであった...orz

　さあ、効率よくモノをつくるぞ！と意気込みコンポーネントでサクサクつくっていこうとなったときに陥りがちだなと思うのが、いつの間にかコンポーネントベースの設計になってしまい、本質的なユーザー体験が置き去りになってしまうことだ。これはこわい。なので、常にユーザーシナリオベースで本当にこの画面がシナリオに沿っているか？を確認しながら設計していくと本当に必要なコンポーネント、画面を選定していきやすいと思った。

　いざステークホルダーに仕様の確認をしに行くというときに、「はじめからデザインツールでビジュアルを作り込んでしまうと、そもそも何を表示するか決まっていないのに、カラーや余白のバランスを指摘されて...」というようなことが記してあった。実際にこれは私も体験したことがある。一度ステークホルダーの「俺的レビュー」スイッチが入ってしまうと本来見てほしい視点でのレビューモードに切り替えてもらうまでに時間がかかり、辛みが深かった。このMTGが終わったら実装に向けてエンジニアの方と相談したいし〜というせめぎ合いである。実際、ここが一番つらみざわだった記憶があったなあ...(遠い目)なので、「今このMTGでは何に注目してどういう視点でどういう体験価値を満たしているかを確認する場にしたい」ということを明示し、常に見えるところに書いておくということをした。実際にモノがあると人間なのでついビジュアルに引っ張られがちになるので、「おっと？ボタンの色？角の丸さ？ん？ズレてきたぞ？」と思ったらすぐに今するべきことは何かと振り替えれる環境にしておくことが重要だった。時間は限られているので...

　(この辺は極めて自信がない)スタイルガイド＝コンポーネントの世界線について。実際にデザイナーとエンジニアが共創する際に、スタイルガイドとコンポーネントの関わりが密になってくると思う。そこで、いかに効率よくスタイルガイドをコンポーネントに紐づけていくかが大事なのかもなと最近思い始めた。スタイルガイドベースでコンポーネントに落として実装したはいいけど、検証の結果スタイルガイドの微調整が行われた〜なんてことがあったら(あるのかな？わかんないw)コンポーネントが置いてけぼりになっちゃったり。コンポーネントの方であまりよいデザインじゃなかった場合にコンポーネント側だけデザイン変えちゃってスタイルガイドが置いてけぼりになっちゃったり。みたいな感じでデザイナーとエンジニアそれぞれで管理しているものが分断しているからこそ情報の乖離が生まれてきてしまうなあと思ったりした。そこでようやくツールに目を向け始めた。今の現場はエンジニアの方が多くデザイナーが私一人しかいなかったので()StoryBookに挑戦しようかなと思ってちょっとずつやってみてる(コード書くの苦手すぎるのでフロントエンドエンジニアさんに協力してもらってやっとだけど(T_T))。せっかくならチームメンバーみんなで管理できる方がいいよね。デザイナーがたくさんいたらFigmaも試してみたかったなあ。ステークホルダーも巻き込むとしたらFigmaがいいかもなあ。開発効率、ステークホルダーとの合意形成、どちらに重きを置いたらいいのか未だに試行錯誤中です...

　UIデザイナーの役割って見る人によってイメージが全然違うんだなあってことがわかったし、自分自身で思っている感覚とも異なるなあと思った。

　個人的には、ユーザーの体験価値を掘り出してデザインできればそれでいいと思っているのであまり肩書きとか役割にこだわりはないし線引もしたくないなと思っている。みんなで得意なことややれることやればいいじゃんってスタンス。合理的に最小の労力で最大の成果だしていきたいよね...(ここで怠け体質が見え隠れする)

3章について

　「データ収集は「量と質」の両側面を行き来する」と記してあった。実際、定量・定性分析のバランスは「何を知りたいか」「今はどのフェーズななのか」によって変化させる必要があるということなんだと思う。そもそもどんなところにフォーカスしていきたいかを決めるにはまずはざっくり定量で見ると主観に偏らない決めができたり、じゃあ実際その数字から読み取れる仮説は合っているのか？実態はどうなのか？という調査を定性でするなどして、定量と定性の特性を活かしながら分析をしていくと良さそうだなと思った。「定量分析と定性分析を組み合わせる」これが最強かな？(･ω･)bｸﾞｯ

　「サービス提供側とユーザーとの価値についての認識ギャップに気づくことが大切」と記してあった。事実に基づいたユーザーが本来得たいであろう体験価値であるかどうかは妄想では語れないということを言っているのかなあと思ったりした。現実、ビジネスサイドに「ユーザーはこうでしたよ、うちの強みをもうちょっと見直したほうがいいかもですよ」って伝えても「うちの強みはこれだから！」と押し通そうとしたりね。あるよね...。まあ確かに市場での推しポイントが異端であることは大事だと思うんだが、ユーザーにとって本当にそれが必要なのか？とは別だったりする。その制約の中でいかにユーザーが「使える〜」と思えるものにするかを求められがちだなあと思ったり。こんな現実だからこそ、私はユーザーの実態をなるべく正しくみんなに伝えるために、事実の解像度を上げることに徹さなければならない。「定量的・定性的、両方の側面から確認する必要」まさにそのとおりだなと思った。

　かと言って現実とばかり向き合っていては飛躍的なユーザーの体験価値の向上をすることは難しいと思う。「アイデアを継続して実現すること」これに価値があると記してあった。事実をしっかりと見た上でアイデアが出てくるわけだが、事実とアイデアは常に結びつき続けるべきだと私は思う。アイデアだけ独り歩きしてしまってはユーザーの実態と乖離してしまう可能性が高いと考えるからだ。

　「プロトタイピングがチームを作る」このワードがとても魅力的だなと思った。どういう意味かなって読み進めてみたんだが、要するに「それぞれの得意な部分を活かし合って合理的にモノにしていくといい」ということなのかなと思った。さっきの章にもあったけど、苦手なことよりも得意なことをやったほうが自分のためにもチームのためにもユーザーのためにも良いことだよなあって思う。そのためにも、チームメンバー全員が最初から議論に加わることが大事〜みたいなことが記してあった。そりな〜となった。様々な役割の人たちで議論するということは言語も統一していかないとそもそも認識が噛み合わずに話ができないよねみたいなことも書いてあった。それはそうだよな〜となった。なるべくみんなでわかる言語で話したいよね。それを意識し始めてからは「UXD」とかじゃなくて「ユーザーの体験」とか言ったりしてみてる。単語でハードルを感じて議論に参加しにくいとかもったいなさすぎる。伝われば何でもいいよね。

　議論の終着点はやはり目標だと思うんだがよくそれを「KPI」や「KGI」を設定するところが多いのでは？みたいなことが記してあった。これによって「目標＝ゴール」を明確にし、最後までチームが一丸となって同じ方角を向いて進むことができるとのこと。尊すぎる...。「KPI」や「KGI」について最近思うことが、ビジネスサイドが体験のプロセスと別物として考えて体験に沿った目標になっていない、みたいなことが起こってしまった〜みたいなやつだ。すごく悔しかったなあ。「KGI」という体験価値(ゴール)に向かって「KPI」を決めようと取り組んだんだが、なかなかどうして「そこまで細かくする必要ない」とか言われてしまったのだよ...かなしみキャリブレーション...(T_T)次こそは体験ベースでゴール設定できるよう、インプションデッキから意識していきたいなと思った。(って結構自分ごと話しすぎ...？（；＾ω＾）汗)

　「ユーザーの体験価値の実現のために何をするべきかをチーム全員が理解しているのか？」が問われるみたいなことが記してあったけど、まさにそれなとなった。自分ひとりじゃプロジェクトをやりきれないし、ユーザーに体験価値を提案できないので、ユーザーにとって最適な共通認識をチーム全員で持てたらどんなに幸せだろうと涙が出てきた...。ワイはエデンに行けるのか...＼病まないで〜／

4章について

　ここには定性調査(ユーザーリサーチ)について手法から丁寧に記してあった。ユーザーが見ている世界をつかむ「ユーザーインタビュー」エモい、エモすぎる...。インタビュー以外にもいろんな手法があるけど、最終的には実際にユーザーと対話して仮説が合っているかを確かめたほうが確実性が出てくるかなと思ったり。

　その仮説について、「なぜその仮説を立てたのか？なぜそれを知りたいのか？」が明確になっていると、データを持ち帰ったときに分析・考察がしやすいなあと思ったことがある。「なぜ」の部分をチームメンバーで共有できているとプロダクトに反映するときもスムーズでいいかもしれない。

　実際にインタビューするときに、「詳細を深掘りする」必要があると記してあった。このユーザー(インフォーマント)ならではの掘り出しやすいポイントをラポール形成時にアタリをつけておいて、質問項目に繋げて何気なく聞いてみるってのが私の戦法としてある(笑)無理やり質問を順番通りにしないと〜ってすると違和感のある対話になってしまうなってのがコミュ障なりの体験談である...(涙)よりリアルなコメントを引き出すことが重要なので、質問は前後してでも自然に相手の心地よい順序で対話できるとこちらも楽しくなってくるなって思った。うん。コミュ障なりに。

　持って帰ったデータをもとに改善案を考えていくわけだが、その際にはシナリオベースで当てはめていくとアップデートをかけていきやすい。実際に模造紙などで張り出している場合ならそのまま付箋を貼っちゃえばいい。ここがこういう理由だからこうしたほうがいいかも？ってのがみんなに見えている状態を保ちたい。

　「懇親会で本音を探る」これやってみたいと思った。かしこまったインタビューとか観察ではなく、同じ視点で対話できることの尊さと言ったら無い。できれば友達感覚で素のコメントをもらいたいな〜...。(なおコミュ障)難易度高そう(どの課題にフォーカスする？課題に応じた尺度は？など)だけど、ここではユーザーから自然と出てくる言葉そのものと向き合うことに価値があるのかなあなんて思ったりした。自然体だからこそ、一番気になっていることを話してくれるかなって。自然体といえば「ファンやコミュニティを形成する」という手法も記載してあった。最近だとTwitterとかDiscordとかがあるかなと思う。ファンと同じフィールドで会話してくれる運営ってなんかいいよな〜ってヲタクなりに思うので、運営側からも同じようにやってみないとって思ってる。ユーザーに一緒につくってもらうという気持ちでアップデートをかけていくことの尊さを思い知る今日このごろである。

結論、ユーザーは尊い！！！！！！

〜完〜

5〜6章を読んでみた記事