プロダクト作りにおけるSimpleとEasyの違い

こんにちは、ひまらつです。プロダクトマネージャーをやっています。

最近プロダクトの「Simple」と「Easy」について考える機会がありました。これまでは意識せず使っていたこれらの単語ですが、自分の中で整理ができたのでnoteに書いてみます。

EasyとSimpleの違い

Easy - 簡単に使える

Easyは「簡単に使える」ことを意味します。内部で色々な処理をしていても、それが隠蔽されていればユーザーからは簡単に見えます。
ユーザーは自身の目的を達成するためにプロダクトを使います。同じ機能を提供していても、ユーザーの目的によって使いやすい or 使いにくい が分かれるので、Easyは主観的な要素といえます。

Easyは簡単にするため内部で色々処理する

Simple - 構成要素が簡素

Simpleは「その要素が簡素である」ことを意味します。簡素なパーツは一つ一つの役割や意味を理解しやすいですが、使うためには自分で組み立てる必要があります。
要素が簡素かどうかはユーザーの使い方には依存しないため、Simpleは客観的な要素といえます。

Simpleは簡素なため理解しやすい

プロダクト作りのEasyとSimple

EasyとSimpleの定義を書きましたが、プロダクト開発のシーンではどう考えるのが良いでしょうか。私は、「ユーザーのユースケースが限定できる場合はEasyにする」が良いと考えています。

例えばユーザーの90%以上が同じような使い方をしているのがわかっている場合、そのユースケースに合わせて設計することで使いやすい機能を提供できます。みんな同じような目的を持っているなら、それに最適化しようという発想です。

逆にユーザーごとに使い方が異なる機能はSimpleにします。例えば権限設定のカスタマイズ機能は、ユーザーが自分の組織やチームに合わせて柔軟に組めるところに魅力があります。これを無理にEasyにしようとすると「誰かにとっては便利だけど、別の誰かにとってはフィットしない」機能になり、全体的な満足はむしろ下がってしまいます。

新しい機能を追加する際は、その機能をユーザーがどう使うかを考え、EasyにするかSimpleに留めるかを判断すると良い気がしています。そしてその判断のためには、インタビューや定性分析を通してユーザーの解像度を上げることが必要です。

EasyとSimpleは両立できる

ここまでEasyとSimpleを対比して書いてきましたが、この2つは両立できます。反意語を考えるとEasyの反対は「Hard」、Simpleの反対は「Complex」です。物事がシンプルかどうかと扱うのが難しいかどうかは別の概念です。

何かを作るときにまず目指すのは「Simple」で、これはどんな場合も目指せます。複雑なものでも、できるだけ紐解いてSimpleな要素の組み合わせにします。Simpleにしていく過程でより深く対象を捉えられますし、Simpleなものはユーザーにとっても、開発チームにとっても理解しやすいです。

Simpleに保つことは常に意識する

要素をSimpleに保った上で、ユーザーのユースケースが明確であれば「Easy」にします。ユーザーの代わりにSimpleな要素を予め組み立てておくことで、ユーザーの行動を省エネすることができます。

最大限Easyなものを作りたい

Easyはひとつ間違えれば余計なお世話です。望まれてない最適化はユーザーの理解を妨げ、逆に使いにくいものにしてしまいます。それでも、できる限りEasyに寄せた方が良いというのが私の意見です。

SaaSのプロダクトはお客さんの仕事を効率化し、本質的な仕事に集中できる時間を増やします。SaaSの使い方に手間取ったり、毎回マニュアルを見ないと使えないのでは効率化への貢献は低いでしょう。セットアップが簡単で、マニュアルなしで使えて、欲しいところに欲しい情報があるのがベストです。
それに、サービスを使っていて、こちらの意図を見透かしたかのような挙動に出会ったときはワクワクしますよね。この体験はユーザーを深く理解したサービスにしか作れない「Easy」の極みだと思っています。触っていて楽しく、しかもそれを使うことで自分の仕事を加速させてくれるプロダクト。そういったものを目指したいですね。

おわりに

プロダクト作りにおけるEasyとSimpleの違いを整理してみました。シンプルという言葉は昔からなんとなく好きでしたが、この整理を通じてその理由を理解できた気がします。今はプロダクト設計を考える際に立ち返る1つの基準となっています。
最後まで読んでいただきありがとうございました。