「変更しやすいUI」を意識したデザイン

いくつかのサービスのデザインに関わって、最近思うようになったことを書いてみる。

要約すると サービスデザイナーはプロダクトの最終的なゴールを高めることを目的としてデザインすべき。あと最初から本気だすとUIの変更要求に対して簡単に舵がとれなくなる。 ということが言いたい。

※新規サービス開発の初期デザインのお話です

最初から本気は出さない

最初から本気を出すと、最適なUIでないにも関わらずみんなが気に入ってしまうような間違った素敵デザインが生まれてしまったり、リニューアルしたくても作りなおすのに工数がかかりすぎるデザインが生まれる。一から百まで全部本気だすなというわけではなく、最適なUIがまだ手探りな状態においては凝ったデザインはPDCAサイクルを鈍化させてしまう、ということ。

素敵デザインをするのは、出来る限り最適なUIに目測をつけてしっかり検証を終えてからとりかかっても遅くはないと思います。

デザインよりもプロダクトの価値を優先する

こういう間違った素敵デザインでもABテストやら小手先の改善はできるのだけど、もっと大きい構造的な部分のUIはほとんど一発勝負になってしまっているのが大体のケースだと思います。 デザイナーというものはとても気高い生き物で、つねに自分が最高だと思うものしかプロダクトとして出したくない。だけどそこをぐっとこらえて、PDCAをバリバリ回す前提でデザインを作っていかないと、サービスの価値仮説を十分に検証できないままインターフェイスの完全体を迎えてしまうことになる。

最初から最適なUIが生み出せるのであれば全く問題ないのだけど、そうはいかないのが駆け出しデザイナーの性。アプリの最初のデザインは大体がこれとかこれとかが理由でほとんど理想的ではない形でリリースされてしまうことを理解しておくべき。自分の全力を常にアウトプットしてみんなにキャーキャー言われたい気持ちは十分わかるのだけど、アプリやサービスのおいては、デザインよりもプロダクトの価値が優先されることを常に意識するべきだと思いました。

想定されるバッドケース

例えば間違った素敵デザインを初期からやってハマってしまうと、UIの抜本的な変更を提案されにくくなる。というか工数的に無理だからディレクターが無意識に避けてしまう。このUIを作り変えるのは工数的に無理だし、というわけで空いたスペースに機能を追加して問題に対応してみる。

機能追加で問題を解決しようとする施策は、積み上げてきたものにさらに積み上げるような施策で、それをするにはまず土台が整っていないとほとんど失敗してしまうケースが多いと思います。

その土台をまず改善するべきなのに、それができない。

ここで言いたい問題は機能追加は悪いもの、ということではなく、凝ったデザインによって機能追加以外の選択肢が無意識的に失われることにあると思います。なのでこういった障壁を少しでも少なくして、「変更しやすいUI」を意識したデザインがサービス開発初期には重要になってくるのではないかなと思いました。

余談ですが、この記事を書くにあたって、gunosyのiOSアプリの開発はすごく参考にさせて頂きました。

リニューアルしてからなんやかんや言われていたデザインでしたが、実は今ではほぼまるきり違う構造のものになっていて、いい意味であっさりしたデザインだからこそ成せるPDCAサイクルの早さだなぁと思いました。「UIなんてまだまだ完成していないからどんどん試行錯誤していくぞ！」みたいなのが伝わってきて、あと半年か一年後か、みんながテノヒラクルーするのがとても楽しみ。