見出し画像

「マイクロインタラクション」は"究極のおもてなし"、ってどういうこと?

Keynoteアニメーション以外では、これまで提案資料やちょっとしたUIくらいしか作ったことがない。つまり「動き」のないものしか作ったことがなかった。

だから、『マイクロインタラクション』に書かれているように、「" この画面 "では、この表示 / 動きがあった方がいいな」とユーザーの行動を先読みして設計する発想は、僕にはそこまでありませんでした。

でも、このマイクロインタラクションは相当、ユーザーの行動に影響を与えるものだと、読んでみてわかりました。

この書籍はWebのインタラクション中心について話しているため、今回の記事の内容もWebよりにはなります。ただ、Web界隈の人しか読まないでは、興味深い内容なのにもったいない。

そのため、まずは『マクロインタラクション』というものに興味を持ってもらうために、スロットマシンの話を紹介します。

スロットマシンのマイクロインタラクション

多くの人は、カジノとまで行かなくても、ゲームセンターか何かでスロットマシーンで遊んだことが一度はあるのではないでしょうか。

絵柄を3つ揃えると、投入したコイン以上のたくさんのコインがジャラジャラ〜と出てくるのですが、ギリギリ揃わなかったことって割とありませんか?そんな時、

「アァーーー!!惜しィーーー!!」

と思わず言ってしまいますよね。これ、実は惜しいもクソも計算されているものだそうです。よく考えれば向こうはビジネスなのだから、儲かるようにしないわけがない。そこでマイクロインタラクション

これどういうカラクリかと言いますと、ギリギリで揃わずに止める「フィードバック」を与えることによって、「惜しかった...もう少しだった...次はいける...」となってしまう。そうなると人はコインを入れてはプレイして、コインを入れてはプレイして......となってしまう。結果、運営側は儲かるというわけです(もちろん他の仕組みも色々あるとは思いますが)。

人間の学習の仕方とマイクロインタラクションの目的

スロットマシンの例は、どちらかというと道徳的にあまり正しくないマイクロインタラクションの使い方かなとは思いますが、フィードバックが人にもたらすものの例としては、とても有用だと思います。

大まかに言って、人は「仮説検証」のループによって学んでいると言えます。人は何か行動を起こす前に、なんらかの仮説(あるいは期待とも言えるかな?)を持っています。「AすればBになるだろう」みたいな感じです。

なんでも例にはなるのですが、僕たちは水道の蛇口をひねると水が出ることを知っていて難なく水を使うことができますが、これは学習の賜物です。先ほどの「AすればBになる」に当てはめて考えると、「蛇口をひねれば水が出る」です。認知心理学的に言えば「メンタルモデル」ですね。

じゃあ蛇口をひねれば「必ず」水がでるかと言うとそうでないこともあります。水道代を払えなければ水は出てきませんよね。もしこの時、水道を管理 / 提供している側が、お金が払われていない場合にいくつかの手段で連絡をするというルールを持っていなければどうなるでしょうか。

「お金を払っていないのかな?いやでも何も言われていないしな...」「もしかして水道管が破裂したのかな?」と、多数の可能性で迷ってしまうし、次の行動を取れなかったり、見当違いの行動をとってしまったりします。

それと同じで、Webサービスやアプリも、ユーザーに適切な案内やフィードバックを出さなければ、ユーザーに混乱、ひどい場合には損失を与えかねません。

そこで、ルールをしっかり設計しておく必要があります。

インタラクションのルールを設計する

どのようなインタラクションがユーザビリティを高めるかについては、ケースバイケースな話なので、どちらかというと概念的なところに触れていこうと思います。僕は読んでいて、次の3つが大事かなと思いました。

> 迷わないように案内をする
> 補足情報を示す
> 行動に対するフィードバック(結果や確認)

これを実現していく上で、マイクロインタラクションを作ることになりますが、ルール設計が何よりも重要なのだと思いました。全部は書きませんが、書籍の中から少しだけ紹介すると、設計すべきルールには次のようなものがあります。

> マイクロインタラクションが起動された時にどう応えるか
> 操作の順番とそのタイミング
> いつどのようなフィードバックが返されるか

これを実際に作ろうと思うと、条件分岐の図を描くことになります。サービスが高機能であればあるほど、たくさんの条件が発生しそうですね...。そう思ったらプログラマーすごいな...。

マイクロインタラクションの種類

僕がざっと読んで理解しているので、実際にインタラクションの設計をする時に、最終的に次の要素として落とし込まれるかなと思います。

> テキスト
> 色
> プログラミングで作る動き

「プログラミングで作る動き」というのは、マウスオーバーした時にどうとかユーザーが一定時間同じページに滞在していたらどうとか、そういうのです(もっとあるだろうけど)。

テキストで十分解決することもあるので、Webだからと言っていつもいつもがっつりコードを書かなくてはならないわけではないです。

やらなすぎを見たことはあっても、やりすぎを見たことはないのですが、「わかってるよ!今やろうと思ってたんだよ!うるせえなー」となってしまいかねないのでよくないでしょう。

デザインを学ぶ人が増えれば、世の中はもっと便利になるのかもしれない

今回、『マイクロインタラクション』を読んで、かなり細かいところに目が行くようになった気がする。知識や情報として知ってないものは、目の前を通っても認知できない可能性が高いと思うので、タイミング的にもかなり良かったかも。

サービスのグロースの観点で言えば、使えば使うほど便利になったり、あまり利用頻度が高くない人を特定して、彼らがどんどん使いたくなるようなマイクロインタラクションを設計すれば、サービスのアクティブ率や利益はかなり上がるかもしれない(もちろんスロットマシン的にはならないようにすべきだけど)。

また、普通に生活をしている中でも、わかりにくいなーって思うことが割とありますよね。僕もよく「なんだこれわかりにくいなー」と、よく思ってます(笑)。

インターフェースに触れた時に案内や誘導がないことで、困るシーンってまだまだいっぱいある。たくさんの人がデザインを学べば、もっと世の中は便利になりそうだなーと思いました。

この記事が気に入ったらサポートをしてみませんか?