大なり小なり、企業組織でウェブ担当者をしていると組織的な事情でUXを損なう判断をせまられる時があります。たとえば、以下のようなシチュエーション。
- 責任者の〇〇さんがそう言ったから
- システム的に無理だから
- 他媒体と表記の統一をしたいから
ユーザを中心に据えて考えたら「その選択肢はないよね」という判断を余儀なくされる時が結構あるんですね。だけど、そこを知恵と想像力とバイタリティでなんとかするのがウェブ担当者やUXデザイナーと呼ばれる人たちの仕事だと思っています。
ウェブ担当者やUXデザイナーがそこでもうひと踏ん張りして「それはユーザ目線で考えたら○○の方が良いですよ」とか「ユーザ目線で考えることが結果的にビジネスを成功に導くんですよ」と、ユーザを中心に据えた考え方でプロジェクトを導くことで、良い成果をあげてプロジェクトに関わる人たちをハッピーにできる。そして、そういったウェブ担当者の粘り次第でウェブサイトのUXが良くも悪くもなるわけです。
では、上にあげたようなシチュエーションに出くわした時、どういった対応ができるのか?
思いつくことを書き出してみます。諦める自分への自戒の意味も込めて。
組織のさまざまな事情や社内政治が絡んでくるとウェブ担当者の仕事ってすごく大変になるときがあります。この記事が、同じような悩みや課題を抱えているウェブ担当者の方々の少しでもお役に立てば幸いです。
責任者の〇〇さんがそう言ったから
最終的な判断をするのはプロジェクトの決裁権を持った責任者です。その責任者が首を縦に振らなければ、どんなに良い提案だとしても実現しないわけです。当たり前ですけど。
では、ウェブ担当者としては最良の提案をしているのにプロジェクト責任者が首を縦に振ってくれないという状況で、ウェブ担当者にはなにができるのか?
まずは、技術的というかテクニック的なところで考えられることを挙げてみます。
- プロジェクトの目的と目標を確認する。そして、意見が分かれている事象の解決策がその目的や目標を達成できるのか話し合う
- 目標・目的が明確でない場合(曖昧なままの時ってけっこうあります)、ヒアリングやリサーチをしなおしてプロジェクト責任者とすり合わせをする
- ユーザ目線で考えることがプロジェクト成功への近道であることを普段から粘り強く、あの手この手を使って説明しておく
- 意見が分かれている事象について他の周りの同僚や身近なユーザ(友人や家族もあり)に意見を聞いてみる(簡単な統計をとってみる)
- プロトタイプを作って簡単なユーザテストを一緒にやってみる。そして、ユーザの反応を直接見てもらう
- ウェブ担当者側が折れても問題ないところは、たとえ意見が分かれたとしてもとことん折れる。そして、そこについてはプロジェクト責任者に全判断を委ねる
- そのかわりUXを損ねる可能性があるクリティカルな部分に関してはプロジェクト責任者に譲歩を促す。ちょっとした取り引き的な感じになりますけど
- UXに影響を与えるクリティカルな部分をすぐに判断できるように、常にカスタマージャーニーマップは頭に入れておく
- A案に加えて、常にA案をアレンジしたA’案やA’’案を考えておく。さらには、奥の手B案を用意しておく。一つの解にこだわりすぎると躓きます
- あと、又聞きだった場合、必ず本人に直接確認するべきです。伝言ゲームでニュアンスが変わってしまっているとミスコミュニケーションが起こります。当然のことなんですけど、できてなかったりするんですよね。
これらはテクニックとして、いますぐにでも実行できることです。
ただ、僕の経験上、最終的にはプロジェクト責任者がウェブやマーケティングをどれだけ深く理解しているかがプロジェクトやウェブサイトのUXの質を大きく左右する要因であることが多いです。そう考えると、プロジェクト責任者との相互理解を深め、必要に応じて啓蒙や教育を行うことが、プロジェクトを真の成功に導く最良の方法だと考えています。
そういう意味で中長期の対策として以下に挙げるようなことが大切です。
- 前提となるマーケティングやウェブの基礎知識について、丁寧かつ詳細にとことん話し合う
- プロジェクト責任者の部署内での立場や他メンバーとの関係など、さまざまな事情(とくに力関係)を理解する
- その人の性格を把握するなど、その人に寄り添った丁寧なコミュニケーションを常に心掛ける
- 第三者としての客観的な視点を持ちつつ、プロジェクト責任者の立場に立って考える。そうすることで見えてくることが多くあり、A’案やA’’案、さらにはB案の策定のヒントにもなります。
- 上にも書きましたが、目標と目的のすりあわせはしつこいくらいにやったほうがいいです
これらは組織内のウェブ担当者じゃないと出来ないことでもあるので、企業にとって非常に価値のあることだとも考えています。あと、出来そうでなかなか出来ないと思うので、これが出来る企業は競合に対して大きなアドバンテージを得られると思います。
Advertisement
システム的に無理だから
僕が働く組織ではサイト制作と運営を担当する部署とCRM(カスタマー・リレーション・マネジメント)システムなどのシステム導入やインテグレーションを担当する部署(ここではシステム部と呼びます)が分かれています。なので、たとえばCRM関連のウェブへのインテグレーション・プロジェクトではシステム部の人たちと一緒に仕事をします。
そこでたまにあるのが、以下のようなシチュエーションです。
- システムでサポートされていないので対応出来ない
- ベンダーのサポートに問い合わせても答えが返ってこないので対応が難しい
組織内でそのシステムについて一番詳しいシステム部の人がそう言うんだから、しかもベンダーのサポートに聞いても答えが返ってこないんだから仕方がない…と、諦めてしまいそうです。が、ここはあえてウェブ担当者に粘って欲しいところです。
個人的に、技術的なことに関してはなんらかの解決策もしくは代替案が存在して、リサーチして検証すればかならず見つかると思っています。もちろん、想定した仕様のままでは達成できないこともあるので、その辺はフレキシブルな対応が必要です。
では、こういったシチュエーションでウェブ担当者になにができるのか?
- システム部の人より、そのシステムについて詳しくなる。システム部の人に教えてもらったり、自分で勉強したり。なにが出来て、なにが出来ないのか詳しく把握する努力をする。ドキュメントを読み込むとか。
- 周辺技術を勉強しておいて、常に代替案を提案したり検証してもらえるようなアイディアを持っておく
- Proof of Concept(概念実証とかプロトタイプ?)を作って代替案の可能性を見てもらう
ざっと思いつくのはこんな感じですが、やっぱりここでも大切なのはシステム部の人との丁寧かつ粘り強いコミュニケーションだと感じます。あとは、自分の技術的な知識・スキルと経験をどこまであげられるかも大切です。日頃の勉強が肝心になってきますね。勉強しなくっちゃ。。。
他媒体と表記の統一をしたいから
もちろん、クロスメディアで表記が統一されているのが一番の理想ですが、公開のタイミングやその他もろもろの事情により媒体ごとに表記が異なってしまう場合があります。あと、以前使っていた表記が最良ではなかった場合もあります。それでも、ただ統一するためだけに最良と思われる表記をあきらめるべきなのか?
否!ですね。
クロスメディアで表記を統一するかどうかは、以下の3つを基準に決めれば良いと思います。
- 想定するカスタマージャーニーマップでユーザの行動がメディアをまたいでいるのか。また、ユーザがメディアをどの程度往き来するのか確認する
- クロスメディアで異なる表記を目にすることでユーザに与える影響を検証する。影響が少ない場合は統一を諦める選択肢を考える
- クロスメディアで表記が違っていても、より露出の高い媒体で最良と思われる表記を使用する
まとめ
上にあげた3つのシチュエーション以外にも、ウェブサイトでのUXを壊しかねない組織的事情はたくさんあって、ウェブ担当者は日々対応を迫られます。ウェブサイトは企業とユーザとの1つの大きなタッチポイントでその役割は企業活動にとって大きな影響を与えます。そのタッチポイントでのUXが壊れてしまうと、サービスや製品全体のUXに与える影響は大きいです。
企業ウェブ担当者にあまり権限が与えられていない場合は特に大変ですが、ここで企業ウェブ担当者がどこまで粘れるかが企業活動の成功に大きく影響を与えると言っても過言ではないと思います。それだけ企業ウェブ担当者は責任ある、そして、価値のある仕事をしているのだと思います。
企業ウェブ担当者は企業を支える大きな力を持っているんですね。
頑張れウェブ担!てか、一緒に頑張りましょう!
2017年11月13日に公開され、2017年11月23日に更新された記事です。
About the author
「明日のウェブ制作に役立つアイディア」をテーマにこのブログを書いています。アメリカの大学を卒業後、ボストン近郊のウェブ制作会社に勤務。帰国後、東京のウェブ制作会社に勤務した後、ウェブ担当者として日英バイリンガルのサイト運営に携わる。詳しくはこちら。
ウェブ制作・ディレクション、ビデオを含むコンテンツ制作のお手伝い、執筆・翻訳のご依頼など、お気軽にご相談ください。いずれも日本語と英語で対応可能です。まずは、Mastodon @rriver@vivaldi.net 、Twitter @rriver 、またはFacebook までご連絡ください。
[…] 9. Tips:頑張れウェブ担!ウェブサイトの良し悪しはウェブ担当者の粘り強いコミュニケーションにかかっている この記事をRTする […]