“UIデザイン”のための”デザインプロセス”


先日、「RIAxDNPチームのUIデザイン10のポイント」という記事を読まれてコンタクトを頂いたお客様がいらっしゃいました。
この記事を書いたのはもう4年前で、PC向けのWebサイトやRIA(Rich Internet Application)が中心だったのですが、我々もすっかりスマートデバイス向けのUIデザインを行っており、これまで自社や他社(得意先)問わず、いろんな案件を経験してきました。
その経験を生かし、我々なりの「UIデザイン」の方法論というかプロセスをご紹介したいと思います。

Sketch

「UIデザイン」プロセスの必要性

ちまたにたくさんのUXデザインやUIデザインについて本やセミナー、ブログもいっぱいあり、もちろん参考にしたり勉強したりしていますが、下記のような理由から、我々なりのやり方をまとめてプロセスとして定義していく必要性を感じるようになりました。

  1. UIデザインの案件が増えてきて、効率的にUIデザインを行っていきたい
  2. UIデザイン及びその要件デザインができるメンバーを増やしたい
  3. なるべく個人のスキルに依存せず、チームで良いUIデザインが出せるようにしたい
  4. UIデザインというワーク自体をもっとマネージメントしていきたい
  5. 依頼主(お客さんなど)を巻き込んでUIデザインを行っていきたい

UIデザインのプロセスを定義し、そのプロセス内のフェーズで利用するメソッドやパターンを当てはめていくことが、自分たちだけでなく、得意先やシステムやサービス開発に関わるステークホルダー全体に共通言語、パターンランゲージをもたらすことが狙いです。

Discussion

「UIデザイナー」としての役割

いざ「UIデザインのプロセスを定義しよう」と思うのですが、そもそも「我々の役割は何か」を考えるところから始まります。まず、我々は「UIデザイナー」と「UXデザイナー」の役割は分けて考えたいと思いました。というのも我々は自社サービスやプロダクトのUI/UXを継続的に考えるというより、お客様を含めたさまざまな案件の受託請負というスタンスだからです。
そこで我々は「UIデザイナー」の役割は担うのですが、「UXデザイナー」の役割は「主体的には」担わないようにしています。UXデザインは、どんなサービスや商品を作るか、それがどんな価値をカスタマーにもたらすか、といった大きな意味での「体験」デザインでおり、その部分はUIデザイナーの役割を大きく越えると考えています。

UXデザインとUIデザインの違いをシリアルで例えたものがありますが(これの細かい議論は置いといて)、根本的にはシリアル自体が美味しくなくては、いくら使いやすいスプーンを用意したところでまあ良いユーザ体験(UX)は期待できませんし、シリアル自体を美味しくするのは我々にはできません。

ちなみに「(広い意味での)何を」「なぜ」作るか、といったベースのコンセプト作りやカスタマーエクスペリエンスのデザインは、弊社の「サービスデザインラボ」が専門に取組んでいます。

Service Design Lab

ただ、これが悩ましいところで、「UIデザイン」を行うには、「誰のために何をつくるか」=「要件」、言い換えればUXに相当する部分が決まっていてほしいのですが、実際にはその要件が「決まっているようで決まっていない」ことの方が多いです。その理由として、実際にアプリやサービスのためのプロジェクトなり案件なりがキックオフすると、

  • 「UIデザイン」に入れるレベルまで「要件、ユーザ体験」が 詰まり切っていない
  • 集まったメンバーの間でもやりたいことのイメージや目的にズレがある
  • UIデザイン考えていく中で、その「要件」でいいのか、疑問が湧いてくる

というような感じになるからで、とはいえ「要件」を決めてからご相談ください、というわけにもいかないので、その「要件」デザイン、UXデザインとオーバーラップする部分の導出についてファシリテーターとして我々UIデザイナーが担い、ステークホルダー全体でUXデザインしたいと考えています。

Discussion

UIデザインプロセス

ということでプロセスを規定するときの悩みや紆余曲折はさておいて、結論的にご紹介させていただきますが、我々が現在策定したUIデザインのための一連のプロセスの概要が下記の図です。

UI Design Process

それぞれのフェーズを簡単に説明します。

  • ヒアリングフェーズ
    • 文字通りお客様や依頼主から案件についてヒアリングを行います。案件の背景やなぜ作るのか、何がどの程度決まっているのか、プロジェクトの計画等を伺います。
  • リサーチフェーズ
    • ヒアリングした内容から、案件の周辺情報をリサーチします。競合や類似のサービスの機能や使い勝手、またターゲットユーザの情報や分析等を行います。
  • コンセプトフェーズ
    • リサーチした結果から、「誰のために」「何を」「どのように」すべきかを決めていきます。案件のゴールや目的等をステークホルダー全体で擦り合わせます。
  • プランニングフェーズ
    • 画面要素となる情報アーキテクチャの整理やその情報を扱うユーザシナリオを決めていきます。ここでコアとなる要件とその周辺要件も見出します。
  • デザインフェーズ
    • 実際にユーザとユーザインターフェースとのインタラクションを検討し、ワイヤーフレームを作成するフェーズです。プロトタイピングフェーズ、評価フェーズとイテレーションでサイクルを回しながら精度を高めていきます。
  • プロトタイピングフェーズ
    • 手書きのワイヤーフレームからプロトタイピングツール、開発環境で開発したものまで、継続的な試行錯誤(=プロトタイピング)ということでプロトタイピングを行なっていきます。
  • 評価フェーズ
    • モックアップから開発したプロダクトについてヒューリスティックに評価を行ったり、実際にユーザからヒアリングを行ったり、ユーザログ等から評価を行います。

もちろんこれらのプロセスのフェーズ分けは現段階のもので、経験を重ねたり他のベストプラクティスを取り入れていくことで改良してくべきだと考えています。また、いろんなUIデザインの案件を進める上で、このプロセスの型にはめることが目的とならないよう、柔軟性に気をつける必要があります。

Discussion

今回は我々のUIデザインプロセスのおおまかなフェーズだけをご紹介したに過ぎませんが、今後それぞれのフェーズについてご紹介したり、また悩みや試行錯誤している様子なども記載していきたいと思います。