こんにちは。サカイと申します。都内でデザイナー兼PMをしています。

以前の職場では完全なデザイナーとして働いており、仕様を決めている人から複雑な仕様をドンと渡されていました。それをなんとかわかりやすくしようと試行錯誤していたのですが、なんとかなった試しがありません。

現在は仕様を考える立場になったので、同じ状態になることはできるだけ避けたいと考えています。当時は受ける側であったため、「そうはならんやろ」と思っていたのですが、これは単純に視野が狭かっただけでした。

様々な制約を念頭に入れて仕様を考えると、自分も気付かぬうちに複雑化の罠にハマってしまいます。何かしらの仕組みで気付ける状態を作っておく必要がありそうです。経験を棚卸しして対策を練りたいと思い、これを書いています。

無理そうだけど…なんでかな

まだ新人の頃、案件の中に「競合他社と同じ商品をユーザーに少し安価で提供できるが、条件が複雑になる」というものがありました。確かに安くて良いのですが、ユーザーに複雑なルールを把握・記憶するコストを強いるものでした。

仕様も開発を行っている社内ですら「この仕様って〇〇だっけ？え、違うの？」と齟齬が何度も発生するレベルの複雑さで、仕様書はかなりの文字量です。

ただ、複雑とはいえユーザーには安価に他社と同じ物を提供できるので、リリースすれば選ばれるはずであるという戦略は、引っかかりはありつつ当時は一定の納得感がありました。

このとき、僕もチームメンバーも一同に「無理そうだな」と感じていたものの、なぜ無理なのかを説明する知識と言語化能力がありませんでした。（そもそも組織に問題があることは自明ですが、今回は論外とします）

「複雑そう」で終わる

もちろん上手くまとめられなかったという実力不足も原因のひとつですが、それだけでは説明できない根本的な問題が存在していたと思います。

みなさんは説明書や利用規約を全部読んで理解しようと思いますか？大抵は全く読まないか、ざっと眺めて必要そうな部分だけ拾い読みするだけではないでしょうか。僕らが作っていたものも同じで、すべてが把握される前提で作られた仕様をユーザーにポンと渡してもうまくいくはずがありませんでした。

この施策がリリースされた結果、ほとんどのユーザーが細かいルールを理解しようとせず、全体から受ける印象で「複雑そう＝コストが高い(自分たちにとって不利益がある)」と判断をしていました。「安くなる価格」 < 「理解するためにかかる(であろう)コスト」の状態です。（これは「処理流暢性」や「流暢性の処理バイアス」と呼ばれる現象です）

なぜ失敗したのか

価格のコントロールは難しいため、理解にかかるコストについて考えたいと思います。

そもそも人間は文字を読まない。
下記のような調査結果があります。

長いルールを作りこんでも読まれなければ意味がありません。パッと見て「複雑そう」だと判断された時点で大量に離脱し、残った少数も全文を読むことはありません。

読める量と読んでくれる時間という切り口でも考えてみます。人間が1秒間に読める文字の量は静止状態で10文字ほどと言われています。1分間で600文字ほどです。Webの閲覧時間については総務省の資料を参照します。

この22.4分の中で、自分のサービスに使ってくれる時間は興味を引く内容でせいぜい1~2分と言ったところでしょう。

上記を考えると本文全体で1200文字ほどであれば時間内に読める量ではあるが、その中で読まれるのは240文字ぐらいということになります。簡潔にまとめることがどれだけ大切かわかります。

僕の体感では上記でも多いと感じます。タイトル周りをざっと見れば概要を掴んでもらえる状態まで仕様をシンプルにする必要があると思っています。Twitterが本文を読まずにツイートしようとすると警告を出すことで話題になりましたが、本文をそもそも読まない人も多いのです。

タイトルぐらいの簡潔な文章で表せるもの、または1枚の図で把握できるレベルまでシンプルなものが求められます。そもそも説明がいらない状態がベストですし、どうしても説明が必要な場合も「〇〇機能について」というタイトルと、1枚の図で8割どんなものか理解できる状態を目指すのが良さそうです。

注意

「情報を簡略化してしまうと、大切な情報が抜け落ちてしまい、誤解を生むのではないか？」という反論が予想されます。もちろんこれは正しいと思います。安全に関わるものや不利益を被ることなど、正しい理解が必須である場合に上記を適用するのは危険です。

一方で、「規約や条件は読まれない」という現実を無視して、難解なまま記載をする状態も本質的にユーザーの利益になっていないのではと感じます。伝える努力をすることと正しい情報であることは分けて考えたい。両方大切であり、両立する努力をすべきだと思います。この記事では2点を分けて、前者についてだけ記載していることに注意してください。

複雑さは不信感を生む

リリース後の反応として興味深かったのは、「内容を正しく理解し、自社のサービスの方が良い条件であることも理解した上で、他社を選ぶ」と言うユーザーが一定数存在したことです。

彼らは「たとえ安くてもルールを把握しておくのが大変だし、何より複雑にして誤魔化そうとするのが気に入らない」と言っていました。

論理的に考えると同じ価値のものを他社より利率を落として安く提供しているのですから、むしろ親切に感じます。たとえ他社が選ばれたとしても、自社のサービスへの嫌悪感を高めてしまう結果になることは予想していませんでした。

お金が絡むと複雑な条件は不信感を生み、ユーザーとの信頼関係を崩してしまう致命傷になってしまうのかもしれません。

数値だけを見て施策を考えていると、価格などの数値に現れやすいものしか見えず、条件を理解するコストやユーザーの心象を考慮できていなかったんだなと感じています。（「悲劇的なデザイン」に出てくるフォードの例を思い出します）

一度信頼を失うと回復は難しいです。さらに、このような複雑な機能改修は、開発に負債を残します。サービス内の余白を食い潰し、その後の改修を難しくしてしまいました。

気付きと対策

上記では複雑化を避けるために文字量を減らしたり、表現を工夫するといった具体的なHowの話をしていました。最後は、そもそも仕様をどのような状態にしておくべきかについても考えてみたいと思います。
下記2点があげられそうです。当たり前ではありますが、大切なことな気がしています。

1. わかりやすい名前を付けられない機能は伝わらない可能性が高い
実際に問題が起こった機能の開発現場では、ある人は「A機能の開発」と呼び、ある人は「Bルールについて」ある人は……

このようにみんなの頭にパッと浮かぶ共通のイメージがなく、わかりやすい名前を付けにくい機能開発は複雑な可能性があります。イメージがわかないということは、図で表すのが難しく、共通の理解を作りにくいです。

2. 何も知らない人が1分間でどんな理解をしたか、事前に把握する
1分間は目安です。ラフの段階で見てもらい、短い時間でキャッチできた要素は何で、どんな理解のズレがあったのかを知ることで、改善を行うことができます。

上記2点で問題が発生した場合は、目的を絞り、仕様を簡略化し、機能を細かく分ける必要がありそうです。最も重要なのはあらゆる機能について「本当に必要か」についてきちんと議論することかもしれません。複雑さを作っているのは大元の価値ではなく、付属部品であることが多いです。

チームメンバーに機能の概要を説明する、説明せずにアウトプットを見てもらうだけでも気付くことは多いです。チームメンバーが理解できないことや勘違いを起こす問題は、ユーザーも同じ状態になる可能性が高いです。
大切なのは社内外問わず早いうちに失敗し・改善することなのではないでしょうか。