足すより削る方が難しい。これはデザインをした者であれば誰もが直面したことのあるチャレンジだろう。現在のサービスデザインでは、足し算よりも引き算の方が何倍も重要である。
事実、現在ヒットしている商品やサービスのその多くが、機能の多さよりも必要最小限の機能でユーザーの目的を果たすことで人気を集めている。
リリース当初、Snapchatは、しばらくすると消えてしまう画像をユーザー同士で送り合うだけのアプリだった。Uberでは、タクシーの事前予約はできなかったし、Amazonは本だけを売っていた。Googleは検索エンジンに過ぎなかったし、マクドナルドはフォークとナイフを提供していなかった。
たくさんのことがそれなりにできるよりも、ある一つのことを最高レベルの洗練された体験で提供することにフォーカスしているプロダクトに人々は熱狂する。それなのに、我々プロダクトチームの多くは、成功する製品には多くの機能が必要だと考えがち。
でも現実は逆である。
機能を削ったことでヒットしたプロダクト例 (主に初期バージョン):
- iPhone – 物理ボタンを極力排除
- MacBook – DVDドライブ排除
- Google – 検索ボックスのみ
- Twitter – 140文字まで
- Instagram – 画像のみ
- Tiktok – 60秒までの制限
- Snapchat – 消える
- Medium – 記事を読むことだけにフォーカス
- Amazon Go – レジ会計が無い
- GoPro – カメラから液晶を排除
- Kindle – 本を読むだけのデバイス
- Uber – 降車時の支払いが無い
- Clubhouse – 音だけ、録音機能なし
1つの機能に絞り込むMVPの価値
例えば、スタートアップの初期においては、必要最小限の機能だけを実装し、そのサービスの価値をユーザーに問うためにMVPと呼ばれる初期バージョンが作り出される。
多くの初期バージョンがそうであるように、機能は限定されているが、その目的が分かりやすく、使いやすい。
機能ベースMVP (誤) と目的ベースのMVP (正)
ユーザー検証の後にサービスがリリースされ、そのシンプルさが喜ばれ、ユーザーも順調に増え始める。
しかし、ここで一つの問題が持ち上がる。
ユーザーを増やす ≠ 機能を増やす
より多くのユーザーを集め、彼らをより喜ばせる？為には、新しいユースケースを想定した機能を追加する必要があるという議論がチーム内で広がり始める。
その主な理由として考えられるのは:
- プロダクトのレビューやアンケートなどを通じて、一部のユーザーから機能追加のリクエストが来る
- プロダクトチームは、そのような新機能を追加することで、それまで獲得できなかったタイプのユーザーや、他のカテゴリーに進出することが可能だと考える。それにより、競合他社から市場シェアを奪うことによる、ビジネスを拡大を狙う
- プロダクト提供側は「機能が増える = より多くのユーザーニーズに対応できる」と勘違いしてしまい、顧客層を広げるために機能追加を進めてしまう
このようにしてどんどん機能が追加され、それに合わせてUIもどんどん複雑になっていく。
多機能の弊害
- UIが使いにくい
- ブランド価値を想起させにくい
- 利用方法を学ばなければならない
- 選択肢が多すぎて行動が起こせない
UIが複雑になって使いにくくなった例
機能を削りにくい主な理由
ほとんどのプロダクトチームは素晴らしい製品を作り、顧客を喜ばせたいと考えている。機能追加はそれを実現する最も一般的な方法だと考えがち。しかしそれは、「短期的」そして「人工的」なドーピング手法でしかない。
その一方で、機能を削る判断をするのはかなり難しい。その主な理由は:
- ユーザーから「使いにくい」という苦情はあるが、「機能を削ってくれ」というリクエストはほぼないので、機能削除の正当化しにくい
- 機能を削ったことによる効果を測定するのが難しい
- 機能を削ったら既存ユーザーから文句が出るのではないかという不安
- もしかしたらその機能をまだ使っているユーザーがいるかもしれない
- その機能が目的で使い始めたユーザーがいるかもしれない
- 機能追加と機能削除のアイディアが出た場合は、本能的に機能追加が優先されがち
おそらく、機能の削除を検討し始める唯一のきっかけは、より洗練された競合サービスが出現し、自社プロダクトの複雑さゆえの使いにくさが露呈し始めてからだろう。まあ、その頃にはほとんどの場合は手遅れであるが…。
日本国内向けのサービスは特に要注意
この議論は特に日本国内向けにしかビジネスを展開していない場合に起こりがち。
というのも、想定ユーザーが日本人だけになってしまうと、どうしても小さなパイからのユーザー獲得になってくるため、プロダクトに機能をどんどん追加することで、より多くのユーザーをカバーするしかない。
結果として、プロダクトのフォーカスがブレ、体験の品質も下げざるを得なくなる。
ところで、リンスインシャンプーを使っている人いる？
ここで機能を増やしたのに、なぜかうまく行ってなさそうな例を紹介する。まずはリンスインシャンプー。元々リンスとシャンプーという2つの異なる機能を1つで実現した夢のような商品。中には、3in1 と呼ばれるボディーシャンプーまで含む3つの機能を実装しているものまである。
でも世の中からシャンプーとリンスは無くならない。というか、リンスインシャンプーの方がマイナーな商品だと感じる。銭湯とかにはあったりもするけれども…。
同じコンセプトで、ボールペンとシャーペンの両方の機能を実装したシャーボという商品もあるが、あまり見かけない。
極め付けは、超多機能の筆箱。小学男子の心をくすぐるこの多機能商品も実用性は必ずしも高くない。
参照元: Twitter
アップデートで機能を削除するのは稀
多くのプロダクトは、初期バージョンはシンプルで使いやすく、その目的が明確だが、バージョンアップを繰り返すにつれ、どんどん多機能になっていく。そしていつの間にか当初の存在価値が存在価値がぼやけはじめていく。
しかし、新バージョンが前バージョンよりも機能が少ないわけにいかない。新バージョンは常に前バージョンよりも「さらに美味しくなりました」でなければならないのだ。
より少なく、しかしより良く (Do less, but better)
冒頭でも紹介した通り、皆さんが日常で利用している商品やサービスのその多くが一つのことを他よりも良い体験を通じて提供している。
それらのプロダクトは必ずしも単純にデザインされているわけではないが、ユーザーに対しては単一の価値を届けるように設計されている。デザイナーは、機能、アーキテクチャ、インタラクション、ユーザビリティ、ブランディング、コミュニケーションなどの製品を取り巻く要素を上手に “隠し”、あくまで一つの価値を生み出している。
優れたデザインは可能な限りデザインをしない
より少なく、しかしより良くというコンセプトは、決して新しいものではない。
1932年生まれのドイツ人工業デザイナー、ディーター・ラムスは、20世紀を代表するデザイナーのひとりとして知られ、大きな影響力を持っている。機能主義の信奉者である彼のデザインに対する合理的なヴィジョンは、「Less, but Better」という有名なフレーズに集約されている。
現代のサービスにおいては、機能が少なければ少ないほどユーザーから長く愛される傾向がある。
なぜなら、そのようなデザインは重要な点だけが凝縮されていて、重要でないものに余計なエネルギーを消費せずに済むからである。純粋で簡素に。原点に立ち返れ。
シンプルなプロダクトを作るための5つのポイント
では、具体的にどのようなポイントを抑えれば、よりシンプルで使いやすく、洗練されたプロダクトを生み出すことができるのだろうか？
- 小さく始める: 必要最低限の機能を実装したMVPの半分、そしてそのまた半分の機能まで削って初めてMVPになる
- データを活用する: ユーザーの利用データを味方に付け、十分に利用されていない機能を見つける。もしくは、ある特定の機能だけを利用されている場合は、それ以外を大胆に削ってみる。(Instagramはそのようにして生まれた)
- 「機能予算」を立ててみる: 製品に実装する機能の境界線を “予算” としてに定め、その年のビジネス目標に直結したものから優先順位をつける
- だが断る: 顧客からの機能追加に関するリクエストを安易に受け入れず、時には断る勇気を持つ
- 代替え策を立てる: 機能を削除することでユーザーから不安が出ることがわかっている場合は、そうならないための案を考える。利用する前、最中、その後など、コミュニケーションデザインや、サポート面で満足度を補完する
「そもそもなぜこの機能が必要なのか」という問いを繰り返すのが重要
結局のところ、短期的な機能要求と、長期的な製品の成長のバランスをとるための単純な法則は存在しない。そんな中で、どれだけ機能を削れるか、そしてどの機能を残すかを判断するのがデザイナーとしての能力の一つであることは間違いない。
たまには、デザインタスクに追われる日々を離れ「もしゼロからこのプロダクトを作り出すとしたら、最初に盛り込む3つの機能はなんだろうか？」と自問自答してみるのをオススメする。
ホンダのスーパーカブが一億台以上も売れたことからも分かる通り、ユーザーは世界最高技術のプロダクトよりも、世界で最も自分の目的をシンプルな方法で実現してくれる商品に熱狂するのだ。
サービスデザインの基本: 迷ったら付けない
プロダクトのスペックを考える際に、特定の機能を実装するかどうかで迷うことがある。特に付けなくても良いが、もしかしたら利用したいユーザーがいるかもしれないので、「念の為」付ける判断になることが多い。
そんな実装するかどうか迷った時は、とりあえずその機能は今回のバージョンでは付けずに、利用データを検証し、どうしても必要な場合は次のバージョンに実装するプランを考えよう。
