デバイスの多様化によって必要となる視点 — コンテキストを理解する(2)

Source

デジタルプロダクトデザイナー/リーダー
Twitterデザインマネージャー
Clearleftエクスペリエンスデザイナー

テクノロジーの進化に伴い、インターネットユーザーを取り巻くコンテキストも変化し、明確に定義することは難しくなってきた。現代のデスクトップ/モバイル・コンテキストの落とし穴から、コンテキストを正しく理解するための切り口について考える。(連載第2回)

連載「コンテキストを理解する」
第1回: コンテキストの落とし穴
第2回: デバイスの多様化によって必要となる視点
第3回: 環境からデザインを逆算する
第4回: 時間軸の中で必要とされるものとは?
第5回: 受動的か能動的かを意識して体験を考える
第6回: 個別最適に、パーソナルスペースを考慮しているか?
第7回: 場所情報を用いるリスク
第8回: ユーザーの周りにも人がいることを意識する
最終回: コンテキスト・デザインの5原則

コンテキストをデザインに落とし込む7つの切り口

リサーチをすれば、単なるコンテキスト以上の洞察が得られる。プロダクト戦略を練る時、サポートするデバイスを選ぶ時、コミュニケーションの手段を企画する時など、いかにリサーチが大切かが分かるはずだ。

しかしせっかく見つけた様々な種類のコンテキスト上の情報や発見は、どのようにデザインに繋げば良いだろうか。当然ながら、コンテキストをいかに分類しても近似値でしかない。カテゴリは溶け合わざるを得ないからだ。しかし次に示すコンテキストの7つの「切り口」が重要な面を網羅しているので、コンテキストの重要性を自信を持って説明できるはずだ。

切り口-1: デバイス
切り口-2: 環境
切り口-3: 時間
切り口-4: 行動
切り口-5: 個性
切り口-6: 場所
切り口-7: ソーシャル

本記事では7つの切り口のうちの1つ、「デバイス」について取り扱う

切り口-1: デバイス

デバイスの形状と性能がユーザのアプローチを形作る。操作方法、スクリーン、その他の出力、ネットワーク接続性など、デバイスの特徴はそれぞれの個々の機能によって形作られる。しかし、ユーザのデバイスの選択はどのように使用のコンテキストに影響するのだろうか。

デジタル時代は、「形状が機能に従う」時代ではない。スーパーコンピュータがチェスに取り組む一方で、スマートフォンはロケットを打ち上げられるくらいの処理能力を持っている。それでも、デバイスの形状と潜在的な能力の間にはまだいくらかの相関関係がある。例えばスクリーンはデバイスの物理的形状と、それに伴うタスクを決定づけている。

1991年、ユビキタスコンピューティングの先駆者Mark Weiser氏はデジタルデバイスの3つの未来形を提示した。Tab、Pad、Boardだ(The Computer for the Twenty-First Century』, Scientific American, Vol. 265, No. 3. (1991), pp. 94-104)。今日のデバイスはこの分類の中に明快に位置付けられる。スマートフォンとMP3プレイヤーはTab。元来小さな携帯デバイスの機能は限られているが、時間軸で見ると大きく拡張してきた。ノートPCとタブレットはWeiser氏が述べるPad、大きなデスクトップコンピュータやテレビはBoardの具現化したものだ。

(Photo by adactio.)
写真: ADACTIO

最近、Dan Saffer氏が、Weiser氏のデバイスのタイプの拡張版として、Dot(小さな、ほとんど目に見えないデバイス)、Box(トースターやステレオのような持ち運びを想定しないデバイス)、Chest(食器洗浄機のような大きく、重いデバイス)、そしてVehicleの追加を提案した(『Designing Devices』, Saffer D, 2011.)。

今となっては、形状が機能に従っているのは一部だけに過ぎない。一昔前のネットにつながる冷蔵庫などは、インターネットバブル時代の安直なアイデアによる負の遺産だ。私たちはDot上でうまくWebブラウザを活用することはできなかったのだ。しかしテクノロジーの急速な進歩によって、どんなデバイスの形状であっても、Webまたはアプリアクセスを提供することが可能となった。小型のデバイスではバッテリーの寿命と小型スクリーンによる制限を受けるかもしれない。しかし位置情報を活用するプロダクトや、日々の生活情報などを読み上げる携帯式プロダクトとしての利用は容易に想像がつく。最近の車にはWiFiのホットスポットと備え付けの小型スクリーンが搭載してある。これから数年のうちに、インターネットや、IoTなどの製品は、予想だにしない場所で活躍するだろう。デバイスの中には、特定のタスクにより最適化された製品も登場するだろうし、人々にとってより重要になるものも、そうでないものもあるだろう。しかし全てはデジタルデザインに関連することを忘れてはいけない。

ソフトウェア・コンテキスト

デバイスのオペレーティングシステムは、それ自体がソフトウェアコンテキストをある程度決定づける。OSがどんな機能を提供するか考え、これらをあなたのプロダクトに統合する方法を探ってみてほしい。例えば、ユーザーがスマートフォンであなたのWebサイトを利用することが分かっている場合は、Webサイト上でリンクをクリックすれば電話ができるようにすればいい。

OSによって必要とする機能がなかったとしたら、どうなるか考えてほしい。ファイル操作に制限があるデバイスに対する備えをしていただろうか。ブラウザプラグインに頼らないフォーマットで、あなたの映像は閲覧可能だろうか。

OS機能が出しゃばってくる可能性もある。例えば、着信やシステムのアップデートとプッシュ通知は、ユーザを、あなたのアプリから遠ざけるかもしれない。ユーザがアプリを再開した時、ユーザが何をしていたか思い出すための手助けをする方法を探し、データ損失のリスクを考慮してみてほしい。一定の期間でリロードするようなアプリの場合、特に長い通話の後は痛手となる。

どのOSにも、多くのUIのルールが積み込まれている。主要なOSのための関連したインターフェースガイドラインを理解し、ネイティブアプリケーションをデバイスの確立したパターンに合わせてみてほしい。

しかし、Webデザインであれば、ネイティブのルールよりもWebのルールを優先させよう。1つのプラットフォームを模倣することは、もう1つのプラットフォームを遠ざけることになる。たった1つのOS上で動作するWebアプリはほとんどない。あなたのプロダクトのユーザ層が特定のOSに限られていたとしても、OSをアップデートする習慣はユーザによって異なるため、ある特定のOSにフォーカスするのは危険だ。

Webアプリに対してネイティブデザインのルールを再現することは、痛みを伴う努力だ。インタラクションデザインパターン(トランジション、タイミングと行動など)は、リバースエンジニアリングや模倣には向かない。これはあなたのコードを肥大化させるし、OSがスタイルを変えてきた時は常に対応する必要がある。

特定のデバイスに最適化されたWebアプリを作りたい、という衝動は理解できるが破滅的ともなる。ネイティブデザインが重要だと感じたら、ネイティブアプリを構築してみてほしい。Webアプリは、プラットフォーム的に中立でなければならない。Webの多様性は、その主な特徴である。

一方でWebアプリを作る際、ユーザのOSとブラウザ情報が分かると役に立つ。それらはUser-Agent(UA)という文字列を通して取得できるが、ブラウザは、その名前とバージョン、OS名とバージョン、使われているデフォルト言語といった他の情報を特定してくれる。この情報はある程度役に立つが、UAは完全ではなく成りすましが容易だ。UA(ブラウザ)スニッフィングは信頼性がないことで悪名高い。

仮にUAに頼ることができたとしても、バージョン番号から正確なブラウザとOS能力を読み取るような信頼に足る方法は無い。UAを補うためのエンジニアリングの手段はクライアント側とサーバ側の技術の混合までを含み、例えば、基本的な特徴を学ぶためにWURFLの言及や、JavaScriptを使用した、ブラウザ側の機能探知などがある。Modernizrのような資料は、タッチイベントやローカルストレージ、advancedCSSなどの機能をサポートするかどうかを教えてくれ、これらの情報を含んでいるクッキーを渡すことで次回から機能探知の速度を上げることができる。

全ての利点のために、ブラウザとデバイスに対する深い知識と、技術的な解決を持って置き換えられるということではない。今日における洞察の用途を制限することがないように。真にデバイスコンテキストを理解するために、デザイナーは新しいハードウェアとソフトウェアを持って常に知識を最新にしておかなければならず、関連した新しいトレンドにもアンテナを伸ばしておかなければいけない。

デバイスコンテキストを理解するポイント

  • プロダクトに使われているデバイスは何か
  • 1年後はどうか。3年後、5年後はどうか
  • そうしたデバイスにできること、できないことは何か
  • このようなデバイスにはどの様なインタラクションが最適か
  • 強みを生かすことができる固有のデバイス機能があるか
  • 私たちのプロダクトはそうした機能を持ち合わせていないデバイスにどう取り組むか
  • 生活をしづらくしてしまうデバイス機能があるか。どうしたらそのような影響を減らすことができるか

第3回: 環境からデザインを逆算する へ続く