一休.com Developers Blog

一休のエンジニア、デザイナー、ディレクターが情報を発信していきます

一休のUI/UXデザイナーとして私がやっている4つのこと

この記事は一休.comアドベントカレンダー2018の11日目です。

qiita.com


はじめに

デザイナーと聞いて、皆さんはどのような人を想像しますか?
「見た目を美しくかっこよく作れる人」、「ビジュアルデザインの専門家」というイメージを持たれている方も多いのではないでしょうか?
デザイナーのアウトプットだけを見ればその通りですが、アウトプットに至るまでのデザインの考え方 や取り組み方、役割がここ数年で変わってきています。
以前は、情報を整理して色や形を使いこなすビジュアルデザインがデザイナーの中心的な業務だと考えられていました。
しかし、Webデザインの標準化が進み、類似サービスの乱立も増え、ユーザーから好まれるサービスかどうかが重視されるようになりました。
より効果的なデザインを実現するために、事業戦略やサービスの現状、マーケットニーズに目を向け、デザインに活かそうとする動きが活発になりました。

とはいえ、理屈は理解できても具体的に何をすれば良いのかがわかりにくいと感じている方も多いはず。そこで今回は、一例として私が一休のデザイナーとして取り組んでいることをご紹介したいと思います。

Index
1) トーンマナ―などのルールは最低限にして都度考える
2) 自分たちが目指すデザインの方針を明文化する
3) デザイナーが自由に発散し、少し先の将来について考える場を設ける
4) デザインに取り掛かる前に考える

トーンマナ―などのルールは最低限にして都度考える

一休のレストラン事業のトーンマナーで定義しているのは、複数のページで登場する基本的なUIパーツとタイポグラフィの基準のみです。
あまり詳細まで定義するとルールに縛られて考える機会が失われる可能性がありますし、ドキュメントの整備に手間をかけるのも得策ではありません。
敢えてルールを決めすぎず、状況に応じてデザイナーが自分の頭で考え、最良と思うものを画面に反映させて効果を見てみる。
工夫できる余地を残すことでサービス改良の提案がしやすくなり、変化の促進につながると考えました。
ただし、都度デザインすることがユーザーのためにもサービスのためにもならない要素についてはVueコンポーネントに定義して、デザイン、コーディングの効率化とサービスの使いやすさの両方の実現を目指すことにしました。

目指したいデザインの方針を明文化して共有する

デザインをしていてしばしば頭を悩ませるのは正解が複数あることです。
デザインの善し悪しは判断軸によって変わりますし、人によって異なる感想を持ちます。
チームでデザインを考える場合、個々に全く異なるコンセプトで考えてしまい、サービス全体での一貫性が損なわれることもあります。
かといって、トーンマナ―を充実させれば良いかと言うと前述の通り、そうではないと思っています。

そこで、サービスデザインコンセプトというものを明文化することにしました。
ルールではなくコンセプト、つまり方向性です。
具体的にあれをする、これをするを書くわけではなく、実現したい景色を3つ~5つの項目に落とし込み、自分たちが作っていくプロダクトの目標として据えました。
そして、この目標にマッチしていない箇所について、「こうしたらどうだろう?」「こういう方法もあるかも」「どうやって進めようか?」といったことを、次項で紹介する「UI/UXデザイン語り場」で話し合っています。

一休レストラン事業のサービスデザインコンセプト(抜粋)

  • 楽しい、予定がなくても見たくなるサービスであること
  • 最短で目的を達成できるサービスであること
  • 直感的に操作ができ、考える必要がないサービス
  • システマチックになりすぎず人間味があるサービス

デザイナーが自由に発散し、少し先の将来について考える場を設ける

目前のタスク消化であっという間に数か月が過ぎてしまった、という経験はありませんか?
また、自分の考えが正しいかわからず提案しても良いものかと躊躇してしまう、ということはありませんか?
これらの課題をチームで解消して、小さなことでも良いので実行を積み重ねていきたい、という想いから「UI/UXデザイン語り場」というミーティングを実施することにしました。
週に一時間、今抱えているタスクから離れてこれからやっていきたいこと、やってみたいことについて考え、自由に話すための時間です。

提案した内容をなんでもやれば良いわけではありませんが、答えのないことを行動前にあれこれ考えすぎても意味がありません。
そして最も避けるべきは「何もしないこと」です。
何もしなければ業績は低下していきます。
よほど的外れなことでない限り、まずやってみる、やってみた結果を踏まえて次の打ち手を考える。
この繰り返しがサービス改善には不可欠です。

デザインに取り掛かる前に考える

「こういう機能を付けたいから画面デザインをください」と言われた時に、いきなりデザインツールに向かってしまうのは適切ではありません。
その前に、まずは企画者の話に耳を傾け、実現したいこと、手段、現時点での仮説、リスクなどを書き出し、前提情報を整理します。
そして、それらの前提を元にターゲットの深掘りをしていきます。
データからわかることと、データからはわからない不確かなことに分けてまとめると良いでしょう。
ヒアリングやデータ解析、他社分析の作業は必ずしもデザイナーが担当する必要はありません。
自分でできるなら自分でやれば良いですし、できない場合には得意な人の協力を得ても良いと思います。
重要なことは事実と可能性をしっかりと把握することです。

一通りまとめ終えたら、いくつかのターゲットグループのユーザー像を想像できるようにしてから、いざデザインに取り組みます。
このプロセスを踏んだ時と踏んでいない時とで、デザインを提案する際の説得力も自信も、提案内容も変わるはずです。
多少手間でもこのプロセスを踏んで予測し、実施後にどうなったのかをノウハウとして蓄積すると、アイデアの引き出しが増やせると思います。

おわりに

いかがだったでしょうか?
「そりゃそうでしょ!」と思う内容が多かったと思いますが、13年間ECサイトのデザインに携わってきて気付いたのは、難しく考える必要はないということでした。
シンプルに考える、当たり前のことを当たり前にちゃんとやってみた結果、見えてくることも多々あります。
少しでも参考になれば幸いです。

最後までお読みいただき、ありがとうございました。
次回は@atsumim の 「プラン詳細ページのモーダル化を Fastly で段階的リリースした話」です。お楽しみに!