読者です 読者をやめる 読者になる 読者になる

naMemo

うぇっぶやアプリやデザインに興味深々なキモオタのメモ

PJで協働してUIデザインを作るための3つのポイント

f:id:oooNAKi:20161222022634j:plain

この投稿は、UIデザインアドベントカレンダー21日目の記事です。

https://www.adventar.org/calendars/1834

私は某企業のデザイナーとしてWebサービスやアプリのUIをデザインしています。 デザイナーは、サービスを成長させていくためにプロジェクト内の様々な関係者と協働し、ユーザとの接点であるインターフェースを作るのが仕事です。

関係者とは、たとえば、以下の4つが挙げられます。

  • ディレクター
  • 自分以外のデザイナー
  • エンジニア
  • ユーザ(今回はあまりフォーカスしません)

様々な関係者と働く上での課題

私が働いているサービスは、デザイナーから、「こんな機能どうか」「ここのUIもっと改善したい!」と提案できる環境です。 ただ、これらの関係者に対し説得力のあるUIをつくっていくのは、難しいということをこの1年で痛感しました。 ディレクターからは「それ必要なの?それで数値伸びるの?」と言われたり、エンジニアからも「それ仕様的に無理」と言われたりと、上手く進行しないことがしばしばあります。 デザイナーの立場として、自分がやりたいだけだと受け入れてもらうことは難しいです。

様々な職種と協働して働くには、各々が大事にしていることを理解し、きちんとコミュニケーションをして、説得力のあるUIをつくる必要があります。 その為に、私がこの一年で学んだ点を整理していきたいと思います。

①ビジネス価値とユーザニーズの両面で目的を設定する

UI設計にのめり込んでいると、自分中心的なデザインになってしまい、結局コレって何のためにやるんだっけ?というのを忘れてしまいがちです。

機能仕様をまとめる際に、UIの目的を、以下の観点で明文化して、何のために作るか立ち返ることができるようにします。

  • ビジネス的な価値

    • この機能は、どんな指標に効果があるか

    • 例:PV向上、UU向上、継続率向上 などなど

  • ユーザニーズ

    • この機能で、ユーザのやりたいことは何か。解決したいことはなにか。

これをまとめておくことで、のちのち関係者にレビューしてもらうときの論拠にすることもできます。

ちなみに、機能を検討していく際に、サービス内でKPIツリーを設定しておくと、サービスのビジネスゴールに対し、どの指標を伸ばしていくべきかわかりやすくなります。

KPIツリーとは、

例えばアプリのKGIを売上とした場合、売上を構成する要素を分解して施策が実行可能になるレベルまで落とし込まれた指標(KPI)の一覧です。

KPI tree ※以下のサイトから画像転載しています。詳細はこちらにまとまっています。

https://growthhackjournal.com/kpi-tree-for-app/

KPIツリーをつくることで、施策が影響を及ぼす指標も明確になるので、リリース後の効果検証もしやすくなります。 デザイナーもKPIツリーを意識することで「これ意味があるの?」議論を減らすことができます。

ただ、KPIも重要ですが、あくまでデザイナーは、ユーザとの接点を守る砦であり、ユーザに寄り添って面をつくることを忘れないようにします。KPI厨になって、ユーザが使いづらいサイトをつくってしまっては、意味がありません。

②自分のつくるUIの理由を徹底的に追求する

UIデザインも一人でやるものではなく、チームの他のデザイナーと一緒に議論しながらUI設計をしていくことが多いと思います。私の場合は、デザインチームでUIのデザインレビューを行っています。

ただ、デザイナーによって、UIに対する考えは違います。ときには、UIに対して意見が食い違ったり議論になったりする場合もあります。そのような場合に、他のデザイナー達に、自分がなぜこのUIを設計したのか意図を説明できる力が必要になってきます。

意図を説明できるようになるために、自分の作ったUI一つ一つに対し、自問自答しながらデザインしていきます。 例えば、達成すべきユーザニーズや、サービスのブランディングと照らし合わせて、

  • なぜこの色にしたか?

  • なぜこの情報の優先度にしたか?

  • なぜこのレイアウトにしたか?

というように、常に自問自答しながらUIを作ることで、自分の中で設計の理由を明確にすることができます。

自分のデザインに芯を通すことができるので、他のデザイナーにレビューをもらう際に、「これはもっとXXに改善すべき」といった意見に対し、単純にナアナアと意見を受け入れるのではなく、自分の中でのUIの根拠をもとに議論することができます。

蛇足ですが、UIの議論をしていて、「こうしたらどう?」という意見をもらった際に、SketchMirrorを使ってリアルタイム制作をし、その場で実機確認してもらうと、良し悪しの判断が即座に出来てウケが良かったです。議論も長引きません。

③UI/UXをデザイナーだけで決定しない

エンジニアに実装をしてもらう時にある課題として、UI設計終わった段階で、技術的な工数の事情や仕様モレで指摘をもらい、作り直し・・・になることが挙げられます。

UXやUIに関する仕事は、ディレクターやデザイナーが担いがちですが、施策の企画を検討するフェーズからエンジニアに入ってもらうことで、早い段階で仕様のすり合わせを行うことができます。

この検討段階で気をつけているのが、UIをつくりこまないことです。

エンジニアにとっては、Sketchなどでつくった、デザイナーにとってのワイヤーフレームも「作り込まれていて議論が終わったUI」に見えてしまうこともあるそうです(人によるとは思いますが)。 そのため、ホワイトボードや紙の上に、あえてラフなプロトタイプ描いて議論をすることで、職種関わらず関係者が検討しやすいようにします。

ペーパープロト程度であれば、エンジニアの人も一緒に絵を描きながら議論できます。 エンジニアリング観点から、機能をもっとよくできる提案をいただける場合もあります。

まとめ

デザイナーが様々な関係者と協働し、説得力のあるUIを提案するために、私が気をつけている3つのポイントをご紹介しました。

ここ最近感じたことは、職種を超えて、密にコミュニケーションし、多くのフィードバックをもらって議論したものは、目的に沿ったUIがうまれていくということです。 デザイナーは、単純な制作スキルだけでなく、各関係者との仲立ちができるコミュニケーション能力、自分の成果物を論理的に伝える力が必要になってきているなと思います。