あるチームの例

My Strengths Finderでのチーム構成メンバー例はこの４人でした。

チームリーダーでWebプロデューサーのAさん
WebディレクターでUXデザイナーのBさん
フロントエンドエンジニアのCさん
WebデザイナーでUIデザイナーの私

上の４人のうち一番重要な人は誰なのか？わかりますか？
それはUXをカバーしている人です。この場合はBさんです。Bさんの能力や知識、経験次第により、リリース後のウェブの成果が変わってきます。しかしそれがわかるのは数ヶ月先なのが困ったところです。

このチームではBさんはWebディレクターを兼ねていますから、クライアントと一番近い立場にいて、クライアントの意向を受けてUXを行っているはずです。

ところがUXに失敗する多くの例として浮かび上がるのが、あまりにクライアント側の意向に振り回されて、ユーザーにとって使い勝手の悪いWebを作ってしまう危険性です。

また「いつまでに出来るの？」「○ヶ月でできるよね？」とクライアントにプッシュされ、WebディレクターであるBさんは「うちは何とかやります」と案件確保を重視に動いてしまった結果、肝心のUXに時間をとれず、

「ウェブ作ったはいいけどお客が来ないよね？」という最悪の事態を招く道を進んでしまう事になります。

原因はUXを軽視したから。クライアント自己満足サイトができ、ユーザーが面白くなく使いにくいからです。

UXに時間をかけるとは何に時間をかけるのか？

先にUXとは「ユーザーのWebにおける体験」とお伝えしましたが、主体はクライアントではなく、ユーザーです。ウェブの主役はクライアントではなくクライアントがターゲットとしているユーザーです。

優秀なクライアントはこの理解が深く、ユーザー分析が行き届いていて、その内容をBさんにしっかり伝えている場合は、最悪の事態は回避される可能性も高いです。

しかし多くの中小企業ではユーザー分析が進んでいなく決裁権限者が知識を持っていない事実があります。

ユーザーを分析せずリリースを急ぐクライアント→ 経験の浅いUXデザイナー

この組み合わせで集客できないウェブが自然発生的にできてしまうのです。

では本来のUXとは何を行うのかというと、それは「ユーザーテスト」です。

もっとくわしく言うと、ユーザーの事をよく知るという事です。もっと具体的に何をするのかと言うと「足を運んでユーザーに実際に会い話を聞く」「ユーザーにインタビューを行う」事です。

しかしBさんの立場のUXデザイナーが失敗しがちなのは、ユーザーに会うよりクライアントに会いに行ってしまう事です。

このUXの正しい工程こそがウェブの成否を分ける重要なポイントです。この工程に時間をかければかけるほどウェブは成功します。

UIデザイナーである私は、UXデザイナーからの案件準備の出来具合により、UIのスピードは格段に違ったものになります。

UXデザイナーから「とにかく時間がないからプロトタイプは概要OKされたから、すぐUI制作にかかって！」と分析資料も少なく言われた時は、ただスピード重視に集中する事になってしまいます。

UXデザイナーとUIデザイナーはまったく別の仕事です

これまでの説明でおわかりのように、UXとUIはまったく別の仕事です。この理解がまだ国内の経営者や管理者に行き渡っていない現状があります。

チームメンバーの声が吸い上げられる環境なら、この説明も通りやすいですが、決裁権を持つ方々の頭にあるのは別の数値。UXとUIの区別など枝葉事と思われている節もあります。すると人事も採用時の肩書に「UX/UIデザイナー」と記載してしまい、１人で２役やれる人は人件費も１人分ですむと、堂々とこの職位名で募集をかけたりするのです。

わかる人は「UX/UIデザイナー」という記述を見た途端、その会社の内情が透けて見え引いてしまったりします。そうなると「UX/UIデザイナー」は一瞬でその会社の文化がバレでしまうかっこ悪い名称とさえなりうるのです。

それでもUX/UIデザイナーとして１人で両方をやってる場合は、人員に余裕があって、それぞれUXとUIの専任の部下がいて、それを取りまとめるチーフ的な役目なら問題ありません。

要するにUXとUIにはそれぞれ別の専任が必要なのです。これを１人でやった場合、多分どちらも中途半端になります。というよりUXはほとんど形だけで、UIに重点をおかざるを得ないからです。

以上のUXとUIが別物という事を踏まえて、工程管理を行えば「マーケティング、マーケティング！」と別予算をかけることもなくなる可能性もあるのです。