要件、要素、分類と構造化、そして、視覚化・振る舞いの検討へ

昨日の「人間中心設計プロセスでの具体的なデザインへの落とし込みの技術に関する理解不足について」の続きとして。

結局、インタラクティブな製品のデザインというのは、きわめてシステム設計的なものだと考えたほうがいいと思っています。製品、利用者を中心に、それが用いられる利用環境も含めた大きなシステムを想定した設計が必要だと捉えたほうがやるべきことが明確になってくるのではないかと思います。

各段階でのアウトプットから見たUIデザインのプロセス

きわめて概念的にモデル化してしまえば、作業のステップは各段階で以下のようなアウトプットを作成しながら進むと考えればいいと思います。

  1. コンテキストシナリオ
    • ペルソナが製品を利用する際のコンテキスト、行動を物語として示したもの
  2. 要件の定義
    • コンテキストシナリオを分析して製品に求められる要件をペルソナの視点で抽出、リスト化
    • データ要件と機能要件を中心に、ビジネス要件、技術要件、その他の要件を抽出する
  3. 要素のリスト化
    • コンテキストシナリオから抽出した要件をUIの言語に翻訳したデータ要素、機能要素に変換
    • 例えば「電話をかける」という機能要件は「アドレス帳から電話をする」「発／着信履歴から電話をする」「短縮ダイヤルで電話をする」「音声通話で相手と話す」という機能要素に翻訳できる
    • 要件のリストを元に必要なデータ要素（およびデータを構成する属性）、機能要素をリストアップする
  4. 要素の分類（情報の組織化）
    • リストアップしたデータ要素、機能要素を、ペルソナのゴールや役割、コンテキストシナリオを考慮しながら分類しグループ化する
    • グループ化した要素はペルソナの作業フローや比較・併用などの利用の仕方、利用頻度も考慮して、並び順や優先度合いも決めておく
  5. 要素・要素群の階層構造化（情報の構造化）
    • グループ化した要素群を階層構造化する
    • データ要素および機能要素それぞれに関して、ある要素群がどの要素群の下位構造であるか、要素群同士の関係性はどのようにモデル化できるかなどを検討し、適切な階層構造と因果関係を作成する
  6. UIフレームワークの検討（情報構造の視覚化・具体化）
    • 分類・階層構造化したデータ要素・機能要素を適切な形に配置したUIフレームワーク（＝ワイヤーフレーム）を手描きで何パターンもスケッチしてUIデザインを検討する
    • エリアの分け方、コントロールコンポーネントをはじめとするボックス型の領域の使い方を何パターンを描きながら、コンテキストシナリオを元にしたシミュレーションを行い、最適な案を探る
  7. キーパスシナリオ、チェックシナリオを用いたインタラクションの検討
    • ペルソナが製品を利用する際に行う操作やそれに対する製品のフィードバックなど、詳細なインタラクションを記述したキーパスシナリオを、ペルソナが頻繁に使う経路に絞って作成し、スケッチしたUIのデザインやインタラクションを検討する
    • 利用頻度が少なかったり、ペルソナにとってはあまり重要ではない経路に関しては、チェックシナリオと呼ばれるペルソナの利用視点での質問項目を並べたリストでのチェックを行う

こうしたステップを踏むことで、UIの構造や骨格および利用者と製品相互のインタラクションをデザインすることができます。このステップがUIのラフなデザインとなり、さらにビジュアルデザインを検討し、デザインを精緻化していくことになります。

インタラクションデザインをするには多少なりともシステム設計の知識は必要

どうでしょう？　このステップをみると、いわゆるデザインというイメージよりはシステム設計のイメージに近いですよね。データという静的なオブジェクトと機能（イベント）という動的なオブジェクトの分類、構造化、関係性の定義を行いながら、システム（製品とそれを使う人間も含めた）を要件という概念的なものからUIや具体的な振る舞いへの具体化していく作業は、むしろシステム設計をしている方のほうが馴染みやすいのではないか、と。

その意味で本気でインタラクションデザイン、UIのデザインをやろうとすれば、システム的な発想ができないとつらいと思うんです。

でも、そのことをちゃんと認識している人が少ないし、情報デザインとして教えられてもいないんじゃないかなと思うんです。イメージ的には、多くの場合、デザインをやりたいと思う人ってできればシステム的なことは（苦手なので）避けたいとかって感じるんじゃないかという気もします。それは教わるほうだけじゃなくて、教える側にしてもたぶんそうなんじゃないでしょうか？（これが問題）

ただ、実際、インタラクティブな製品・サービスをデザインしようとしたら、そこに関わることは避けられないんじゃないかなーって気がします。グラフィックデザインの意味で情報デザインをやるならともかく、ウェブでも組み込みシステムでもソフトウェアでも、UIを通じて人とシステムがインタラクションを行うものをデザインしようというなら、やっぱりすこしはシステム設計のことも学んでおいたほうがいいと思います。

ER図？　データの正規化？　ユースケース図？　なにそれ、おいしいの？　というレベルではさすがに困ります。昨日のエントリーでは、UIは実装モデルを表現するのではなく利用者の脳内モデルに近づけて表現しないといけないと書きましたが、それをちゃんと区別して使い分けるには、避けるべき対象である実装モデルがそもそもどうういうものかもある程度はイメージできないと避けるのもむずかしいと思いますから。
（ちなみに僕自身は昔、すこし自分でもプログラムを書いたりデータベースをつくったりしてたおかげで幸いシステムアレルギーはないのですが、それ以上に佐藤正美さんという方からデータベース設計について教わったおかげで、ずいぶんシステムに関する基礎的な勉強をさせてもらったと思います）

別に、本当にシステム設計ができたり、プログラムが書けたりというレベルは必要なくて、システム設計の基本的な考え方やどういう手法があるかを知っている程度でもいいと思います。UIデザイン、インタラクションデザインで定義したものが、実際のシステム設計の段階でのインプットとしての要件にもなるわけですので。

とはいえ、やはり最低限のシステム設計の知識は必要。そうじゃないと、使えるデザイン、使いやすいデザインには絶対にならないと思いますから。

　　

関連エントリー

この記事へのコメント

コメントを書く

この記事へのトラックバック