コンテキストをデザインに落とし込む7つの切り口
リサーチをすれば、コンテキストも含め、それ以外の洞察を得ることができます。プロダクト戦略を練る時、サポートするデバイスを選ぶ時、コミュニケーションの手段を企画する時など、リサーチがいかに大切かが分かります。
リサーチから見つけた様々なコンテキスト上の情報や発見は、どのようにデザインに繋げば良いのでしょうか。
例えば、コンテキストを単純に分類しても、それはあくまで近似値にしかなり得ません。なぜなら、その分類結果は、コンテキストが溶け込んでわかりにくくなってしまっているから可能性が高いからです。
私は、コンテキストを7つの「切り口」で分類しました。これを使えば、コンテキストの重要性を理解することができるでしょう。
本記事は7つの切り口のうち、1つ目の「デバイス」について取り扱います。
切り口-1: デバイス
デバイスの形状と性能は、ユーザの使い方を形作り操作方法やスクリーン、その他の出力、ネットワーク接続性など、デバイスの特徴は個々の機能によって形作られます。しかし、ユーザのデバイスの選択は、どのようにデバイスの使用に関するコンテキストに影響を及ぼすのでしょうか。
デジタル時代は「形態は機能に従う」時代ではありません。スーパーコンピュータがチェスに取り組む一方で、スマートフォンはロケットを打ち上げられるくらいの処理能力を持っています。そうは言っても、デバイスの形状と機能の間にはまだいくらかの相関関係があります。例えば、スクリーンはデバイスの物理的形状と、それに伴うタスクを決定づけています。
1991年、ユビキタスコンピューティングの先駆者Mark Weiser氏はデジタルデバイスの3つの未来形を提示しました
「Tab」、「Pad」、「Board」(『The Computer for the Twenty-First Century』PDF, Scientific American, Vol. 265, No. 3. (1991), pp. 94-104)。
今日のデバイスは、この分類の中に明快に位置付けられます。スマートフォンとMP3プレイヤーは「Tab」。初期の小さな携帯用のデバイスの機能は限られたものでしたが、時間の経過とともに大きく拡張してきました。Weiser氏の言う「Pad」はノートPCとタブレット、「Board」は大きなデスクトップコンピュータやテレビを具現化したものです。

(Photo by adactio.)
写真: ADACTIO
Dan Saffer氏は、Weiser氏のデバイスのタイプの拡張版として、「Dot」(小さな、ほとんど目に見えないデバイス)、「Box」(トースターやステレオのような持ち運びを想定しないデバイス)、「Chest」(食器洗浄機のような大きく、重いデバイス)、そしてVehicleの追加を提案しました。(『Designing Devices』AMAZON, Saffer D, 2011.)
今となっては、形態は機能に従うのは一部だけに過ぎません。一昔前のネットに繋がる冷蔵庫などは、いわゆるインターネットバブル時代の安直なアイデアによる負の遺産です。
少し前の技術では「Dot」上でうまくWebブラウザを活用することはできませんでした。しかし、テクノロジーの急速な進歩によって、どんなデバイスの形状であっても、Webまたはアプリケーションにアクセスをすることが可能となりました。
もちろん、小型のデバイスではバッテリーの寿命や小さなスクリーンによる制限を受けるかもしれませんが、位置情報を活用するプロダクトや、日々の生活情報などを読み上げるプロダクトとしての利用することができると言うことは、容易に想像がつきます。最近の車にはWiFiのホットスポットと小型スクリーンが搭載してあります。
これから数年のうちに、インターネットや、IoTなどの製品は、予想だにしない場所で活躍することでしょう。デバイスの中には、特定の使い方に一層最適化された製品も登場するでしょうし、人々にとってより重要になるものもあるでしょう。しかし、全てはデジタルデザインに繋がっていくということを忘れてはいけません。
ソフトウェア・コンテキスト
オペレーティングシステム(OS)
デバイスのオペレーティングシステム(OS)は、それ自体がソフトウェアのコンテキストをある程度決定づけます。OSがどんな機能を提供するか考え、これらをプロダクトに統合する方法を探ってみてください。
例えば、ユーザーがスマートフォンでWebサイトを利用することが分かっている場合は、Webサイト上でリンクをクリックすれば、問い合わせをするための電話ができるようにするといったような簡単なことからです。
もし、あなたが必要としている機能が、ユーザーのOSに備わっていなかったらどうなるか考えてみてください。ファイル操作に制限があるデバイスに対する準備をしていただろうか。ブラウザのプラグインに依存フォーマットで、用意した動画は閲覧可能だろうか。などです。
OSの機能が邪魔をする可能性もあります。例えば、着信やシステムのアップデートとプッシュ通知は、ユーザをアプリから遠ざけるかもしれません。また、アプリを再度立ち上げた時、ユーザ自身が何をしていたか思い出す助けとなる方法を探してみてください。そして、データが失われるリスクを考えてみてください。一定時間放置しているとログアウトされてしまうようなアプリにとって長い通話というのは痛手となります。
どのOSにも多くのUIのルールが積み込まれています。そのため主要なOSのインターフェースガイドラインを理解し、ネイティブアプリケーションを各デバイスの確立したルールに合わせる必要が出てくるでしょう。
Webデザイン
Webデザインの場合には、ネイティブのルールよりもWebのルールを優先させます。1つのプラットフォームのルールに従うということは、他のプラットフォームのルールから遠ざかることになることもあるのです。たった1つのOS上で動作するWebアプリはほとんどありません。あなたのプロダクトのユーザ層が特定のOSに限られていたとしても、OSをアップデートする習慣はユーザによって異なるため、ある特定のOSにフォーカスするのは危険です。
Webアプリに対して、ネイティブデザインのルールを再現することは並々ならぬ努力が必要となります。インタラクションデザインパターン(トランジション、タイミングと挙動など)は、リバースエンジニアリングや模倣には向きません。これはコードを肥大化させ、OSが変わった時は常に対応する必要が出てきます。
特定のデバイスに最適化されたWebアプリを作りたい、という衝動は理解できますが、破滅的にもなります。ネイティブデザインが重要だと感じたら、ネイティブアプリを構築してみてください。Webアプリは、プラットフォーム的に中立でなければなりません。Webの多様性こそが、Webの特徴だからです。
Webアプリ
Webアプリを作る際、ユーザのOSとブラウザ情報が分かると役に立ちます。それらはUser-Agent(UA)を通して、ブラウザの種類とバージョン、OS名とバージョン、使われているデフォルト言語といった他の情報を特定します。この情報はある程度役に立ちますが、UAは完全ではなく、なりすましが簡単なので、ユーザーエージェントスニッフィングの信頼性はないと言えます。
仮に、UAに頼ることができたとしても、バージョン番号から正確にブラウザやOSの機能を読み取るような方法はありません。UAを補うための技術的な方法としてはクライアント側とサーバ側の技術の合わせたものがあります。
基本的な特徴を学ぶためにWURFLや、JavaScriptを使用したブラウザ側の機能探知があります。JavaScriptのライブラリ「Modernizr」は、ユーザーのブラウザがタッチイベントやローカルストレージ、CSSバージョンをサポートしているかどうかを教えてくれます。cookieをユーザーに渡すことで、次のセッションからサポートしている機能の速度を上げることができます。
それら全ての利点をもってしても、技術的な解決方法というのはWebサイトに訪れる顧客やデバイスに対する深い知識に取って代わるものでは決してありません。今日におけるリサーチ(洞察の用途)を無視しないようにしましょう。
正しくデバイスコンテキストを理解するために、UXデザイナーは新しいハードウェアとソフトウェアをに関する知識を常に最新にし続けておかなければなりませんし、また新しいトレンドにもアンテナを伸ばしておかなければなりません。
デバイスコンテキストを理解するポイント
- プロダクトに使われているデバイスは何でしょうか
- 1年後はどうか。3年後、5年後はどうでしょうか
- そうしたデバイスにできること、できないことは何でしょうか
- このようなデバイスにはどのようなインタラクションが最適でしょうか
- 強みを生かすことができるデバイス固有の機能があるでしょうか
- 私たちのプロダクトが必要とする機能を持ち合わせていないデバイスはどのようにすべきでしょうか
- プロダクトを使いづらくしてしまうデバイス固有の機能があるでしょうか。もしあるとしたら、どのようにしてその影響を減らすことができるでしょうか
切り口-2: 環境に続きます。
本記事は、2013年に記載されたケニー・ボールズによるコンテキストの紹介記事を翻訳したものです。
SOURCE
