UI/UXデザイナー?
Webサービス開発において、「UI/UXデザイナー」という肩書をよく目にする。なんとなくデザイナーというと、「イラレやフォトショを使う人」をイメージしてしまう。僕もそうだった。
確かにUIは目に見えるため、UIをデザインする上ではイラレやフォトショを使うんだと思う。でもUXは違う。 UIはUXのいち要素でしかなく、UXは目に見えない要素も包含する。
The Elements of UX
次の図は、Adaptive Pathのジェームス・ギャレット氏が2000年頃に提唱したThe Elements of UXというモデル。(オリジナルの図はこちら)
この図はUXを考える上で、すごく分かりやすい。イラレやフォトショ作業を伴うであろう、ビジュアルデザインやインターフェースデザインは、あくまでUXの表層でしかない。
UXってサービス開発そのものだ
UXは、情報アーキテクチャや、サービスの戦略など、目に見えない部分も含めて構成される。エンジニアリングだってUXに含まれると思うし、カスタマーサポートやコミュニティマネジメントのようなサービス運営面もUXを構成する要素だと思う。
つまり、UXを作り上げる行為は、サービス開発とほぼ同義だと思う。少なくとも、このThe Elements of UXの5要素はサービス開発において必要不可欠だと思う。
デザイナーはみんな超人なのか
じゃあ所謂「UI/UXデザイナー」と呼ばれる人は、これらを全てこなせるスーパーサイヤ人なんだろうか。
グラフィックデザインもできて、UIデザインもできて、インタラクションデザイン、情報アーキテクチャへの理解があり、さらにサービス企画、可能であればフロントエンドのコードも書ける人…。
確かにそういう人も居る。クックパッドにはこういう超人デザイナーが多かった。ただ、それが普通だと思って、どのUI/UXデザイナーにもこれらを求めると、サービス開発は失敗する。と、社外に飛び出してみて気づいた。
考えてみれば当然なんだけど、例えばIA (情報アーキテクチャ) のような抽象的なスキルと、ビジュアルデザインのような目に見えるアウトプットを出すスキルは全く別物。デザイナーのなかで得意不得意があって当たり前。
エンジニアは技術スタック毎に役割が分かりやすい。インフラエンジニアに対して、Swiftを書いてくださいとは誰も言わないだろう。
逆にデザイナーは役割の違いが分かりづらいのはあるなと思う。xxxデザインの違いって、デザインに対する理解がないと分かりづらい。だから、あれもこれもデザイナーに求めるんだと思う。
デザイナーでなくてもUXをデザインできるはず
「UX=デザイナーの領域」と考えると思考停止だと思う。全デザイナーに対して、超人的スキルセットを求める必要がでてくる。
加えて、UXデザインがサービス開発そのものだとすると、「サービス開発エンジニア」と呼ばれる人は何をするのか(ひたすらコードを書く…?)。「Webディレクター」と呼ばれる人は何をするのか(制作進行…?)って話にもなる。
話を、The Elements of UXに戻すと、UXにおいて、ビジュアルデザインはあくまで表層でしかない。ビジュアルで表現する技術がなかったとしても、それはUXデザインができないことにはならないと思う。
つまりエンジニアや、ディレクターだってUXはデザインできるはず。UXを要素分解し、一つ一つのスキルを身につければ、デザイナーの役割の一部を補完することができるはず。 そうして、チーム全体でUXをデザインする、サービス開発することが重要だと思う。
実際やってみてる
今一緒に仕事をしている外部のデザイナーさんは、ビジュアルデザインが得意な人で、逆に抽象レイヤーが苦手な人。自分はこれまでにサービス開発エンジニア兼プロダクトオーナー的な役割をしていた時期があり、コンセプト作りのような抽象レイヤーは経験してきた。
なので、The Elements of UXでいう戦略~構造レイヤーまでは自分が担当し、骨格や表現のレイヤーをデザイナーさんにお願いするような役割分担にしたところ、少し開発がうまく回るようになった。(逆に言えばその前は、機能の要件定義の一部までデザイナーに丸投げしていた…)
ただ、構造レイヤーについては僕も知識や経験が足りないし、可能であれば骨格(情報デザイン)のスキルも付けたい。 ということで、最近はIAを勉強してみてる。

- 作者: 坂本貴史,宮崎綾子,長谷川恭久
- 出版社/メーカー: ワークスコーポレーション
- 発売日: 2011/03/29
- メディア: 単行本
- 購入: 12人 クリック: 167回
- この商品を含むブログ (10件) を見る
役割分担することによって、抽象レイヤーで考えたことを適切な形で、次のレイヤーを担当する人に共有する必要がある。 例えば、戦略を表現するために、アプリケーション定義ステートメントや、リーンキャンバスみたいなフレームワークを使うんだと思う。
同じ組織にいて、意思疎通がとれる人であれば、少し会話するだけでも共有できるんだろうけど、外部にいる人だとそれもまた難しい…。長くなってきたので、またそれは別途エントリにしたい。