最初のデザインスケッチご覧のとおり、このアプリケーションデザインの方法は信頼できるプロセスというより、ブレインストーミングのセッションにそっくりです。このようなプロセスは、まともなアプリケーションに辿り着くかもしれませんし、辿り着かないかもしれません。この最初のデザインにはいくつかの問題があります。番号しか拾うことができません。その番号を検索し、書名などに変換しなければならないでしょう。番号のないほど古い本をたくさん持っているユーザーはどうするのでしょう?書籍情報の赤外線通信はちょっとした便利機能ですが、そのささやかな便利さのわりには処理コストがかかります。誰かさんに書籍情報をビームするのは、どれくらい意味のあることでしょうか?その本が貸出中かどうかの確認のために詳細画面への移動を強いるのは、ユーザーがしたいことが単に一覧を眺め、どれが貸出中かを知りたいだけの場合には退屈な作業になってしまうでしょう。お勧めのアプローチさて、インターフェースデザインの普通のアプローチについて見てきました。次は、もっと良いアプローチについて考えましょう。結果をもたらしてくれるものです。この正しいアプローチのステップは以下のとおりです。デザイン目標を決めるユーザーを知るユーザーシナリオを作る実装案を作成する最初のデザインコンセプトを開発するデザインを完成させるここで説明するデザインプロセスに、完全に従う必要は必ずしもありません。小さな企業や個人でやっている場合には。ソフトウェア開発は多くの要因に影響される複雑な仕事であり、全てのプロジェクトは互いに異なります。デザインプロセスについて知り、できるだけそれに従えば良いことがあるでしょう。デバイスはシャツのポケットに収まり、速くて簡単に使え、学習曲線が急でなく、低コストで、安心して使えるだけのバッテリ寿命を持つこと。Palmのデザイナがデザイン目標を持って始めたのと同じように、アプリケーション開発でもデザイン目標を持って始めるべきです。アプリケーションのデザイン目標のセットは以下のとおりです。プラットフォームで成功したければ上記のデザイン目標を達成すべきです。小さな企業では、アプリケーションのアイデアとデザイン目標は間違いなくあなた自身から出てくるでしょう。大きな企業では、デザイン目標はマーケティング部門から出てくるかもしれません。前節の書籍アプリケーションの例を考えてみて下さい。アプリケーションが何をすべきかという記述は、大きな企業のマーケティング部門から出てくるかもしれませんし、独立したアイデアかもしれません。伝統的なデザイン目標は副詞を単純に追加します。“書籍愛好家が手早く、簡単に書籍を管理し、誰に貸しているかわかるようなアプリケーションを作成する”ユーザーを知るユーザーは千差万別です。ハンドヘルドの、あるいはあなたの製品の未来の典型的ユーザーではありません。ハンドヘルドは使い方が簡単なため、コンピュータ業界の外でも多くの人を惹きつけます。コンピュータ業界の人には“ハードウェア”と“ソフトウェア”、“アプリケーション”の違いは快適ですが、業界の外にいる一般的なユーザーはハンドヘルドを総合的に1つのデバイスとして見ています。彼らはハードウェアの問題とソフトウェアの問題、あるいはアプリケーションのバグを区別するという考えを持っていません。彼らが知っているのは自分にやらねばならない仕事があるということだけであり、Palmハンドヘルドがその手助けをしてくれることを期待しているのです。アプリケーションが訴求しそうなユーザーベースをよく調査して下さい。できれば、ターゲットユーザーをより良く知り、彼らがなぜそのアプリケーションを欲しがっているのかを学ぶためにフォーカスグループを設定します。ワインデータベースのアプリケーションなら非技術系の顧客に広く訴求するでしょう。内部メモリを調査するユーティリティは顧客のほとんどが技術系のはずです。Palm界の技術系と非技術系の両方に訴求力があるでしょう。広範な顧客のために、できるだけ組込みアプリケーションに追従しておきたいと考えるでしょう。ユーザーはすでそれらの使い方を知っており、それ故にあなたのアプリケーションの使い方についても暗黙のうちによく知っているということになるのです。機能を“改良”するのはやめましょう。“改良”というのは、グローバル検索機能におけるプレフィックスと同じようにサフィックスでの検索をサポートするようなことです。一部の限られた、高度に技術的な顧客を対象としているのであれば、ユーザーインターフェースデザインの大部分を免れるかもしれません。優秀なインターフェースは決して害にはなりません。作れば、ユーザーはそのアプリケーションをより高く評価してくれるでしょう。前節から見ているデザイン目標のような典型的ユーザーの記述は、マーケティング部門から別の情報としてやってくる場合もあります。小さな企業には、マーケットリサーチの専門知識を備えた大きなマーケティング部門を持つという贅沢はできないかもしれません。友人や家族の中からでもユーザーを見つけ、彼らのニーズについて話すことはできます。書籍アプリケーションについては、以下の特徴を持つ人々がこのアプリケーションを買いそうだということがわかりました。たくさんの本を所有している。暇さえあれば本屋をぶらついている。どの本を持っていてどの本を持っていないか、または持っていてまだ読んでいないかを思い出せない。たくさんの本を友人に貸しているため、どの本を持っているか調べる時に問題になる。多くの人はテクノロジーが苦手。対象となる顧客の大部分はテクノロジーが苦手なので、できるだけ簡単に使えるようにアプリケーションを作成しなければなりません。アプリケーションと同じ感覚で使えるように作成する必要があります。ユーザーシナリオを作る典型的なユーザー像を集めたら、そのユーザーを意識しながらデザインを始めます。それとも車の中でしょうか?いくつかのユーザーシナリオを作りましょう。ユーザーシナリオは、ユーザーがそのアプリケーションでいつ、何をするかを記述したものです。“ユーザーは1日に5回、地下鉄に乗っている間に電子メールにアクセスする必要がある”というのは良いシナリオ記述です。ユーザーが何をするか、彼または彼女がどこでそれをするか、どれくらいの頻度でするかが明記されています。ユーザーシナリオを作成するもっとも良い方法はもちろん、フォーカスグループや他の方法を使って、潜在的なユーザーと話をすることです。ユーザーシナリオを見つけ出すには、以下のことがらを知っている必要があります。頻繁に利用される作業は、簡単に実行できなければなりません。予定の入力は頻繁に実行されるもう1つの作業です。3:05など)というのはそれほど多くありません。このような予定の入力を可能にするとしても、頻繁に発生するわけではありませんからタップが数回余分に必要となっても良いでしょう。必要でも頻繁に実行されないタスクというものもあります。アプリケーションを起動するものです。通常起動されるのは1回だけですから、頻繁とはいえません。頻繁には発生しないと思われるものも含め、できるだけ多くのシナリオを作成して下さい。これはデザインプロセスの中でもトリッキーな部分です。アプリケーション開発チームがサポートする、想定済みのシナリオは簡単に作成できるものです。そのようなシナリオだけにフォーカスしていると、最終的にできあがるアプリケーションは、チームのニーズには合致していてもユーザーのニーズには必ずしも合致しないでしょう。網羅性の高いユーザーシナリオは、ユーザーのニーズに注目し続ける努力を必要とするのです。ワイヤレスインターネット接続を使用した書籍購入が盛り込まれていました。これらは悪いアイデアではありません。ユーザーベースにはテクノロジーが苦手な人々が多く含まれていることはすでに見たとおりです。ようなローエンドのハンドヘルドに惹かれます。ハイエンドのハンドヘルドを持っているユーザーは少数でしょう。持っていそうにはありませんし、ましてやバーコードスキャナを持ってなどいないでしょう。番号のスキャンやインターネット経由での書籍購入はあきらめなければならないのです。ユーザーが数多くいることがわかれば捨てなければならないでしょう。カラー表示への依存は、このアプリケーションでは間違いなく良くないアイデアです。カラーのハンドヘルドは高価になる傾向があります。人々がそれを持っている保証はありません。テクノロジーにフォーカスしたデザインは誤った方向へ逸れて行ってしまいがちなので、アプリケーションのユーザーシナリオをいくつか検討するようにしましょう。ユーザーは所有している全書籍の一覧を見たいと思っています。(頻繁にありそう)ユーザーは書店にいて、特定の本を所有しているかどうかを知りたいと思っています。(頻繁にありそう)ユーザーは書店にいて、新しく購入した書籍をリストに追加したいと考えています。(頻繁にありそう)ユーザーはデスクトップコンピュータから離れており、インターネットで書籍を購入したいと考えています。(頻繁でもありそうでもない)ユーザーは友人に本を貸そうとしています。(ありそうだが頻繁ではない)ユーザーは自宅にいて特定の書籍を探しており、それが貸出中かどうか知りたがっています。(頻繁にありそう)ユーザーは貸出中の書籍一覧を見たいと考えています。(ありそうだが頻繁ではない)ユーザーは特定の著者、あるいは特定のテーマについて所有している書籍の一覧を見たいと考えています。(ありそうだが頻繁ではない)ユーザーは指定した人物に貸している書籍の一覧を確認し、それらがいつ返却される予定かを知りたがっています。番号をスキャンしたいと考えています。(頻繁でもありそうでもない)デザインの最初の3つのステップ(デザイン目標を決め、ユーザーを知り、ユーザーシナリオを作成する)では、ユーザーの問題をどのように解決するかについてはまだ着目していないことに注意して下さい。そのかわり、彼らの問題を解決できるよう、ユーザーを理解することに注力するのです。実装案を作成するユーザーが誰で、アプリケーションをどのように使うかのイメージを掴むことができたので、次のステップではアプリケーションの実装案を記述します。この記述では、アプリケーションの見た目よりも操作感に着目します。これにより、実装の案はユーザーシナリオから自然に導かれます。このステップの背後には、2つの考え方があります。第一に、実装案への合意の上でアプリケーションの設計と開発に全員を巻き込んでしまえば、エンジニアはインターフェースデザイナによる外観のデザインと並行して機能を設計できます。第二に、アプリケーションの操作感にフォーカスすることにより、アプリケーションの外観に関する(この時点では開発を不必要に遅らせることになる)ありがちな論争を先延ばしにできるのです。1人で仕事をしているのであれば外観の開発をする前に実装案を作成するこれら2つの理由は無関係です。外観への注力を少し先延ばしにしてソフトウェアを開発することが役に立つと思うかもしれませんし、思わないかもしれません。いずれにせよ、ユーザーシナリオのフローや前のステップで作成した典型的ユーザーの記述に従って実装を行なっていくことになります。書籍アプリケーションの実装案は以下のとおりです。起動時の画面はアドレス帳に非常に似ています。所有している書籍の一覧が表示され、タイトル順にソートされています。アドレス帳のメイン画面を真似るのは、このアプリケーションに親近感を感じやすくするためです。ユーザーは大量の書籍を所有しているかもしれないので、アドレス帳と同じように文字を入力するだけで書籍を検索できるようにします。特定の書籍を所有しているかどうかを素早く知ることができるように、特殊な表示が可能なフィルタを提供し、特定の著者の全ての書籍や特定のテーマに関する全ての書籍、貸出中の全ての書籍を表示できるようにします。起動時画面では、新しい書籍情報の入力や書籍の詳細情報表示を可能にします。詳細画面には、タイトル、著者名、カテゴリ、および友人への貸出に関する状態が表示されます。メイン画面は、ユーザーが素早くリストをスクロールしてどの本が貸出中かを見られるように、貸出状態を表示できるようにします。データ入力を簡単にするため、デスクトップアプリケーションに統合されたコンジットを提供し、ユーザーが書籍情報のほとんどをデスクトップで入力してハンドヘルドに同期できるようにします。人は時に同じ著者の本をいくつか購入しますから、著者名に関してはデータベースに既存の著者名にもとづいた名前補完機能を提供します。他の組込みアプリケーションとの統合も行ないます。友人への書籍の貸出しは名前でアドレス帳にリンクされ、連絡先もそこに含まれることになるでしょう。友人が本を返却する日付を入力することにより、予定表との連携もできるかもしれません。多くの人は友人への貸出しに期限を設定しないため、常に利用可能な機能にするよりはユーザー設定で有効にできるオプション機能にした方が良いでしょう。テクノロジーにフォーカスしたデザインアプローチを思い出してみると、新規ボタンに加えて編集ボタンと削除ボタンをすぐに思いついています(あとスキャニングとビーム、ワイヤレスインターネット経由での書籍購入もありましたが、前のステップで除外しました)。ユーザーが頻繁に行なう作業にフォーカスしている間、編集と削除のボタンは話題に昇りませんでした。書籍情報は変化しませんから、編集ボタンは......そう、アドレス帳の編集ボタンほど重要ではありません。それに、書籍愛好家は滅多に本を捨てません。ユーザーがデータ入力での誤りを修正できるよう、なんらかの方法を提供すべきでしょう。そのため、サブ画面メニューまたはコマンドボタンとして編集と削除を提供することにします。最初のデザインコンセプトを開発するアプリケーションの特徴を記述し終わったら、次は外観を開発する番です。最初のデザインコンセプトに着目しながら始めましょう。最初のデザインはメイン画面に焦点を当てています。要素の選択が問題になってきます。ユーザーインターフェースの詳細は確定できないでしょうし、アラートのようなサブ画面はもっと後になるまで無視されることになるでしょう。ユーザーシナリオの可能性と頻度を考慮することは重要です。頻繁に使用されるコマンドや設定は、より簡単に発見でき、素早く実行できるべきです。要素の選択に関する詳細は本書の残りの章で説明しています。図1.5に、書籍アプリケーションの初期デザインコンセプトを示します。誤ったアプローチによる最初のデザイン(図1.4)との違いに注目して下さい。初期デザインコンセプトユーザーのニーズを学ぶのに時間をかけたため、彼らの抱える主要な問題が収集した大量の書籍の管理であることはわかっています。ユーザーシナリオには、頻繁に行なわれる作業としてどの本を所有し、それがどこにあるのかを確認するというものがあります。書籍の一覧は非常に長くなりうるため、もっとも重要な作業は文書一覧の提示と新しい書籍の入力であると判断しました。メイン画面では、カテゴリ選択による表示のフィルタリングや、ルックアップフィールドへの文字入力による移動などにより、書籍情報のナビゲーションを支援します。ノートアイコンを使うことにより、書籍一覧をスクロールするだけでどの本が貸出中かを簡単に確認できます。ノートアイコンをタップすると、貸出しに関する詳細情報を表示します。貸出情報は、誰にいつ貸出して、いつ返却されるのかを表示し、ルックアップボタンを提供することで、返却期限を知らせる必要がある場合にアドレス帳の連絡先情報に素早く移動できます。他の画面も用意します。書籍タイトルのかわりに著者名でソートできるようにするプリファレンス画面や、特定の人物に貸出している書籍を検索する検索画面です。これらの作業はユーザーシナリオでは頻繁には発生しないものとして記述されているため、コマンドボタンではなくメニューを通してアクセスすることになります。この時点ではまだスケッチに過ぎないかもしれませんが、作成したデザインがユーザーのニーズに適合しているかどうかを検証するために、この段階でユーザビリティのテストを始めるのにそのスケッチは適しています。メモ用紙くらいシンプルなテクノロジーを使ってモックアップを作ることもできますし、共通タスクのユーザーウォークスルーをすることもできます。ユーザビリティのテストを実施したら、デザインコンセプトに磨きをかけて次の段階が完了するまで再テストをします。デザインを完成させる主要なコンセプトがプロジェクトに参加している(インターフェースデザイナやマーケティング、エンジニアリングを含む)全員の合意を得られたら、デザインを確定できます。この時点で、アプリケーションの全画面をデザインし、全ての画面遷移を把握する必要があります。全てのUI要素を画面上に正しく配置し、メニューのデザインもする必要があります。全てのエラー状態も定義する必要があります。この段階はソフトウェアのアルファバージョンの作成段階でもあるべきです。従って、アルファリリースが完了したら、より多くのユーザーテストとフィードバックを得ることができ、ベータビルドやその先の最終ビルドへのデザインを洗練していくことができるのです。アルファ版の開発中にデザインは完成しているということに注意して下さい。多くの開発者は製品開発サイクルのもっと後までユーザーインターフェースデザインを放置しておきたがりますが、それは誤りです。最後まで待っていたら、初期デザインは開発済みのコードに縛られてしまいます。先延ばしにするほどデザインの変更は困難になり、インターフェースをそのまま放置する理由付けは簡単になっていくのです。2020/01/212020-01-21-01-最近の長風呂のお供はこれだった2020/01/172020-01-17-01-fistの自動実行スクリプトにおけるセキュリティホール問題2020/01/112020-01-11-01-fistにsudoを追加する2020/01/072020-01-07-01-fistのプライベートデータとスクリプトの問題2020年01月のlog2019/12/312019-12-31-01-2019年を総括するよ2019/12/262019-12-26-01-guile拡張のREPLは存続へ2019/12/222019-12-22-01-fistのguile拡張からREPL機能を除去するかも2019/12/192019-12-19-01-fistのguile拡張でstream入出力2019/12/082019-12-08-01-fistで添付ファイルのメモリ内圧縮2019年12月のlog2019/11/282019-11-28-01-書籍持ち歩き問題2019/11/222019-11-22-01-fistでzlibを使い始める2019/11/192019-11-19-01-読んでた本と、これから読む本books:Docker実践ガイド第2版2019/11/152019-11-15-01-デスクトップPCをデュアルブートに2019/11/082019-11-08-01-スマートフォンでも鍵盤を使いたい2019年11月のlog2019/10/302019-10-30-01-steamをfistに改名2019/10/242019-10-24-01-できればスケジュールやタスクなんかも。