# マイクロインタラクション
## マイクロインタラクションのデザイン

マイクロインタラクション: 単一のシナリオに基づいてひとつの作業だけをこなす最小単位のインタラクションのこと 
例「携帯電話を消音にする」

- マイクロインタラクションに焦点を当てれば、すぐれたユーザーエクスペリエンスを実現できる

## マイクロインタラクションの歴史
- マイクロインタラクションの歴史は最初期の家電製品にまでさかのぼる。
- 今日、我々が日常的に使っている標準的なマイクロインタラクションも、かつてはユニークで画期的なものであった。

## マイクロインタラクションの構造
- 優れたマイクロインタラクションでは、下記のパートがスムーズに展開される
トリガー→ルール→フィードバック→ループとモード
## トリガー
### 手動トリガー

手動トリガー: ユーザーが自ら起動するトリガー
システムトリガー: システムが自動的に起動するトリガー

#### ターゲットとなるユーザーがコンテキスト(周囲の状況、文脈)からトリガーであると認識できるものをトリガーとする
- メトロカード自動販売機の例
- マイクロインタラクションの多くは、ユーザーが何をいつ、どれくらいの頻度でやりたいと思っているかを理解することから始まる
- 「iPhone のスイッチを切り替えて消音モードにする」というのは、ユーザーが日常的に、かつまた手早くやりたいと望む、ごくありふれた操作。そのためサウンドのオン・オフ切り替えのトリガーは常時使用可能であり、どのアプリが起動されていても使える。
- 肝心なのは「いつ、どこで」というユーザーの要求にトリガーを一致させること

#### トリガーにより常に同じことが始まるようにする
- ユーザーが、マイクロインタラクションの役割に関して的確なメンタルモデルを構築できるようにするため
- iOS 6までのiPhoneやiPadのホームボタンは、押すとホーム画面に移動するが、すでにホーム画面にいる場合は検索画面に移動していた。iOS7からはホーム画面でホームボタンを押しても何も起こらなくなった

#### データを前面にだす
- マイクロインタラクション内部に含まれるデータをトリガーに反映する形で提示することも可能

#### 視覚的なシグニファイアを「破壊」しない
- トリガーの外見がボタンであれば、ボタンのように機能し、押すことができなければならない

#### マイクロインタラクションの使用頻度が高ければ高いほど、見つけやすいものでなければならない

#### 偽のシグニファイアが生成されないようにする
- 対象物がボタンのような外見であれば、ボタンのように動作しなければならない

#### トリガー自体では表せない情報を提供するときに限ってラベルを付加する
- 文字を追加するのではなく、ラベルの内容を視覚的に表せないか考えてみる
- iOSの設定「選択項目の読み上げ」では「ウサギとカメ」の寓話に基づいたアイコンラベルを用いて速度を表現している
- マイクロインタラクションのラベルは「独創性」を発揮する場所ではない
- Googleの「I'm Feeling Lucky」というボタンラベルはおもしろいが、ボタンを押したときに何が起こるか、「事前情報」をまったく提供していない

### 手動トリガーの構成要素
#### コントロール
- 単一のアクションに対しては、ひとつのボタンあるいは単純なジェスチャー
- ふたつの状態(たとえばオンとオフ)があるアクションには、「トグルスイッチ」(横あるいは縦に並んだふたつの状態のいずれかを選択する)
- 「トグルボタン」(押し込むと押下状態になり、もう一度押すと戻るような、ふたつの状態を切り替えられるボタン)を使うこともできるが、ボタンがどちらの状態にあるのか一見して判断するのが難しいことが多く、第3の状態があるのかどうかも判断がつきかねる
- 数個の状態が定義されているアクションでは、ダイヤルがよい
- 指定された範囲で連続量を指定するアクション(たとえば音量調節)には、スライダーやダイヤル(特にすばやく動かせる「ジョグダイヤル」)が最適

### 手動トリガーを見つけられるようにする
- ほとんどのユーザーが頻繁に利用するマイクロインタラクションは、すぐ見つけられなければならない。
- ある程度のユーザーがかなりの頻度で利用するマイクロインタラクションは、簡単に見つけられなければならない。
- あまり利用されないマイクロインタラクションは、探さなければ見つからないようにする。

#### そもそもどうやってものを見つけるのか
- その事物が動いたり音を立てたりすることによって、私たちの注意が無意識にそれに引きつけられる場合
- 私たちは動きや音に対して無意識に注意を向けてしまうので、トリガーを動かしたり音を出したりするのは、エラーや警告などの優先度の高いマイクロインタラクションに限るべき
- 目的をもって何かを探す場合
- 私たちが何かを探しているときは、視野が狭くなり「対象認識」のプロセスに入っている
- 対象認識を行うとき、私たちの目は「ジオン」と呼ばれる馴染みのある形状を探す
- ジオンは四角形、三角形、立方体、円柱といった単純な図形や立体で、 脳はジオンを組み合わせてその物体が何であるかを把握する
- このため、トリガー、特にアイコンのようなものには幾何図形を使うとよい

### 不可視トリガーは学習可能でなければならない
- ユーザーは、マイクロインタラクションを「偶然」見つけたり、他人やヘルプから学んだりすると、あとで記憶に頼ってそれを再現しようとする
- 不可視トリガーが「学習可能」であるためには、そうしたトリガーが(ほとんど)いつでも利用できる状態になっているか、あるいは逆に、特定のごく限られた条件下でのみ利用できるものでなければならない

### システムトリガー
- ユーザーが意識して操作しなくても、一定の条件が満たされると自動的に起動されるもの
- 実はユーザーが起動するものよりも「システムトリガー」のほうが起動される回数は多い
### システムトリガーのルール
- トリガーを起動する頻度はどれくらいか。
- ユーザー情報のうち、何が既知であるか。トリガーをより効果的でより楽しいものにし、よりユーザーに適合したものにするために、既知のユーザー情報をどう利用するか。(たとえば現在夜中だとわかっていれば、システムトリガーの起動頻度を下げることもできる)
- トリガーが起動されたことを示す表示はあるか。トリガーにより作業が開始された際に、目に見える状態の変化があるか。開始後はどうか。開始直前はどうか。
- システムエラーが起きるとどうなるか(たとえばネットワークの切断やデータの不足など)。中止するか、再試行するか。再試行するなら再試行までの間隔はどの程度にするか。

## ルール
- ユーザーはマイクロインタラクションのルールを知りたい
- 「iPhone事件」のX氏も、消音モードでも「オフ」にならないサウンドがあるということを、当然事前に知っておきたかったはず
- 昔の機械類とは違って、現代の機器を使うときにはトリガーが開始した動作が明示されないことも多い

## フィードバック
- どのようなソフトウェアや機器を使っているときでも、何が起きているのかを完全に知っている人はほとんどいない
- 「ファイルをフォルダに入れる」という操作は本当に「ファイル」を「フォルダ」に入れているわけではないし、メールの着信時にも本当に「郵便」が「郵便受け」に入るわけではない。
- 進行中のインタラクションに関するユーザーの理解を助けるメタファー
- 機器やアプリのルールに関するユーザーの理解を助ける視覚的、聴覚的、触覚的な要素がフィードバック
- 製品の個性を表現する上でトリガーは重要な役割を果たすが、さらに重要なのがフィードバック
- フィードバックは、製品全体の形態と並んで、製品の個性を決定づける要素だと言っても過言ではない

## ループとモード
- 各マイクロインタラクションのメタルール(ルールのルール)の役割
- 消音スイッチのように手動でオフにされるまでオンのままにしておくか、しばらくしたら終了するのか、あるいは中断している間はどうするか、条件が変わったらどうするかといったことを決めるのがループとモード

## ３つの手法
- マイクロインタラクションをベースにして、アプリやサービスを構築する手法には主に次の3種類がある
1: マイクロインタラクションをひとつひとつ個別に検討していく方法
2: ひとつのマイクロインタラクションを中心にしてひとつの製品を作り上げる方法
3: 多数のマイクロインタラクションをひとつのデジタル製品にまとめ上げる方法

#### 1. 個々を磨く
- プロジェクトを進めていく過程で、あるいは製品を改良する過程で、必要になりそうなマイクロインタラクションを見定めてリストアップし、ひとつひとつ検討していく
- うまくいけば比類のない記憶に残る瞬間(Signature Moments)を生み出せる可能性もゼロではない
- Facebook の「いいね!」ボタンのように、「記憶に残る瞬間」は、企業のブランドを確立したり、高い評価を得たりする上で非常に効果的

#### 2. ひとつのマイクロインタラクション=製品
- 複雑なアプリや機能になってしまいそうなものを複数のマイクロインタラクションに分け、そのひとつひとつについて、マイクロインタラクション を中心に据え、ひとつの製品を作り上げるというアプローチ
- 初代iPod, Instagram, Nestなど

#### 3. 多数をまとめ上げる
- アプリや機器は、数多くのマイクロインタラクションが協調して動作している結果であると見なす
- この方法には落とし穴もある
- マイクロインタラクショ ンに目を奪われていて全体像を見失う恐れがある
- 最終的に全体をまとめ上げたとき、すべての細部がぴたりとはまって一貫性のあるひとつの製品に仕上がるとはかぎらない
- ソフトウェアプロ ジェクトに「余裕たっぷりのスケジュール」はなく、クライアントは大きな機能や特徴に目を奪われやすく、細部にはあまり関心をもたない