先日iPhoneのOSバージョンを13にしたら、App StoreのUpdateアイコンがArchadeに変わってしまい、右上の顔アイコンをあけたところに機能が移動したことは人に教えてもらうまで気づかなかった。この例にもれず、使い慣れたユーザーインターフェイスがバージョンアップによって急に変わってしまい苦労した経験は多いのではないかと思う。
開発元のソフトウェアベンダーもあえてユーザーインターフェイスを使いにくくしているわけではなく、むしろ少しでも使いやすくしようと日々努力している。それが結果的にユーザーインターフェイスを使いにくくしてしまっているのも、また事実である。
私自身が大手ソフトウェアメーカーの開発部門に在籍していた経験も踏まえ、開発プロジェクトで働く力学と、それによりなぜ使いにくいユーザーインターフェイスができてしまうのか、そしてそうならないために開発者が学ばねばならないことは何か、について考察してみた。
バージョンが上がると使いにくくなる、その理由
プロダクトは Ver. 3～4で成熟する
プロダクトは最初に世の中に登場するときは、さまざまな理由で不完全な状態でリリースされることが多い。スケジュール順守やリソース不足による機能実装の積み残し、市場や顧客フィードバックの不足、などである。最初のバージョンを出したものの、市場で淘汰されるプロダクトも多い。
市場の洗礼を受けて生き残ったプロダクトは、バージョンアップが行われることになる。だいたいメジャーバージョンアップを2、3回やると、当初達成したかった機能がだいたい実装され、また顧客フィードバックも適度に反映された状態になり、プロダクトとして成熟してくることになる。
例でいうと、Windows 95 (Ver. 4.0)、Office 951、Mac OS System 4、iPhone 3GS (iOS 3.0)、Android 4.02が、ユーザーインターフェイスとして一応の成熟を見る頃となる。
この頃になると、市場でも一定の評価が得られ、パワーユーザーではない普通のユーザーも増えてくるころとなる。
開発者は自分の成果を見せる必要がある
さて、基本機能が固まったプロダクトは、開発チームを維持していくためにさらなる開発ロードマップを引くことになる。追加する機能はどうしても枝葉の機能が増えていき、利用シナリオについてもそんなにメジャーではないものも増えていくことになる。しかし、プロダクトを目立たせて売り続けるためには、これらの機能を大々的に宣伝して、顧客の注意を惹く必要がある。
開発者は新機能を見せつけたい
すると何が起こるかというと、開発チームは新機能を使うボタンをユーザーインターフェイスの目立つところに置くようになる。たとえば第一階層目のメニューでいままで使用率が低いと「思われる」機能と入れ替えたり、旧機能の後継機能で機能アップしたと「信じる」機能と旧機能のメニューを入れ替えたり、といったことを行う。そして、機能の数が増えていくにつれて機能のメニューの数は増え続け、ユーザーインターフェイスが複雑になっていくのである。
開発者は新しい見た目でユーザーを驚かせたい
加えて、実際には機能アップはしていなくても、バージョンが上がったということを感じさせる一番簡単な方法は見た目を変えることである。ビジュアルを変更することで、ユーザーはプロダクトのバージョンがあがったことを目で感じることになるのである。たとえば、アイコンを変更したり、ツールバーの見た目を変更したりといった内容である。このことから、ビジュアル変更の機能は、メジャーバージョンアップの際の主要な開発項目として計画されることが多い。これはついついやってしまいがちである。
しかし、既存ユーザーの反発にあい、結局互換モードを用意してそこから抜け出せないという状況になることもしばしばある。いままでのソフトウェアの歴史の中でも最も極端だった例のひとつははWindows 8で、タッチ対応のためにスタートボタンをなくすという暴挙に出たが受け入れられず、マイナーバージョンアップでボタンが戻ることになり、次のメジャーバージョンアップで結局スタートメニューが復活した。
多くのユーザーは使い慣れた操作方法を変えたくない
パワーユーザーではない多くの初心者ユーザーがプロダクトを使うようになると、その人たちは開発チームのように毎日プロダクトに接しているわけでもなければ、常にプロダクトのことを考えているわけでもない。中には数カ月に1回触るかどうかのユーザーもいるだろう。そういうユーザーは基本的に新しいことを積極的に覚えようとせず、変化についていこうとはしない。いままで使っていた機能の使い方が大きく変わるようなユーザーインターフェイスの変更は基本的に許容しないのである。
では、どうすればよいのか？
ユーザーフィードバックに声を傾ける
まず最初にやるべきことは、ユーザーがユーザーインターフェイスに対してどう思っているかをよく聞くことである。ユーザーインターフェイスを変更したのであれば、それが良い評価につながったのか、ネガティブな評価になったのか、ネガティブだとすると何がいけなかったのかをユーザーのフィードバックを分析してあぶりだすことである。
テレメトリを実装して機能の利用状況を計測する
ユーザーの声を直接聞くことに加えて、より多くの統計的なデータを集めることも重要になる。プロダクトに製品フィードバックの機能を付けたり、ユーザーの利用状況を自動的に収集するようなしくみを実装して、そのデータを分析してみるのも手である。
機能が多いことは必ずしも価値にならないことを認識する
開発チームとしては自分たちの存続のためにも、新しい機能を生み出し続けていくことが自分たちの価値であると思いがちであるが、ユーザーは必ずしもそうは思っていないことを認識する必要がある。プロダクトの初期バージョンの時は、もちろん機能が足りないと思っているユーザーが多いのだが、バージョンアップを重ねるごとにその数は減ってくる。いつまでも同じトーンで機能を増やし続けることは得策ではない。少なくとも入り口となるユーザーインターフェイスを増やしてしまうことは、ユーザーにより多くの判断を求めることにつながるため、ある一定の水準を超えるとネガティブに働くことが多い。
変わらないことも価値だと認識する
情報過多で変化が激しい今の世の中、ちょっと目を離すとざまざまなモノが変わりすぎてついていけなくなることが多いが、時間を経てもあえて変化しないことも重要になってくる。ただし、そのためにはCEOレベルで強い意志が必要になる。なぜなら先に述べた通り、開発チームは自分の存在意義を出すために常に変化を求めてくるからである。
これがうまくいっていたと思われる例は昔のスティーブ・ジョブズが存命していたころのAppleで、Mac OSやiOSのデザインをいたずらに変えたりせずに長期間 (Mac OSは15年以上!) にわたり同じルックアンドフィールや使い勝手を保ち続けていた。
ただし、ジョブズ亡き後はこの方針が揺らいで、いろいろと変更をしようとしているようにも見える。ユーザーインターフェイスはCEOも巻き込んだレベルの問題解決が必要になってくるのである。
シンプルなのがベスト
結局、ユーザーはそんなに多くのことは覚えられないので、ユーザーインターフェイスの入り口はシンプルなほうが良い。機能を実装するなら、裏の見えないところで、表から呼び出したときにいろいろやってもらって、その結果だけ帰ってくればよい。Microsoft Wordのインターフェイスもさまざまな試行錯誤が数バージョンごとに行われ、見た目がシンプルになったり複雑になったりを繰り返しているが、最近目指しているところは入り口はシンプルにすることのようである。
まとめ
ユーザーインターフェイスにも流行り廃りがあり、フラットデザイン、マテリアルデザイン、最近だとFluent Designというのが流行りだそうで、大手ソフトウェアベンダーは定期的に流れを作って、こぞって自社のソフトウェアをそのデザインに適用させようとしている。まるで毎年洋服の流行が変わったり (メーカーが変えたり)、車のデザインが丸くなったり四角くなったりするのと同じである。
ユーザーインターフェイスの進化に究極のゴールがあるかどうかは筆者は懐疑的だが、今後AIの進化の力も借りて、入り口のユーザーインターフェイスの数は増やさずに処理できるようなしくみ (たとえば会話形式？)が発展していくことが望ましいだろう。また、開発者は、入り口となるユーザーインターフェイスの設計には細心の注意を払い、今までと大きく変えたり数を増やしたりしないように常に心掛けるべきだろう。