なぜユーザーの要求を知るだけではダメなのか？

ユーザーの要求を知ることは重要です。ただし、それを知ったからといって、うまく形が作れるかというとそう簡単な話ではありません。

とあるスーパーのセルフレジ端末は少しづつアップデートされているのですが、そのアップデートのされ方があまりよくありません。なんとなくユーザーの要求が反映されているにも関わらずです。なぜなのでしょうか。

バージョン1：支払い方法を途中で変更するには？

まず、最初のバージョンは、このようなデザインになっていました。

ユーザーは最初に支払い方法を選択して、商品をスキャンします。その後、事前に選択していた支払い方法に則った支払い手続きに進み、確認画面を経て支払いを完了します。

ところが、私が実際に使っていると問題が出てきました。スキャン後に現金不足やカード忘れに気づき、支払い方法を変更する必要が出てきたのです。

しかし、画面を見てもどこからできるのかわかりません。しかたがないので、ループものの映画の主人公のように覚悟を決め、「支払い中止」ボタンを押しました。

するとスタスタと店員がやってきました。もしかすると、支払い中止をして商品だけ持っていってしまう悪い人もいるのかもしれません。私は店員に「どうされましたか？」と聞かれたので、支払い方法を変更したいことを告げると、店員は手慣れた様子で、支払い方法選択画面に切り替えました。

スキャンのやりなおしという最悪の事態を回避できましたが、それからというもの、支払い方法を変えたくなる度に、私は毎回このようなやりとりを店員とすることになりました。

バージョン2：支払い中止ボタンを押すと何が起こる？

ある日、私は画面が変わっていることに気がつきました。いつものように「支払い中止」ボタンを押すと、なんと「支払い方法の選択」画面が表示されたのです。

私からすると、支払い方法をすぐに変更できるようになりました。おそらくデザインした側も私のようなユーザーを想定したのかもしれません。もしくは、店員から「何度も支払い方法選択画面を出す作業が発生している」と言われたのかもしれません。

つまり、ユーザーや店員の不便を解消したある種の「問題解決デザイン」でした。しかし、解決策としては何か歪なのです。

まず「支払い中止」ボタンが何を意味するのかわからなくなってしまいました。「支払い中止」すると「支払い方法の選択」をすることになるのです。

バージョン1では少なくとも「支払い中止」ボタンを押すと、支払いが中止になるので、不整合はありませんでしたが、バージョン2では世界が壊れてしまったのです。

この点はデザインにおいて非常に注目すべきことです。ユーザーの操作数を減らすかどうか以前に、UIには意味の構造が存在するということです。それを無視して「改善のようなこと」をしても良い形にならないことを示唆しています。

また、作り手がその意味の構造を意識せずに作っていることを示唆しています。単に「ユーザーが支払い中止ボタンを押す、店員が話を聞く、店員が支払い方法選択画面を出す」という行為が繰り返されているから「支払い中止ボタンと支払い方法選択画面をつなげる」という発想です。

その結果、支払い方法を変更したい人と支払いを中止したい人、両方にとって意味のわからないものになってしまいました。

また、そもそも、バージョン1で「支払い方法を変更するには、支払いを中止して店員とやりとりする」という謎の操作手順が出来上がってしまっていたことも浮き彫りにもなりました。

バージョン2で、この「謎の操作手順」（＝意味のつながりのない暗黙的な操作手順）をユーザーの要求とみなし改善したとしても、おかしな形になってしまうわけです。

そんなわけで、バージョン2は意味の構造が壊れ、裏技、隠しコマンドのようなものが出来上がってしまいました。

バージョン3：「支払い方法を後で選択」する？

しばらくして、システムは再びアップデートされました。今度は、最初の画面に「支払い方法は後で選択」ボタンが追加されました。

やはり、バージョン2の裏技的な操作方法が問題だったのか、それとも、単に支払い方法を後から変更する人が多かったのでしょうか。

いずれにせよ、これまで通り先に支払い方法を選択するやり方に加えて、後で支払い方法を選択することもできるようになりました。（支払い方法の選択方法の選択肢が増えたので、ちょっとややこしい）

先でも後でもどちらでもいいということは、裏を返せば、支払い方法を選択するタイミングに、システム的な制約はないということかもしれません。

このバージョンも使ってみると歪な形になっていることがわかりました。

というのも、そもそも支払い方法を変更したくなるのは、後で現金不足やカード忘れが判明した時なので、先に「支払い方法は後で選択」を押すことはないのです。

これではまるで山の入り口の横に「遭難する方はこちら」と看板が立っているようなデザインです。

この点も非常に重要です。作り手が認知した一連の連結された支払い方法変更操作のイメージと、その都度ユーザーによって組み合わせられる操作のイメージとの間には大きなギャップがあるのです。

シチュエーションの不自然さを感じつつ、ひとまず「支払い方法は後で選択」を押してみると、スキャン後に支払い方法の選択を行うことができました。支払い方法を変更したい時は「戻る」ボタンで一つ前の支払い方法選択画面に戻ることができました。ボタンのラベルから期待される通りの振る舞いで、この中の世界に秩序が生まれました。

次に、従来通り、先に支払い方法を選択してみました。こちらの場合はスキャン後にすぐに選択済みの支払い方法に応じた画面になりました。今まで通りです。ただし「支払い中止」ボタンが無くなり、ここにも「戻る」ボタンが増えていました。一見、こちらも秩序が生まれています。

ところが「戻る」ボタンを押してみると、意外な画面が表示されたのです。1つ前のスキャン画面に戻るのかと思いきや、なんと支払い方法の選択画面が出てきたのです。

意外なところで世界が壊れていました。

これでは、スキャン画面に戻ろうとして「戻る」ボタンを押しても、なぜか支払い方法の選択画面が出てきてしまうので、ユーザーは何が起こったのかわかりません。

ボタンのラベル名を「支払い中止」から「戻る」に変えただけ、もしくは、支払い方法を後で選択するフローの画面を使い回したのか、実際のところはわかりませんが、意味のつながりが無くなってしまっていました。

アイデア1：手順を解体する

ここまで見てきたように、ユーザーの要求らしきものを把握したとしても、それをタスク指向的に連結した一連の操作要求として捉えてしまったり、意味の構造を作れないと歪で混沌としたデザインになっていくようです。

ここからは、私が改善案を発想する際に、頭の中でどういったことが起こるのかについて考えてみます。

私が思いつくのは「手順の解体」です。

今回の場合、合計金額がわかる前に、支払い方法の選択方法を選択することは困難なので「支払い方法を後で選択」という選択肢自体が無意味です。

次に支払い方法を選択するのは先か？後か？を考えます。

システム的な制約もないのであれば、金額確定後に支払い方法を選択する方が良さそうです。これまで、ある種の間違った操作とされていた「後で支払い方法を選択する」操作を標準にします。これだけでシンプルになります。

繰り返しになりますが、ここで用いられる考えに「手順の解体」があることです。しかも手続きという手順の塊のようなものをデザインしようとしているのにです。

なぜなのか考えてみると、手続きをシステム化をするときにデザイナー自身がデザイン対象を「手続きである」と認識しているので、一連の順序性のあるものとしてイメージすることが多くなります。

そういった場合、今回のような「支払い方法を後で変更する」という事象に遭遇すると、それを、一連の固定化した操作手順、もしくはそれを元にした操作要求として認識して、改善の前提にしてしまうことがでてきます。

これは言ってみれば「過剰な手続き化」です。

つまり、手続きが肯定されやすい手続きシステムをデザインするときこそ「過剰な手続化」に注意する必要があるのです。

アイデア2：「同じもの」を1つにする

次に、確認画面を見ていきましょう。確認画面は金額などが表示されます。「支払い内容」が表示されているとも言えます。一方で一つ前の読み取り画面においても合計金額は表示されています。ということで確認画面を減らすアイデアも出てきます。

別々に扱われているものに共通項を見出し、実は同じなのではないかと考え、1つのものとして扱うという発想です。1つのものとして扱うというイメージがあれば、2つの画面に必要不可欠な差分があったとしても「読み取り後に差分を追加で表示する」という表現も発想しやすくなると思います。

また、私の頭の中を観察すると、このあたりからすでに、ステップを統合しているのではなく、ものとして捉えているかもしれません。

アイデア3：名詞＞動詞にする

次は、これまで出てきたことを異なるスコープに応用します。

2つのステップとして別画面にあったものを1つにする発想です。1つにするといっても、ステップではなく「スキャンした商品」というオブジェクトに対する「支払い」アクションとして扱います。

ユーザーはスキャンをして任意のタイミングで支払いアクションを起こします。その支払いアクションにバリエーションがある、という構造です。

ここで用いられているのは一種の名詞＞動詞シンタックスへの変換、OOUI的な発想です。

人によっては元のステップの画面の要素を組み替えたように感じるかもしれませんが、ステップを廃止した点が大きく異なります。

アイデア4：アクションをプロパティにする

「スキャン」してから「支払い」アクションをとるという、2つの順序を解体できないか考えてみます。

順序性をなくすための簡単な方法は同じ場所に並列に配置することです。このことによって作り手が余計な制約を設けない限り、順不同で操作できるような作りになります。

順序性を解体することで、商品をスキャンして、思った以上に金額が必要であれば支払い方法を変更する、支払い方法を変更した後にまた商品を追加するなども自由にできるようになります。「スキャンした商品」や「支払い方法」プロパティで構成される「支払い」オブジェクトを作っている感覚です。そしてそれに対して支払い手続きというアクションを取るのです。

アイデア5：応用する

さらに推し進めていくとどのような発想になるでしょうか。

支払い方法をプロパティで表現するアイデアも、アクションとして表現するアイデアも、次の画面では支払い手続きごとの表示があり、そこでは合計金額などを表示する必要があります。

支払い前の確認といった意味合いがありますが、実はスキャン画面でも合計金額が表示されています。それに加え、支払い方法をプロパティで扱うアイデア4の場合は、支払い方法も明示されています。支払う内容の確認という意味では十分かもしれません。

ということで、仮にハードウェアの連携や通信による待機時間の制約などないとすると、統合するアイデアも出てきます。

初期値で選択されている支払いをいつでも受け付け、初期値以外の方法を選択した場合も、すぐにその方法で支払いを受け付けます。もちろんこの状態で商品を追加でスキャンすれば合計金額も変わるという世界です。こうすることで「支払い手続きへ」というボタンもなくなり1画面になりました。

形に関する経験や知識

今回はセルフレジという手続き的なシステムを題材にしました。アイデアをさらに推し進めると、そもそも決済方法を選択する必要性がないデザインを考えることもできるかもしれません。

改めて既存システムの変遷と、改善案の変遷を見てみましょう。既存システムはバージョンを追うごとに複雑化しているのに対し、改善案の方は徐々にシンプルになっています。

ここで重要なのは、デザイン経験、デザイン原則、パターン、そこから発想される様々なアイデアなどが出来上がる形に影響を与えるという点です。

ユーザー要求だけでいい形になるわけではなく、むしろ暗黙的な手順が増えたり、いとも簡単に世界が壊れてしまうことがあり得ます。また、デザイナーが持っている形に対する経験や知識は、ユーザー要求をどう認知するのかにも関わっていることが今回のケースから見えてきました。

コンピューター科学者のナサニエル・ボーレンスタインは、デザイン感覚、技術知識、ソリューション経験に欠ける人々（つまり普通の人々）が考えたアプリケーションの基本設計は、囚人移送スケジュールのように「順番通りにやるだけ」のものになると言っています

『オブジェクト指向UIデザイン』