見出し画像

ジュニアUIデザイナーがリードデザイナーになる話

こんばんは!
今日は、関わらせてもらっているスタートアップの企業で
プロダクトをがっつりリニューアルした話をしたい

私はUIデザイナーとしては3か月目のバリバリジュニアUIデザイナーである
(マインドは1年やってるマインド)

今回、プロダクトのUIを私が先導していわゆるリードデザイナーとして
進めていくことになりました(最高の機会)

そう、全画面フルリニューアルです!
デザインシステムも変更、プロダクトロゴも変更、
ただ、仕様は変更なしの、見た目UIを変更ということです
(仕様変更はtier2)

#最初にしたこと
既存のプロダクトの仕様理解
リニューアルなので、仕様の部分は現状でもある程度意匠に現れているいえど、UIを作る中で、プロダクトの仕様理解はかかせません
どこをどう触ったらどういうことができるようになるのか?を
くまなく実環境を操作して体感しました
(それでも作っていく途中であれ?全然わかってなかった、、ってなることは度々ありました※申し訳ない)

#次にしたこと
既存のプロダクトの改善案(仮説)
次にしたことは仮説を立てていく作業です
ユーザーインタビューの前に、この部分のここがこうなんじゃないか?という仮説をfigma上にコメントする形でバンバン書いていきました
その中で、なぜそう思ったのか、だとしたらどうしたらいいと思うか?
というのは、PdMの方にかなり詰めてもらいました
全然言語化できない自分を振り返って、根拠をきちんと言語化できるデザイナーになる!と強く思いました
そのときにその方に、「もうなんでもなぜなぜ攻撃してください!」と頼みました
そしたら本当になぜなぜと問うてくれたので脳に汗を書きながらなんとか答えていく日々でした
そして現在のUIに対してもっとこうしたら?というアイデアを出すためには、知識の土台がいります
それは根拠を説明するためにも必要だし、そもそも違和感を覚えるためにも必要です

#次にしたこと
ユーザーインタビュー
ユーザーインタビューといっても、現在のフェーズのユーザーは限られているので、その方とMTGでインタビューしました
ここで意識しないといけないことが結構あって、かなりそのMTGが緊張したのを覚えています
・ユーザーの”こういう機能がほしい”というのをそのまま真に受けないこと
・なぜ?を掘り下げること
・課題に対しての解決策(手段)は何種類もあるので、「こういうのがいい」から「こうする」ではなく、「なぜこういうのいいのか?」を考えてアプローチを考える
これって結構難易度高くて、どうしても、「こうしたい」を聞くと
「じゃあそうしよう」になってしまうんですよね
なのでnotionに事実とそれに対する課題を抽象化して一覧にする、ということをしました

1.画面ごとにこういうユースケース、こういう使い方をすると思ってるという認識合わせる
2.そのうえでユーザーが思う使いづらい点、分かりづらい点、操作が大変などのネガティブポイントを聞いていく
3.2以外で自分が思う課題や問題を提示して反応伺ってみる
↑この意識でインタビューをしたんですが、どうしても
「○○がいい」って言われると「ってことは○○の方がいいってことですか?」と答えてしまいました💦
自分が思う課題や問題を提示して反応伺ってみるということができてなかったですね


#次にしたこと
課題の抽象化と意匠に起こしてみる
ユーザーインタビューであがった事実を課題として抽象化します
まあ私はこれもかなり苦戦して、どうしても具体的な○○するという言葉になってしまうんですね
具体と抽象の行き来って難しい(ここは鍛えるぞ)
そのうえで、実際に出てきた案をUIに起こしていきます
ここで完璧に仕上げるのではなく、「こういうやり方もあるよね」という
風に色んなSaaSを参考にしながら描いていきます
ああでもないこうでもないと言いながら進めていきます
パーツごとに見たらいける!と思っても画面全体ひいてはプロダクト全体でみるとそうでもなかったり・・・
それでも表現して入れてみないことには始まりません
インプットとアウトプットの繰り返しの期間です


#次にしたこと
徹底的な壁打ち
そうなればIA設計からパーツごとのUIまでPdMと徹底的な
壁打ち期間が始まります
思ったように進まないというのが今回の学びです
俯瞰的にみるとあらかったり、そこまで考えられてないよね、というのが多かったりFB貰って「うわもう全然じゃん!」ってなるのを数回繰り返しました
その過程で「自分全然じゃん」って思って落ち込むことも少しありましたが、よくよく考えればこのような立場でやらせてもらっていることがありがたすぎる…と思って続けます
そしてこれも難しかったなっていうのが、ある仮説Aと仮説Bがあったときに、どちらの懸念の方がユーザビリティにより影響するか?を考えること、実際にユーザーに届けてみないと分からないところもあるけれど、「Aを実現したらBという懸念要素がでてくる」ってどのサービスや事業にもあると思ってて、そこの判断、意思決定が難しかったです
あとは、グラフとか、表とかそういう部分に入っているテキストをなるべく、実際はいりそうな言葉にする、とか、そういう細かい部分も。
(なんでそこまで必要かっていうと、実際のテキスト量によっては意匠も変えたほうがいいかも?っていうことまで考えられるため)

今回のことで私が学んだことはたくさんあるのですが、苦戦したこととしていかが挙げられます

①画面全体プロダクト全体で俯瞰して考える
→やっぱりどうしても細部を考えているとそこだけに囚われたりします
そのパーツ単体、UI単体だけ見ると最善だろうものも、画面遷移や全体の動きを考えるとそうでもなかったりします
②やっぱりインプットがまだまだ足りない
テキストフォームならだいたいこうだよね、とかいう一般論としてのUIをまだ説明しきれないな自分って感じです
③あらゆる可変パターンまで想定しきれていない
どうしても今すぐ見える挙動のUIは想定して描いているのに、「これってこの場合どうなるの?」ってなったときに「たしかに」となることが多かったです hoverとかだとわかりやすい規則的な可変だけど、UIって全体通すとそうじゃないものばかり見えてくる 
④そのうえで、プロダクトは1人でなんか作ってない
これが一番大事かな、と。今後個人開発もしていくけれど、組織のプロダクトを作る以上、デザイナー1人で仕上げるわけじゃない。
特に今回に関してはお世話になっているPdMの方の並々ならぬ伴走をいただき、リニューアル画面を仕上げることができました
エンジニアさんが描くものを形にしてくれて、それを使ってくれるユーザーさんがいる。そしてこれで終わりじゃない、常に改善していくし、そのたびに「ああでもないこうでもない」と壊しながら作りながらみんなとやっていく。初めてがっつり全画面作り切ってとても楽しかったです!


最後に
今回このUI改善に、リードデザイナーとしてお任せしてくれた会社さんと、
常に伴走しながらも時に熱く時に厳しく、時に優しく寄り添ってくれたPdMの方に多大なる感謝を込めて、このプロダクトのより一層の飛躍をこれからも近いところで関わっていきたい







この記事が気に入ったらサポートをしてみませんか?