「ui」タグアーカイブ

機会損失的側面の計量方法

コメントを残す

ユーザーインターフェイス、情報アーキテクチャ設計において、ここのところ機会損失の影響について考えさせられることが続いている。

一般に、ユーザーインターフェイスは必要な要件を積んでいっただけでは、いっぱいいっぱいになってしまい、飛行機の操縦席のようになってしまう。
最近では飛行機の操縦席も統合化されているようだが、とはいえ、エキスパートにはやはり物理的に計器が並んでいる方が「使いやすい」ことが多い。
しかしながら、初めて使う人、長期間にわたって使っているがコミットが低い人、などには、そういったいっぱいいっぱいインターフェイスは、どれからつかってよいかわからない、なにがなにかわからない、といった結果となってしまう。

ちなみにこれを最近「インターフェイスの共倒れ問題」と呼んでいる。

この問題自体はかれこれもう20年くらい語られてきていると思うが、じゃあ、どこまで単純化すればいいの、というポイント、（できるだけ）客観的なこの部分を評価するための指標、といったものをまだ見つけられていない。

おそらく安藤昌也氏の提唱した「長期的ユーザビリティ」の観点、インターフェイスの最低限の教示要件の観点、安全性能の観点（緊急停止とか、ミュートはダイレクトにやる必要がある、とか）、などの要件が足しあわされるのだと思うが、どうもそれだと通り一遍でつまらない。

最近のHCI関係ではそういったあたりも研究されていたりするのかな？
どういった分野を参照すればよいか、ご存じの方いたら教えてください。

ペルソナ法と塩野七生氏

3件の返信

ペルソナ・シナリオ法という言葉がはやっている。

ペルソナ法とは簡単に言ってしまうと、デザインをするとき、一般的でない、具体的な利用者をイメージせよ、という方法。

先日もそういったセミナーを開催したが（すいませんQ&Aの結果はもうじきこの場でお答えします）、その際いつも、「ペルソナ法だとその人向けだけに特化されてしまうのではないか？」という趣旨の質問をいただく。

毎回「そういうものではなく、具体的に対象者を想定することで企画が具体的になる、ということを意図しているんです」という返事をしているのだが、たまたま読んでいた塩野七生さんの「男たちへ」にそのものずばりの解答が載っていた。

（略）ここには、創作活動のカギの一つが見事に言いつくされている。（略）その私でも書くときは、読者は頭になく、眼の前の担当編集者に向かって書く。彼を、でなければ彼女を、うならせてみたいという思いだけで書く。なぜなら、それが上手くいけば、その向こうにいる不特定多数の読者にも自然に通じる、と確信しているからである。（太字は傍点部）
男たちへ―フツウの男をフツウでない男にするための54章 (文春文庫)

とまあ、そういうわけなんです。

TC協会シンポジウムにむけて

コメントを残す

ウェブサイトなどのデザインにおいて、機能（裏側）とユーザーインターフェイス（触れるところ）のデザインは通常別に職能を持った人が行い、フェーズとしても分かれている。

Linuxに必要なのは見た目か – コデラノブログ３

さて、LinuxにMacOSのような見栄えが必要かと言えば、うーんまあ今ぐらい頑張ってればいんじゃない? と思う。実際に使うのはアプリケーションだったりオンライン上のサービスだったりするわけだから、デスクトップやファイルのアイコンなどは、既存OSのい いとこ取りをして使い勝手が良ければ、それで十分だろう。

それよりも、ちょっと使い勝手を変えたり、ツールを入れたりするときに、やっぱり10年経ってもsudoしてコマンド打ち込んだり、エディタで設定 ファイル開いて書き直すみたいなことになっている。多くの人を取り込もうと思うのならば、この辺をGUIで何とかした方がいい。

OSの動き全体をコーディネートする人がいて、その人のポリシーを実現しようとするような集団が後ろについているような状態、つまり会社内の命令系統のような形でチームが固定化されないと、なかなかすべてをGUIでデザインするのは難しい。

そのあたりが、多くの推進力を有志のプログラマ集団に依存しているGNU/Linuxというものが構造的に抱え続けている問題だと思う。

この融合については、いくつか方法を試したり、検討がなされていたりしている。

昨日、テクニカルコミュニケーター協会（TC協会）シンポジウムでのパネルディスカッションの事前打ち合わせのために、TC協会理事の高橋さん、HCD-Net機構長の黒須さん、ソシオメディアの篠原さん、テクニカルライターの高橋さんなどとミーティングをしてこのテクニカルライティング業界でも同じようなことが起きていることに気づいた。

テクニカルライティングは、通常「マニュアル執筆」という形をとることが多いが、これはわりと後工程として製品私用ができあがってから、その説明書、という形で書かれる、ことが多いようだ。

が、いま情報プロダクトを企画するとき、「どう使えるのか」というメッセージは、説明書で説明するものではなく、機器自体に埋め込まれていなければならない（あるいは箱に書いてある、とかでもいいかもしれないけど）。

この部分にテクニカルライティングの専門家が関与していない、できていない、というのは大変もったいない。

「テクニカルライティングの専門家」がどこからどこまでの領域の技能を指すのかは定義が難しいような気がするが、そこが明らかになれば、サービスや製品の企画・設計の段階にもっと関与できるようになると思う（というか、参加していただきたいです）。

若干はしょり気味で書いたのでわかりにくいですが、今後深掘りする必要があるテーマに思う。

Symbian vs. Andoroid (and iPhone)

2件の返信

NokiaはSymbian OSのSymbian Limitedを買収すると発表した。

これに伴い、AT&T、LG、Motorola、NTTドコモ、Samsung、Sony Ericsson、STMicroelectronics、Texs Instruments、VodafoneとNPO Symbian Foundationを設立することを発表した。

Nokia to acquire Symbian Limited to enable evolution of the leading open mobile platform
http://www.nokia.com/A4136001?newsid=1230415

これに対して、The Wall Street JournalはGoogleのAndroidの携帯電話への搭載の遅れを記事にしている。

Google’s Mobile-Hnadset Plans Are Slowed
http://online.wsj.com/article/SB121418837707895947.html

記事によると、今年後半に発売予定だったAndroid搭載携帯電話は第四四半期まで発売されないとのこと。

Googleと30社のパートナーによるアナウンス、という書き方をしているが、T-MobileなどのAndoroid搭載機を発売予定だったキャリアとメーカーはリリーススケジュールの調整に苦労している、とのこと。

ドコモはOSにAndoroidを採用するんじゃなかったっけ？

ＮＴＴドコモ、携帯ＯＳ簡素化発表
http://www.yomiuri.co.jp/net/news/20080428nt0b.htm
（もっと長い記事があったのだが、削除されている）

アメリカではいろいろな端末が入り乱れているが、イギリスでは街を歩いているとみなNokiaだった。

４年くらいSymbian S60端末を使ってきているがSymbian携帯の最大の使い勝手（この場合、長期使い勝手：Long Term Usability）上の課題は、アプリケーションのマルチタスク切り替えではないかと思う。

S60では、「アプリケーション立ち上げ」の概念が重要で、一度立ち上げたアプリケーションは「切り替え」で移動、さっきまでの動作を引き継ぐことができるが、これを覚えていないとうまく使いこなせない。

また、各アプリケーションの中の振る舞いはアプリケーション依存なので、たとえばブラウザはタブのように複数ウインドウを立ち上げられるが、メールは「書きかけ」バッファは一つで、複数書きかけられない（「Draft」フォルダに入れればできるけど）。

もちろん、こんな面倒なことを考えずとも使うことはできるが、たとえばメールからURLをクリックしたとき、ブラウザのメールアドレスをクリックしたとき、Google Searchアプリの検索結果への遷移等、アプリ連携があるときの振る舞いは挙動不審なことが多い。

また、致命的なのは、ボタン操作で、上記の「アプリ切り替え」は「メニューボタン長押し」なので、これは使いこなせている人、アプリケーション概念を理解している人にしかうまく使えないだろう。

iPhoneではこの問題を「操作ボタンは一つ」という方法で解決している。

ユーザーは別アプリに移る際は常に「HOME」ボタンを押すしかなく、このとき立ち上がり済みかどうかはまったく意識する必要もなく、むしろ通常は意識できない。

操作上もすでに立ち上がっているアプリでは直前までの振る舞いが継承されるが、特に立ち上がり時間等で意識することはまずなく、自然で違和感がない。

iPhone 3Gによる黒船襲来に対して、日本では「デザイン優先携帯」としての扱いを行っているように見えるが、さすがにこういった「UIの基本文法」に関してのクオリティはAppleの企業資産として生かされている。

これは、開発プロセス、評価手法、設計のツール、関与するスタッフの種類、どの段階でだれが口を出せるかという文化、どの程度リサーチやプロトタイピングに時間を費やしそれらを前提にするか、ユーザーテストの実施とタイミングといった要素の有機的な組み合わせ方の、勘所や雰囲気といったもので作られるものだ。

Appleの内部事情はよく知らないが、たとえばどの程度の開発チームでどの程度のタスクを実施することが最適か、という経験則もここには含まれる。

経験された方はわかると思うが、モデル作りや、コアなコンセプト作りにおいては、あまり体制が大きいとなかなかプロジェクトが進まない。この場合はリサーチやプロトタイピングに最低限のスタッフと、意志決定に必要なキーパーソンのみの関与、がベストな体制となる。

このApple社のアドバンテージはとても重要であり、今後はPC関係だけでなく、情報プロダクトのデザイン一般において意味をなしてくるだろう。