日別アーカイブ: 2018年4月2日

UI無限ループにハマらないための、ハンバーグ・ブロッコリー理論

先日こんなツイートをしたのですが、UIのためのUIの話が多い気がしています。


UIってやろうと思えばどこまでも出来るので、どのタイミングで妥協して出すか(実装に係る工数も含め)という着地点を探すのが重要だと思っています。

よくあるのが、UIを洗練させるためにリリース時期を伸ばすことです。確かにUIは大切なのですが、延々UIを洗練し続けてUI無限ループに陥ってしまうことがあるのです。UI無限ループに陥らないためのハンバーグ・ブロッコリー理論を提唱します。

そのプロダクトにおいて、UIはハンバーグか?ブロッコリーか?

まず、UIをどこまで掘り下げるかを考えるにあたり、作ろとしているプロダクトにとって、UIがハンバーグ(主菜)に当たるのか、ブロッコリー(副菜)にあたるのかを考えます。

例えばツイートの例にあったマンガアプリの場合のハンバーグ(主菜)は、もちろん漫画コンテンツそのものです。コンテンツそのものに比べればUIはブロッコリー(副菜)です。
ハンターハンターの最新話が読める使いにくいマンガアプリと、名も知らない漫画しかない使いやすいマンガアプリがあったとしたら、使われるのは断然前者です。

もちろん、両方良くするに越したことはないのですが、リソースは限られています。
戦略というのはリソースの最適化ですから、リソースが限られている場合はハンバーグ(主菜)に多く割くべきです。もし1,000万あったとして、500万をUIデザインに割いたら、500万をコンテンツの獲得に割くことになります。この場合はUIデザインに割く費用を最小限にとどめて、コンテンツの獲得にほぼ投下するべきでしょう。

ということで、コンテンツが主役の場合はUIに割くよりはコンテンツの獲得にリソースを割いた方が効率が良いわけです。

UIそのものが、ハンバーグになる場合

しかし、UIそのものがハンバーグである場合は、UIそのものが価値になりますから妥協をしてはいけないということになります。例を挙げるとSNSやメッセージングアプリなどがそうです。これらにとっての価値は、人々が発信するメッセージなどですが、そのメッセージの発信と受取という行為が、かなりの頻度で行われるため、UIそのものがハンバーグになります。

同様に、ソーシャルゲームなどのゲームアプリなども、UIそのものがゲームというコンテンツの一部に内包されるため、ハンバーグであるということになります。

また、ニュースアプリなどもUIそのものに注力する必要があります。先ほどの漫画アプリと比較すると、ハンバーグはニュース記事そのものではないかと思われますが、ニュースアプリは細切れのニュースをキュレーションして配信しているプラットフォームそのものに価値があるので、ニュース記事をいかにまとめるか、それをどう見せるかというUIが重要だからです。

また、UIがハンバーグになる場合は、利用頻度が著しく高いサービスであるという点があります。マンガアプリは、マンガを選んでしまえば、マンガを読むという導線を辿り、一日に何度もアクセスするものでもありません。しかしSNSやメッセージアプリ、ニュースアプリなどは日に何回もアクセスすることになります。
利用頻度が高いということは、UIに少しでも気持ち悪い点があると、離脱のポイントになるからです。

ということで、UI無限ループに陥らないためのハンバーグ・ブロッコリー理論でした。