UX Blog
UXデザインの国内外の最新動向をお伝えすると共に、弊社内の日々の業務や勉強会/イベント等で得た学びや、考察したことについて共有して参ります。当Blogの更新情報は、Twitter経由でも配信しています。興味のある方はぜひ、@mlc_uxをフォローしてください。当Blogへのご意見・ご質問は、Twitter経由でも受け付けております。
2014年8月4日
Blog移転のお知らせ
誠に勝手ながら、このたび当UX Blogを移転することになりましたので、お知らせいたします。移転先のURLは
http://www.mitsue.co.jp/knowledge/blog/ux/
になります。大変恐れ入りますが、ブックマークやフィードリーダーなどの設定変更をお願いいたします。
なお、旧URL（http://ux.mitsue.co.jp/）は今後もご利用いただけますが、新規の記事は投稿されませんので、ご注意下さい。
今後ともUX Blogをよろしくお願いいたします。
2014年3月6日
プロトタイプを活用して、利用体験をわかりやすく共有しよう
インタラクションデザイナーの橋本です。今回はアプリケーションをデザインする際の、プロトタイプの活用のしどころとプロトタイプの種類と使い分けについて紹介します。
プロトタイプの活用のしどころ
先日、FacebookからiPhone用のニュースリーダーアプリPaperが米国向けにリリースされました。
雑誌を流し読むように投稿やニュースにざっと目を通しつつ、気になったものは新聞を広げるようにして続きを読む...そんな使い方が、手のかかったなめらかな動きで実現されています。*
しかし、こうしたインターフェイスも、当然ながら最初は発案者の頭の中にしかなかったものです。こうした動きのある製品を作ろうとするとき、私たちはインターフェイスのイメージをプロジェクト関係者にどうやって共有していけばよいのでしょうか？
画面イメージを伝える際にはワイヤーフレームがよく使われますが、このような動きのない静的なドキュメントでは、実際にアプリがどのように使えるのか想像しづらいでしょう。そのため、動きをつけたプロトタイプでデザインした画面を共有していくことが効果的です。
例として、私が作成したプロトタイプ（を操作している様子を動画で）以下にご紹介します。
- 電子書籍アプリのプロトタイプ
- ECサイトのプロトタイプ
いかがでしょうか。文書で説明されるときと比べ、グッと内容がわかりやすくなったのではないでしょうか。このような動きをつけた詳細なプロトタイプは共有のために有用ではありますが、静的な文書と比べるとコストが掛かってしまいます。
プロトタイプには詳細度や作成コストによっていくつかの種類に分けられるのですが、それらを適材適所で使い分けていくことで、費用対効果を最大限あげることができるでしょう。
プロトタイプの種類と使い分け
プロトタイプは大きく、以下の種類に分けられます。
- 手書きのプロトタイプ
- 紙やホワイトボードにペンで書いて作ったアナログなプロトタイプ
- イメージマッププロトタイプ
- 画面イメージをリンクで紙芝居のようにつなげたプロトタイプ
- 詳細なプロトタイプ
- 実際の動きにある程度近いプロトタイプ
プロジェクトのフェーズによって最適なプロトタイプは異なります。
プロジェクト初期では共有の精度より、様々なデザインの選択肢を洗い出し最適なものを見つけることがより重要になりますから、なるべくコストの低いプロトタイピングが求められるでしょう。
その点では、紙やホワイトボード上に手書きで画面内容を書いて検討していく（ペーパープロトタイプ）ほうが、多くのパターンが検討できますし、レビューする側も完成度が低いためかえってフィードバックしやすいというメリットがあります（完成度が高いと、出来上がった感じがしまい、コメントがあまり出なくなると経験的に感じています）
ある程度進んだ段階で、実際の利用体験に近いものへと詳細なプロトタイプを利用していくとよいでしょう。
プロトタイピングツール
最後に、デザインの現場で役立ちそうなプロトタイピングツールをいくつかご紹介いたします。
POP
POPはスマートフォン用アプリです。
ペーパープロトタイプをカメラで撮影し、アプリ上でリンクを設定していくことで、手書きの動くプロトタイプが作成できます。プロジェクト初期に作成したペーパープロトタイプをテストしてみる際に便利です。ただし、対象がスマートフォンのアプリに限られる点は注意です（PC未対応、スクロール不可のため）
InVision
InVisionはブラウザで使えるウェブサービスで、POPに似ていますが、PC・スマートフォン、どちらのプロトタイプも作成できます。
POPがカメラで撮影した画像を動くプロトタイプにするのに対し、InVisionはデザインした画面の画像をアップロードしてプロトタイプにしていきます。ですので、InVisionはビジュアルデザインが出来てくるあたりで役立つでしょう。
Axure RP
POPやInVisionは気軽に導入できますが、一方で設定できる動きには限界があります。
リッチアプリケーションなどインタラクティブな製品のプロトタイプを作成する場合はAxureが良いでしょう。Axureはかなり高機能なソフトウェアで、画面の非同期での書き換えやUI部品固定などが実現できる数少ないソフトです。上記で掲載した動画（私が作成したプロトタイプ）もこのAxureで作成しています。
なお、AxureはPOPやInVisionと違い、UIパーツをキャンバスにドラッグアンドドロップしながらプロトタイプを作成するツールです（PC/Mac対応）
* 幾つかのユーザビリティ問題は抱えていますが・・
2013年12月27日
【海外記事紹介：下】Overhauling a UI without Upsetting Current User
こんにちは。インタラクションデザイナーの奈須です。
前回の記事に引き続き、「Overhauling a UI without Upsetting Current User」（現行のユーザーを混乱させずに、UIを組み直す方法）をご紹介します。
今回は、「終わりの見えない「UIの議論」はやめましょう」以降の章をご紹介をしたいと思います。
以下、翻訳記事本文となります。
（この記事はUX Magazineにおける投稿記事「Overhauling a UI without Upsetting Current User」を翻訳したも
のです。当Blogは翻訳の正確性を保証いたしませんので、必要に応じ原文を参照ください。）
終わりの見えない「UIに関する議論」はやめましょう
しかし、良質なユーザーリサーチに取り組んでいても、まだ多くのプロジェクトが非生産的な、デザインや実装の議論から抜け出せなくなっています。これを避けるために、デザインチームや開発チームは、もっとも大切である「製品の方針」へ立ち返りましょう。もし特定の画面や機能について議論が起こった時は、以下の事項を確認しなおし、議論をストップしましょう。
- なぜユーザーはこの機能を使いたいと思うのか？
- 何がユーザーにとって一番一般的な作業なのか？
- どんな状況、文脈でその機能は使われるのか？
- どういったユーザーがこの機能を一番必要とするのか？
これらの事項に関して、すべてのチームメンバーがこれらの事項を思い出し、確認する時間を少し取ることで無駄な議論を避け、プロジェクトの完了までのスピードを上げる事ができます。もしこれをしなければ、きっと同じ論争が何度も何度もデザインと開発のプロセスの中で浮上してくるでしょう。
チームで議論を進めて行く中で、頻繁に「ある種の機能を含めるか？」という議論が起こります。ここで、実際その議論の根本にあるのは「我々の製品の主なユーザーは誰で、彼らは何に価値を置くのか？」という事です。既にチームでその事について考慮できていれば、機能をどう決めて行くかは明白であるので、開発チームはこれらの問題に対する議論が容易に行えるでしょう。
デザイン改修に向けてのフィードバックの統合：解釈と優先順位付けの実施
「何にも引けをとらない製品」と言われるものでも完璧ではありませんし、普遍的に、誰にでも受け入れられるわけではありません。ユーザーは常に何かしらデザインに対して不満を持つものなのです。そのため、ユーザーのUIに対する不満（常にいくつかは必ず存在するものです）を処理する際、問題を早く収束させるためだけに、不満を額面通り受け取ったり、条件反射的に対応してはいけません。
ベテランのプロダクトマネージャーやUXデザイナーは、
- それぞれの問題が、どれくらいの頻度で発生しているのか
- ある問題の、あるユーザーへのインパクト
- それぞれの問題の、相対的な重要度
...等を決定するため、様々なユーザーから質的なデータと量的なデータを収集する時間を取るものです。このデータ・分析は、関係が希薄で、気をそらすような問題は脇に置いておき、製品の成功に最も影響がある問題（究極的にはビジネスの成功に影響がある問題）にチームが迅速に取り組むために、ユーザーのすべての反応を理解する助けになります。
その不満はどれくらいのユーザーが抱いているのか？
いくつかの不平不満から、一般的なユーザーの問題を見つける事ができることもありますが、ただ単に『母数は少ないが、声の大きいユーザーグループ』の不平不満である場合もあります。
この場合、定量データが大変役に立ちます。GoogleがGmailのUIを改修した際、画面の隅にユーザーに新しいデザインに対するフィードバックを求めるポップアップバーを配置しました。
これは、どれくらいデザイン上の課題が広がっているのかを測る時にとても効果的な仕組みですし、おまけに、不満を直接ソフトウェアメーカーに聞いてもらう事でユーザーに自分がUIの決定に影響力がある、という意識を与えることができます。しかしながら、この手法は様々な種類の意見を分類する際、手間がかかります。提供されるデータの質もそれほど高くありません。なぜなら、ユーザーは時に不満の背景をきちんと説明せず、解決案だけを提案してきたりするからです。
より効率が良く、かつ強力なデータ収集を行いたければ、ターゲットユーザーへのランダムな調査（具体的にはユーザーインタビューやエスノグラフィ―調査）を行いましょう。これはユーザーの不満が一般的なものであり、今すぐに取り組むべき問題なのか、もしくは一般的ではない問題で優先度の低いものなのかを見極めるために必要なフィードバックの量と質をもたらしてくれます。
変更しない事のリスクを考えましょう
デザインのアップデートを行うことはコストが大きく、また、もしもアップデートがユーザーの批判を引き起こしてしまうと、よりコストがかかります。「悪いUIを作ることで、ユーザーからの信用を損う事態」を避けるため、現状のまま保ったり保守的なアプローチを行うことは魅力的でしょう。しかし、iPadやsalesForse.comのような製品によって、ソフトウェアのユーザー体験の新しい基準が作り上げられました。それらによって高くなっていくユーザーの期待に応えるため、企業はUIのアップデートを行わざるを得ません。
幸運にも私達は、ユーザーを混乱させずにUIの改善を行うことができます。適切なUX手法と製品管理はロイヤルユーザーを失うことなく、時代に合った、新しいUIを確実に生み出すことができるでしょう。
ユーザー調査を行い、データを集めること・解釈すること・優先順位付けすることが、良いUXデザインの基礎なのです。これらは企業が市場の中で勝者であり続けるために、組織の中で高めなければならない、核となる能力なのです。
関連サービス
ミツエーリンクスではよりよいUXの実現のため、各種UX,UI関連サービスをご提供しています。
2013年12月4日
【海外記事紹介：上】Overhauling a UI without Upsetting Current User
こんにちは。インタラクションデザイナーの奈須です。
今回から2回に分けて、UI改修に関する海外の記事をご紹介したいと思います。
ご紹介するのは、UX Magazineで紹介されていた、「Overhauling a UI without Upsetting Current User」（現行のユーザーを混乱させずに、UIを組み直す方法）という記事です。タイトルの通り、UIの改修を行う際の障害は何か、どういう手法を使っていけばいいのかを紹介している記事です。内容は大きく以下の3つの章で構成されています。
- 見た目と機能を良く考えよう
- デザイン改修は根拠に基づいて行おう
- 終わりの見えない「UIの議論」はやめましょう
UIデザインの参考になればと思い、UXブログでご紹介したいと思います。長いので、今回は、
- 見た目と機能を良く考えよう
- デザイン改修は根拠に基づいて行おう
までの章の内容をご紹介します。以下、翻訳記事本文となります。
（この記事はUX Magazineにおける投稿記事「Overhauling a UI without Upsetting Current User」を翻訳したも
のです。当Blogは翻訳の正確性を保証いたしませんので、必要に応じ原文を参照ください。）
現行のユーザーを混乱させずに、UIを組み直す方法
素晴らしいソフトウェア製品を持つ会社は、UI改善を行う必要を分かっていても、「UI変更によって、既存のユーザーが困惑してしまう」との懸念から、UI変更をためらうことがあります。ある会社の重役の方は、Macadamian社（注：この記事の筆者が勤める会社）に対して、以下のように発言しています。
「グーグルやFacebookのUI改修に対する、カスタマーからの反発を見るべきです。私はデザインの変更でカスタマーを失うリスクを、軽々しく冒したくありません。」
確かに、GoogleやTwitter , FacebookはUIの大きな変更を行いました。GmailのUI改修に対しては、「ユーザーの生産性を取り戻すため、UIを旧バージョンに元に戻すように働きかける」ため、UI変更後24時間以内には何百人ものユーザーが「新GmailのUIへの反対同盟」を結成しましたし、Facebookでは「問題がある訳じゃないなら、UIを変更しないで！」というような、UI変更への不満を表現するバナーが投稿されたりしました。
しかし、このように上手く行かなかった改修例もありますが、デザインを改修する事によって、競合を大きく出し抜き、成功した会社の例もあります。例えば、Salesforce.comがCRM（顧客関係管理）市場で優位なのは、その革新的なデザイン改修によるところが大きいのです。
外見と機能を良く考えよう
「経験」の価値の9割は見た目(How it looks)ではなく、どのように動作するか(How it works)によります。もちろん、ビジュアルデザインが重要でないということではありません。ただ、それだけでは不十分なのです。
とあるツイッタ―ユーザーは、新しいGmailのインターフェースが不評だった主な理由について、
「Gmailの新しいUIは機能よりも見た目重視に改修しすぎたのです。Gmailがみんなに使われていたのは、機能が良かったからだと言うのに。」と言い、「使ってみるまでは新しいGmailはスッキリしていて良く思えるけど、使い始めると使いにくいので、ユーザーは気を付けるべき。」とも発言しています。
通説として、非デザイナーは、「素晴らしい体験や製品の成功はビジュアル的な価値に依存する」と考えていると言えるでしょう。UXの専門家は、ビジュアルは「体験」を形作る１要素であると認識していますが、時にビジュアルデザインには、ユーザー体験の他の側面に使う時間を犠牲にして、不釣り合いなほど多くの時間が費やされます。素晴らしい見た目（ビジュアル）は、最初に製品に引きつけるためには重要度が高く、またビジュアルデザインは購入の意思決定をする際に非常に重要な要因でしょう。しかし、製品が市場において支持されるためには、製品の見た目ではないところに重点を置いて開発する必要があります。これは、ソーシャルメディアを通じ、予測できないほど早いスピードで製品に関する情報や意見が飛び交う社会において、特筆すべき真理である、と言えるでしょう。
デザインの改修において、見た目を改善したものの、「新しい価値」を提供する事に失敗した場合、新しいユーザーをガッカリさせるだけでは済みません。改修する以前は満足していたユーザーをも遠ざけ、さらに、こういった「失敗」のニュースは瞬く間に拡散します。「見た目の美しさは、ユーザーの実際の経験と等しい」というような間違った考えを持つのはやめましょう。
デザイン改修は根拠に基づいて行おう
単に見た目を美しくするためでなく、機能的な改善を行うため、プロダクトマネージャーと、デザインチームはリアルなユーザーを調査しなくてはなりません。多くの人は、この原則について既に知っているでしょうが、どうやって実行するかによって大きく異なってきます。
企業が一般的にもっともやりがちなミスのうちの1つは、ユーザーが欲しいと言っているものに基づいてUIの改修を行うことです。不幸な事に、実際の経験は、ユーザーが「すると思う」とか、「好きじゃないと思う」とか言ったことが、現実の行動と合致していないと言う事が散見されます。さらに、どうやって「UIを改善するのか」に関するユーザーの提案は、非合理的なものだったり、実行不可能なものだったり、さらにその両方だったりします。
ユーザーにフィードバックを依頼し、またそれを聞くことは大切なことである一方、ユーザーはデザイナーやユーザビリティエンジニアではないので、彼らの不満や提案はそのまま捉えるべきではありません。デザイン解と、デザイン提案を混同してはいけないのです。本当のUIの問題と解決策を見つけるために、「意見」だけでなく、「事実」も考慮した注意深いUXリサーチを行わなくてはなりません。
どんなUI改修でも使える基本的なテクニックとしては、フォーカスグループとユーザビリティテストが挙げられるでしょう。
フォーカスグループ
フォーカスグループは、新しい、もしくは既に存在する製品、アイデアについて、ターゲットユーザーの豊富な意見や態度を知る事ができる、強力な調査手法です。デザインの改修プロジェクトの早い段階での評価・調査として、フォーカスグループを行うのが最も良いでしょう。
開発の初期段階やデザイン改修の評価段階で、以下の事を見つけるためにフォーカスグループを行うともっとも効果的です。
- インターフェースの様々な側面に対する、意見の幅広さを感じとる
- ユーザーの「好み」にある背景、新しいUIに対するアイデア、UI変更のリクエストなど、なぜそういう意見が出たのかを理解する
- ユーザーのありのままの欲求をリスト化する
こういった情報は、プロジェクトの早い段階における方向性を、開発チームに与えてくれます。だからこそチームは開発の準備ができ、さらに重要な部分の開発をデザイン設計と並行し、早めに取り掛かることができます。
しかしながら、フォーカスグループは行動データを得る方法としてはあまり適していません。ユーザーが「きっとやると思う」と言う事は、彼らが実際に行う行動と比較すると非常に信用できません。それにはいくつか理由があります。1つめに、ユーザーが「きっとやると思う」と言う事と、ユーザーの実際の行動・態度は度々違うことがあります。人々はある状況下で、文脈的な要因が彼らの行動をどのように変える可能性があるかについて予測することができないのです。これが、車の試乗や30日間返品可能システムが好まれる理由でしょう。
２つめに、人々は自分自身の行動すべてに気を配りきれていません。毎日の習慣などは当たり前すぎて、やっている事すら忘れてしまうことがあります。例えば誰かに「電話のどんな機能を使っていますか？また、大体どの位の頻度ですか？」のような単純な質問をしたとします。質問への答えは、実際に調査したデータと比べるとびっくりするほど違っていたりします。
こういったところで、ユーザビリティテストなどの調査手法が活きてきます。
ユーザビリティテスト
ユーザビリティテストは、あらかじめ決められた一連のソフトウェア上のタスクを、ユーザーに実行してもらい、それらを調査・評価する事を通して、どんなデザインが有効か、見つけ出していくテクニックです。ユーザーが皆同様にワークフローの中の特定の部分でつまづくようであれば、それはデザインに不備があるという強い兆候です。
リサーチャーはインタビューを行ったり、体験したことについてのより質的な質問を行いながら、ユーザビリティテストの各セッションを遂行していきます。ユーザビリティ指標、たとえばタスク完了までの時間や、エラーの数、クリック数、成功率などは「使いやすい度合」と同時に収集/測定されます。
ユーザビリティテストは、βテストとは全く違ったものです。βテストでは、ユーザーは一般的にタスクを実行する事を非常に困難にするようなユーザビリティ問題、つまり明確なバグのみをレポートします。基本的に、「直観的でない」という問題や「実行する際に困難である」というような問題を見つけてもレポートしないでしょう。人は基本的に、自分のミスした点を認めるのを好みませんし、βテスター（もしくは、少なくとも1度は問題をレポートした事のある人）は、時に製品のファンであり、パワーユーザーであります。彼らはすでに、ユーザビリティ上の問題を回避したり、無視したりする事を学んでしまっているかもしれないのです。
ユーザビリティ上の問題（もしくは、その問題に関するバグ）を解決するにあたり、最もコストがかかる時期は「製品が完成した後」です。できるだけ製品がβ版になるまでに、明確なユーザビリティ問題は解決されているべきです。
次回、最後の章：終わりの見えない「UIの議論」はやめましょう をご紹介したいと思います。
関連サービス
ミツエーリンクスではよりよいUXの実現のため、各種UX,UI関連サービスをご提供しています。
2013年9月27日
【海外UXイベント紹介】UX Masterclass (プラハ & ローマ)
UX alliance が主催する「UX Masterclass」が、プラハ(10月2日)とローマ(10月4日)で開催されます。
今回で8回目となる UX Masterclass には、当社UX本部のInternational UX Business ManagerであるFrancis Fungが「Why mobile experience & design will be different between East and West」のテーマで登壇いたします。
世界に広がるUX専門家の国際的なネットワークを通して、最新のトレンドや各国で特色のある内容が紹介されます。本UX Blogでも、面白そうなトピックを取り上げてご紹介してまいります。
2013年8月21日
「ソフトウェア品質のホンネ」：利用者視点でシステムに魂を吹き込む
SQiP (Software Quality Profession) [スキップ] と言うソフトウェア品質の研究・普及活動を行っている団体のウェブサイトで、「ソフトウェア品質のホンネ」と言うコラム記事のコーナーがあります。
以前もUX関連の記事を執筆しましたが、今回、
とのタイトルで、システム開発者に対して、UXデザインに取り組むことをアピールする記事を書きました。
上記記事中でもご紹介していますが、SQiP特別講演会でUXデザインの体験セミナーを開催いたします。
お一人でもご参加いただける半日のワークショップです。ご興味がある方は、ぜひお申し込みください。
2013年7月18日
iOSは「フラット」になっただけではない（後編）
iOS7のデザインの方向性について、前回は「コンテンツに一段とフォーカスする」という話をしました。
続いて『「見て理解する」から「触って理解する」へ』ですが、これはどういうことでしょうか？今回もアプリを見ながらご説明します。
カレンダーアプリ―紙カレンダーの模倣からの脱却
（iOS7版カレンダーの画像はアップル社のサイトでご確認ください）
紙のカレンダーを見ていて、例えば今月下旬と来月上旬を同時にみたいと思ったことはありませんか？紙のカレンダーは1ヶ月毎に用紙が別になっており、同時に見づらくなっています（それを考慮して前月/次月を小さく記載しているカレンダーもありますね）。
従来のカレンダーアプリは、紙のカレンダーのように1ヶ月単位で区切られた、不連続な表示になっていました。iOS7版ではこの月毎の区切りを取っ払い、縦スクロールで自由に行き来できる連続的な表示になりました。これにより、月の区切りに縛られず、今月下旬と来月上旬をあわせて見やすくなっています。
紙のカレンダーに沿うと使い方はわかりやすくはなるものの、一方でその物理的特質による制約を受けることで、本来やりたかったことが行いづらくなる、デジタル環境ならではの良さを損ねてしまう、という問題が起きていたと言えます。実物という足枷を外すことで、デジタルアプリケーションとしての可能性を引き出したといえるでしょう。*註
メタファーとイディオム
ソフトウェア開発者/デザイナーであり、デジタル機器のUIデザインに詳しいアラン・クーパー氏は、その著書の中で上記観点について考察を行っています。
彼はインターフェースのコンセプトとして「メタファ的」「イディオム的」があることを指摘しています。
まず、メタファ的なインターフェースについては、
メタファー的なインターフェイスはインターフェイスに含まれているビジュアルな手がかりとその機能をユーザーが直観的に結びつけてくれることを頼りとする方法である。ソフトウェアの仕組みを理解する必要がないという分、実装中心インターフェイスからは一歩前進しているが、その力と便利さは実際以上に評価されている。
Alan Cooper「About Face 3 インタラクションデザインの極意」P.277より
と指摘し、その弱点をいくつか説明しています。
メタファに厳密に従うようなことをすると、インターフェイスが現実の世界の仕組みに不要に縛られる事になってしまう。現実の3次元空間は乱雑で、物理的な動きには限界があるが、デジタル製品の最も素晴らしい点は、そのようなものでユーザに提示する動作モデルを縛らなくて済むことではないだろうか。（同著P.275より）
メタファは初めて使うユーザの学習という点では小さな効果があるが、初心者が中級者になった後は高くつく。ほとんどのメタファは、物理的な世界のメカニズムを反映しているので、ユーザのコンセプトを地面にしっかりと釘付けにしてしまうが、その分ソフトウェアの力が制限されてしまうのだ。（同著P.278より）
プリンタやドキュメントのような物理オブジェクトのビジュアルメタファは簡単に見つかるかもしれないが、プロセス、関係、サービス、変換など、ソフトウェアでもっともよく使われるものを表すメタファを見つけるのは難しいし、ひょっとすると不可能かもしれない。（同著P.282より）
まとめると、
- 現実世界の物理的な制約に不要に縛られることになってしまう
- 最初はよいが、慣れた後は作業の妨げとなってしまう恐れがある
- 現実に都合の良いメタファーがあるとは限らない
というところですね。
そこで、彼は「イディオム」を持ち出します。
回りくどい言い方をすることを「beat around the bush」（藪のまわりを叩く）といったり、かっこいいということを「cool」といったりするのをイディオム（熟語）と呼ぶが、イディオム的なデザインは、私たちがイディオムを学んで使うメカニズムを基礎としている。
（中略）
比喩的ではない単純なビジュアルおよび振る舞いのイディオムを学習して仕事を完成させ、ゴールを達成しようというものだ。（同著P.279より）
イディオムは、PCで言えばマウスによるウィンドウの最小化/最大化やウィンドウのスクロールなどが該当します。つまり、メタファとは違い、現実世界には対応するものが存在しないインターフェイスであり、最初はよくわからないけれど、学習して覚えてみると以後忘れずに使えるインターフェイスのことです。
メタファ的インターフェイスは、現実で対応するものを学習していれば、見ればすぐに使い方がわかります。そこでは現実の"模写"の精度が求められるでしょう。
イディオムについてもっとも大切なことは、イディオムには学習が必要だが、その学習はおそろしく簡単であり、優れたイディオムなら一度学習するだけで十分だということだ。（同著P.280より）
こう述べるように、イディオム的インターフェイスで求められるのは、学習しやすさと言えるでしょう。現実を模倣しない訳ですから、一見しての分かりやすさよりも使ってみての分かりやすさをいかに高めるかが鍵となります。とすると、見た目という静的な側面ではなく、動的な側面（操作体系や動き、フィードバック）のデザインがより重要となります。
- 参考/関連記事
- 人との関わりから考えるタッチUIのあり方 - could
- この記事では、より広い視野から静止状態（スクリーンショット）だけでは UI の評価が難しくなってきたことを指摘しています。
メタファーからイディオムへ
iOS6⇒iOS7はこうしたメタファーからイディオムへのインターフェイスの方向性の転換と見ることも出来るでしょう。
しかし、「一見しただけで使い方がわかったほうが初心者にも優しいし、そちらのほうがいいじゃないか」、そう感じる方もいるかと思います。
ただ、デジタルネイティブという言葉に象徴されるように、コンピュータという存在がどんどん身近になってきています。文字通り、スマートフォンを肌身離さず持っている人もいるでしょう。そして、そんな人にとって初めて手に取るスケジューラは紙の手帳ではないかもしれません。
その時に、紙の手帳を模したスケジューラと、使ってみると手に馴染むスマートフォンに適したスケジューラ、どちらを初めに手にとってもらうのが良いでしょうか？学習コストが同じであれば、機器のポテンシャルを最大限に引き出した後者のインターフェイスの方が好ましいと言えるのではないでしょうか。そう考えると、こうしたインターフェイスの方向性の転換は、長期的には正しいと言えるのかもしれません。
iOSは「フラット」になっただけではなく、こうした2種のデザイン変更によって、デジタルインタフェースデザインの可能性を追求しているのではと考えています。
- *註：iOS6のアプリのデザインを批判しているわけではなく、むしろ、世の中の人がフリックなどタッチ操作に慣れていない黎明期においては、それに慣れてもらうために一定の意義があったと思います。また、iOS7のカレンダーも完全に良いと言っているわけではなく、予定内容がわからないなど課題と感じる点は色々あります
関連サービス
ミツエーリンクスではよりよいUXの実現のため、各種UX,UI関連サービスをご提供しています。