いいUXはいいデザイナーから！ - shinshi-onigooriのブログ

今回はプロダクトのUXを向上させるために必要なことについて先週開催されたMercari Design Talkで発見があったため記事にしたいと思います。

1, 導入

2, いいプロダクト作れるチームとは

3, デザイナーって何するべきなの？

4,おまけ

1,導入

私はよくプロダクトを発想することがあり、その際に様々なプロダクトのデザインを見て回ることがあります。その中で、このUIデザインいいな、このデザインフロー、ページフローのUXいいなと思うことがあるのですが、具体的に何がいいのかは考察できても、それがどのような工程で作られているのか分からず、自分で再現する方法を探していました。

以前Navigation UIの作り方という題の記事を描きました、あれは自分一人で作るという前提でした。しかし、仕事というのはそうもいきません。ましてやより大規模なサービスのを作るとなればなおさら一人では限界が来てしまいます。一人でできることには時間という制約があり、その制約の中で各々が自分の得意なことをチームでこなす必要があります。これはWeb業界以外にも言えることです。

ではどのようなチームがより良いUXのプロダクトを作れるようになるでしょうか。

今回はこのことについて12/7に開かれたMercari Design Talk #3 の内容を踏まえながら考察していきたいと思います。

2, いいプロダクト作れるチームとは

ズバリ言いましょう。優秀なデザイナーがいるチームです。

とはいったもの、嫌々そんなデザイナーだけじゃうまくいかんでしょうと、言いたい気持ちはわかります。しかし、どんなに実装の早いエンジニアとマネジメント力のあるマネージャーとビジョンのあるプロデューサーがいても、目にみえるデザインがなければプロダクト作ることすらできません。つまりデザイナーは絶対条件ではなく、最低条件なのです。

多くの企業はデザイナーをあまり重要視しておらず、外部に発注したりや事業部の方がデザインを作ったりしています。こうなってくると前者は自分の作っているプロダクトに完全な熱量を割いてくれないですし、後者はデザインのプロではないのでなかなかうまく要件定義が進まなかったりなどはザラにあります。

大切なのは、自分のチームに同じ目線のデザイナーをジョインさせることなのです。

ではデザイナーがいることでプロダクト開発にどのようなワークフローが生まれるのかみてみましょう。

こうしてみると、いくつかのワークフローにおいてデザイナー重要な役割を果たしているのがわかると思います。デザイナーがPMともに過去と現在のUXR(UX Research)を行い(Discovery)、そこからプロダクトの戦略(Strategy)や軸(Concept)を練っていく。それが終わってようやくWire framingに入り、PMやDeveloperからFeedbackを得て、最終デザインを完成させ(Finalization)、ようやく実装が始まる(Dev Support)のです。つまり、デザイナーとはただ見た目を起こすだけではなく、そのプロダクトについて抽象的な部分と具体的な部分のどちらについても語られる人間にならなければならないのです。それこそが良いデザイナーなのだと私は考えます。

3, デザイナーって何するべきなの？

ではプロダクトを通してデザイナーどのようなフロー踏んでいるのかはわかりましたが、よりその具体的なスコープの中身をMercariさんの資料を参考に見ていきます。見てみたいと思います。

何やらDesign review なるものが二つあるみたいですね。

オープンなFeedBackの場と、ClosedなFeedBackの場でクオリティを上げるようです。

前者では、デザインの視野を広げられそうですし、デザイナー通しのコミュニケーションにもなって楽しそうです。後者ではゴールまでぶれないように人数を絞ってFinalizeしていくのは非常に効率的で良いと思いました。詰まるところ、デザイナーも一人ではなくチームとなって視野を広げていく必要があるということですね。Design Reviewを行うことで、プロダクトのブラッシュアップはもちろん、UXの向上やデザイナー同士の関わりを増やし、チームもプロダクトも丁寧に豊かに育てることができそうです。エンジニアはよく開発チームを組みますが、デザインとなると一人だけなんてこともザラにあります。しかしそうではない、デザインチームあって然りですね。

UX DesignerとUX Researcherの違いは一枚目の画像を参照

UX designer まとめ

4,おまけ

最後にMercariさんが考える、議論の仕方について共有して終わりにしたいと思います。

デザインとは見た目を作る作業なので、どうしてもその議論は見た目の良し悪しの話に傾いていきがちです。そんな時に気を付ける、というよりかは意識することがあります。それが、課題/仮説で始まって、課題/仮説の解決が達成できているかの確認で終わるという流れを徹底することだそうです。

こうすることでどの議題においてもそのデザインの良し悪しではなく、根本的な部分の議論ができるわけです。エンジニアリングにおいても、コーディングの良し悪しではなく、そもそもそのコードはユーザの課題/仮説を解決するに足るコードなのか、という視点でみるということだと考えます。デザイナーはこのような視点で議論をする力も求められるというわけです。

終わりに

いかがでしたでしょうか。自分は駆け出しフルスタックエンジニア(?)として活動する中でいつもデザインの質というもの考えていました。今回は将来的にどのようにデザインにアプローチをかけるべきなのかのヒントを掴むことができたと考えています。もしデザイナーとして働いてみたいと考えている方のヒントになるものを残せていたら大変嬉しいです。ここまで読んでいただきありがとうございました。