テクニカルサポートチームは来る日も来る日も、ユーザーの課題に対処しています。彼らは製品に関する問題の最前線の業務を担っており、不満を抱えた顧客のエラーを修正したり、戸惑うユーザーをなだめたりしています。ではなぜサポート技術者は、UXのリソースとしてめったに活用されないのでしょうか？
あらゆる製品において、完璧なものはありません。それはユーザーも同じです。技術的に不完全なものやユーザーエラーは不可避であり、これらを対処するのもサポートチームなのです。パスワード紛失やアプリのリセットなどのすべての些細なものの中において、テクニカルサポートチームはユーザーインサイトの宝庫の上に頻繁にいるのです。いまこそサポートチームに注目すべきです。
開発チームが陥る落とし穴
製品をつくった開発者やデザイナーにとっては、製品を使うのは非常に容易です。製品の欠点や障害を発見するのは、制作サイドの視点では難しいかもしれません。ユーザーが新しい技術とインタラクションする際、自分たちと同じように楽観的であるという保証はないのです。
ユーザーは疑問や混乱、不満、要望を抱いているでしょう。その代わり、Michael McWatters氏の文言に、「実際の人間は、デザインや開発の過程で特定できなかった問題にさらされるでしょう。どのような優秀なチームであっても、陥る可能性のある落とし穴のすべてを予測することはできません。」というものがあります。
この落とし穴は高くつきます。著書『Software Engineering: A Practitioner’s Approach』の中で、Roger Pressman氏は製品デザインにおける問題を解決するためにかかるすべての費用を計算しています。これによると、同じ課題であっても、開発中であれば10ドルで済むものがリリース後となると、100ドルかそれ以上かかるそうです。
残念ながら、私たちがいるのは完璧な製品開発の世界ではありません。大抵の場合は、製品がリリースされたあとにユーザーが課題とユーザビリティの問題を発見することになります。そしてこれらの問題は、のちのアップデートやバグ修正の中で対処されます。失敗と修正の終わりなきループです（これは必然的なようにも見えますが）。
テクニカルサポートの役割
テクニカルサポートの役目は、これらの火消しをあちこちで行うことです。テクニカルサポートは電話を受け、チケットを管理し、ライブチャットでの応対をし、技術に関するメールを処理します。さらには、不満なユーザーにソリューションを送信し、ブランドへの信頼を取り戻すという重要な責任があります。
このプロセスは、私たちが想像する以上に日常的に起こっています。Gallupの調査によると、6カ月以内に問題を報告してくる顧客は10人中６人いるそうです。これは製品の問題に関する氷山の一角に過ぎないかもしれません。なぜなら苦情１件に対して、27人ものユーザーが不満をもちながらもなにも報告しないそうです。
テクニカルサポートは多忙な仕事です。長時間の勤務であるのがほとんどでしょう。ユーザーとハイレベルなインタラクションを行っているのは、テクニカルサポートチームだけだと言っているのではありません。セールスやマーケティング、カスタマーサービスなどすべてのチームが、エンドユーザーとの接触で欠かせない役割を担っています。そしてすべてのチームがユーザーの知見をUXの議題に持ち込んでいます。
しかし製品の核心部分を熟知しており、またユーザーがどのように対応しているかを理解しているのはテクニカルサポートチームです。ユーザーの技術に関する不満、ドキュメントのバグやエラーに対して、サポート技術者は耳を傾けます。そしてソフトウェアの面において、ユーザーが苦労している部分を段階的に説明していきます。テクニカルサポートチームは、エンドユーザーと開発者の中間の人であることが多いです。両者の見識を理解し、仲介をします。
間違いをカバーする
行き詰ったユーザーのサポートにおいて、技術者は製品における多くの間違いをカバーします。ユーザーがあなたのソリューションを購入し、そのセットアップですぐに行き詰まってしまったとします。ユーザーはあなたにバカにされたと憤り、直ちに製品を捨ててしまうでしょう。
優秀なテクニカルサポートがないと、新規の顧客をすぐに失ってしまうでしょう。おまけにネット上でひどいことを言われるかもしれません。しかしテクニカルサポートが優秀であれば、ユーザーを満足させて引き戻すことができるでしょう。製品の不十分な点をカバーするのに役立ちます。実際に78％の人々が、サポートの対応を理由にブランドやサービスを購入しています。
こう考えてください。あなたの製品は際立ったものがほとんどありません。ユーザーは競合相手の製品を選ぶ可能性があります。すべての製品は、同じような性能とセールスポイントをもっています。サポートの対応が健全であれば、サポートがユーサビリティの面で劣る製品とユーザー感において接着剤の役割を果たします。そして開発者が最適化を行う間に、ユーザーを保持することができるのです。
組織の分断
私たちは製品の欠陥を、単にデザイナーや開発者のせいだと言っているわけではありません。UXの最適化という開発者のタスクは、なかなか容易ではありません。結局、顧客と会話をする機会が開発者にはほとんどないのです。彼らは技術的な要求のリストを渡され、決められた時間枠でコーディングを課せられます。
プログラミングに集中する日々の中で、エンドユーザーから声を聞く機会はほとんどありません。開発者は使用中のソリューションを作成する一方で、通常は自分たちの仕事がユーザーを満足させているのか、あるいはいらつかせているのかを知る機会がないのです。
実際にあるソフトウェアのプロジェクト報告によると、技術に関するプロジェクト要件が、企業との調和を欠くと回答した作業員は78％でした。さらに45％が、関わっているプロジェクトの経営目的が不明瞭だと答えています。
この組織の分断（サイロ化）は、ソリューション作成として悪い状態です。企業は人間中心の製品の作成に努めます。ソフトウェアは、購入した人にとって有益で便利なものでしょう。しかし製品が中心としている人と話さないのであれば、果たして開発者は人間中心の製品を作成することができるのでしょうか？
成功へのチケット
この論点は、私たちをテクニカルサポートチームの真正面へと導きます。テクニカルサポートチーム行きの多数のチケットには、ユーザーインサイトが詰まっています。ユーザーインサイトは、開発やデザインチームにもフィードバックされるべきです。
たとえば特定の機能でよくみられるユーザーのエラーは、その機能に関するユーザビリティの再検討が必要であるという明確なサインです。同様に、繰り返し起こる機能の要求は、その製品の将来的な価値をどう高めることができるかを指し示しています。ソリューションの新たな追加に関する苦情は、UIの微調整や機能の変形の防止に役立つでしょう。その一方で、ユーザーから共通に称賛される部分があれば、なにをずさんに扱ってはいけないか理解するのに役立ちます。
これらすべてが有益なものですが、残念ながら大抵は単独部門の中でしか保有されていません。簡単に言うと、このような率直でフィルターのかかっていない批判こそが、ユーザーと離れたところにいる開発者には不可欠なのです。ユーザーをなだめることにおいてテクニカルサポート部門が貴重であるのと同様に、開発者も製品の問題を決定的に解決する手がかりをもっています。
端末相互間の連鎖
著書『The Conversation Engine』で、Nathan Walters氏はこのように書いています。
ユーザー体験とは単なる製品や機能、インターフェイスなどではありません。それは実体験のように感じる、端末相互間の価値連鎖なのです。
これを考慮に入れるにせよ入れないにせよ、この価値連鎖はエンドユーザーに対してだけでなく、内部でも展開されるものです。そのためこの連鎖は、ユーザーとサポートの間やサポートと製品部門の間をしっかりとつなぐ必要があります。
プロジェクトのデザイン業務に、経験を積んだ技術サポートをステークホルダーとして巻き込み、アドバイスをもらいましよう。また素晴らしい体験のために、開発者がカスタマーサポートの声を聞く定期的なセッションを取り入れてみましょう。技術チームで集まってみたり、単純にUXに焦点を当てた定期的なフィードバックのミーティングを開いたりすることもできるでしょう。
いずれにせよ、実際のユーザーインサイトを開発チームにも還元するフィードバックの連鎖を設けましょう。そうすることで、エンドユーザーとそのニーズにより鋭い焦点を置いた、協調的な環境をつくることができます。
最後の決め手
ほとんどのテクニカルサポートチームが正当に評価されていないと言ってもよいでしょう。UXに関して言えば、補足部かあるいは省略されています。これはもったいないアプローチで、実際のユーザーリサーチの日々の流れを無視しているということでもあります。
どのように見なすにしろ、テクニカルサポートは優秀なUXの中心的な側面です。まず第一に、行き詰ったユーザーの体験を改善して、混乱を解消する手助けをします。その上、さらにテクニカルサポートは、ユーザーと会話をし、良い点・悪い点両方のフィードバックを収集するための完璧な方法です。そしてさらに言うと、テクニカルサポートは将来のユーサビリティ向上も担います。
サポート技術者は、単なるクレーム処理係以上のものです。UXに関して言えば、彼らは成功の決め手となる存在なのです。
