本記事では、未経験の元エンジニアがヘルプセンターシステムのリプレイスでUX・UI改善に携わった話として、改善事例とそこから得た学び・反省について紹介しています。
はじめに
こんにちは、プラットフォーム事業本部 第一開発部 CSプラットフォームグループの小杉です。
私は2022〜2023年中頃にかけて、ヘルプ・問い合わせサイトとその管理システム（現：ヘルプセンターシステム）のリプレイスプロジェクトに携わりました。
本プロジェクトの概要に関しては以下の記事をお読みください。
https://inside.dmm.com/articles/new-helpcentersystem/
本プロジェクトにおいて、私は主にヘルプセンターシステムおよび管理画面のUX・UIの改善提案や関連部署との連携を担当しました。
これまではエンジニアとしてPHPのコードを書くことがほとんどでしたが、UX・UIに関して改善案を出し、中心となって改善を行うのは本リプレイスが初めてでした。
いろいろな挑戦をさせてもらえるのはDMMの良いところだなと感じます。
今回はリプレイス内で実施した改善事例と、そこから得た学びと反省点について、それぞれピックアップして紹介します。
改善事例について
今回のリプレイスでは軽微なものから大掛かりなものまで、いくつもの改善を実施しました。その中でもエンドユーザー向けの改善について以下3点を紹介します。
FAQサイトと問い合わせサイトの統合
リプレイス前ではFAQを集めた自己解決用「DMMヘルプ」と、カスタマーサポートに問い合わせるための「DMMサポートセンター」という2つのサイトが別々に存在している状態でした。
DMMには非常に多くのサービスが存在し、サービスごとにFAQ記事や問い合わせフォームが作成され、階層ごとにページが作成されていたために以下のような問題がありました。
- FAQで自己解決ができない場合に、別の問い合わせ用サイトに遷移した上で一から問い合わせ先を探す必要がある
- 本来、FAQを閲覧すれば問い合わせせずに問題解決できる可能性が高いのに対し、FAQを閲覧することなく問い合わせに至ってしまう
そこで今回のリプレイスでは、ユーザー側の不要な回遊やアクションの手間を減らすことを目的に「DMMヘルプセンター」として2つのサイトを統合することにしました。
DMMヘルプセンターでは、ユーザーが困った際に先にFAQ記事を閲覧してもらい、その上で自己解決ができなかった場合に問い合わせフォームへ遷移できるようなサイト構成となっています。
FAQ記事の統一
リプレイス前では、「DMMヘルプ」のFAQ記事はデバイスごとに内容を書き分ける必要がありました。具体的には、スマートフォンで記事を閲覧した際にはスマートフォン向けの情報のみが表示され、パソコンで閲覧した際にはパソコン向けの情報のみが表示される状況が存在していました。
これは、過去にDMMにフィーチャーフォン（ガラケー）用のサイトが存在していた頃の名残で、フィーチャーフォン用サイトは現在閉鎖されています。
またパソコン用とスマートフォン用のサイトでは同じサービスが提供されています。
そのため、同一ユーザーによる複数デバイスの使い分け傾向の高さや、FAQ記事を閲覧するデバイスと実際にサービス利用に用いるデバイスが異なる可能性も考えられるようになりました。
パソコンやスマートフォンに限らず、現代ではさまざまなデバイスが市場に出ており、“デバイス間で情報共有”のニーズが高まっています。
一部のDMMサービスでは、テレビやPlayStationといった多様なデバイスを介してサービス利用できるようにもなっています。
そこで新しいヘルプセンターにおいても、「どのようなデバイス環境下であっても、ユーザーは同じ情報を得ることができる」ことを目的とし、デバイスごとに存在していたFAQ記事を統一。1つの記事の中でサービス提供がされている全てのデバイス情報が得られるような構成に変更しました。
ライティングルールの統一
「DMMヘルプ」の管理システムでは、ヘルプ記事の作成のために書式設定用の多様なプラグインが存在し、またHTMLを直接編集できるWYSIWYGエディターが提供されていました。
このエディターは自由度が高く、さまざまな表現が可能なために書き手によって表現方法が異なることで、統一感に欠けたヘルプ記事を生み出してしまっていました。
またどのケースで、どのようなスタイルを当てるかという“見た目のわかりやすさ”に関しても、書き手のスキルに委ねられていました。
さらに自由なエディターで作成される記事は、ウェブアクセシビリティの観点からも課題を生みやすくなります。その例として、表が複雑に結合されて表現されてしまうことで、スクリーンリーダー等の視覚的な支援技術を用いるユーザーの理解に影響が出るケースがありました。
これらの事象は全て、ユーザーにとって記事内容の理解が難しくなるという問題に帰結していました。
記事を書く際のライティングルールをまとめた資料もありましたが、人力で全てを統一するのは難しい状況でした。
そこで、今回のリプレイスでは少しでもそこの負担を減らし、ライティングルールが統一できるようにエディターのカスタマイズも行いました。
「Tips記載用」「注意喚起用」といった形でスタイルを用途ごとに用意し、HTMLの直接編集を禁止することで誰が記事を作成してもスタイルに差が出ず、ウェブアクセシビリティにも準拠した形のエディターに一新しました。
これにより、記事の表現方法のばらつきやウェブアクセシビリティの問題、そして作成者のスキルに左右される“見た目のわかりやすさ”といった課題を大幅に改善することが可能となりました。
リプレイスにおける学びと反省
利用者の声をいかに反映していくか
DMMヘルプセンターの管理画面の設計をしていたときの話です。
DMMには複数のカスタマーサポート部署が存在しており、ヘルプセンターの管理システムはそれらの部署により利用されています。
UIの設計段階では、GoogleやSlack等社内で使い慣れたシステムのUIを参考に組み立てるように意識したり、根拠となる事例を探して設計を進めたりしました。
そうして作られたUIを元に管理システムの利用者にフィードバックを依頼した結果、各部署で相反する意見や要望があることだけでなく、広く使われているツールを参考にして設計したという理由では相手の納得を得ることが難しいこともわかってきました。
管理システムの利用者からの要望をそのまま受け取るのではなく、その背後にある真のニーズを把握し、その解決のために最適なアイデアを導き出すスキルの重要性を感じました。
「他のツールがそうだから」と主張しきるのではなく、「なぜそのUI設計が適しているのか」を明確に理解した上で、その理由を利用者に具体的に説明できればスムーズに理解と納得を得られたと思います。そういった気づきは得られたものの、これらのスキルに関してはまだまだ勉強不足です。
引き続き、より良いUI・UXを追求してまいります。
データ移行の手間から学ぶ設計の重要性
改善事例として記載したFAQ記事内容の統一やライティングルールの統一にあたり、既存の記事に関しても内容の統一を行い、新しいエディターに沿ったルールとなるようにHTMLの置き換えを行いました。
今回私たちが再利用したかったのは記事の文面そのものであり、その文面に付随するスタイル等の表現方法ではありませんでしたが、無秩序に作成された旧記事のデータには独自のJavaScriptが埋め込まれていたり、CSSが直接記載されていたりしました。
FAQ記事は3000件以上存在しており、かつ規則性のないものが多かったこともあり、スクリプトを利用した自動置き換えに全てを任せられず、手動で1つずつ記事を修正する作業に約1.5人月を要しました。
データ作成の自由度が高すぎることは前述したユーザビリティに関する問題点のみならず、生成されたデータの再利用の容易さという観点からも大きな問題を生むことを身をもって実感しました。
QAチームとの連携に苦戦
案件内で私の業務の1つであった関連部署との連携には、QAチームとの調整が含まれていました。
検証担当のQAチームへの仕様共有は、ある程度実装が進んだ段階からFigmaに起こしたデザインやユースケース図といった画面仕様書をベースに行っていました。
ところが、メール送受信システム等の画面に現れない仕様の共有漏れにより検証が抜けてしまう部分がいくつもありました。
検証が漏れた部分では、リリース後の不具合が頻発し、結果的に利用者であるカスタマーサポートメンバーの手を煩わせることにもつながりました。
QAチームはUIだけでなく、さまざまな観点からテスト項目に関する提案をしてくれるものの、開発側からの情報共有がないことには進みません。
そのため、もっと早い段階からQAチームと連携し、仕様の検討段階から会議に参加してもらうなど細かな情報共有を行うべきであったと感じました。
さいごに
大規模リプレイスにおけるはじめてのUI・UX改善で、個人としては達成感とともに反省点も多いプロジェクトとなりました。
また、今回のリプレイスは技術負債からの脱却に焦点が当てられたこともあり、リプレイス内では実現できなかった改善も多くあります。
そのため脱却が完了した現在でも、CSプラットフォームグループではヘルプセンターに関わる多くの機能改善を実施しており、今後もたくさんの改善を予定しています。
DMMヘルプセンターの今後にご期待ください！
最後までお読みくださりありがとうございました。
