はじめに
こんにちは、EXNOAブラウザプラットフォーム部デザイナーの穆です。DMM GAMESオンラインゲームプラットフォームのUI/UX改善を担当しています。
今回はスマホブラウザゲーム画面について、他職能のメンバーを巻き込んでサービスや機能改善を行った事例を紹介します。
スマホブラウザゲーム画面改善案件について
スマホブラウザゲーム画面とは、DMM GAMESスマホプラットフォーム内のゲームを起動してプレイする画面のことを指します。
ブラウザでもアプリのように没入感の高いプレイ環境を実現できるように、アプリのUIを調査・分析し、ユーザー体験向上とMAU・継続率向上の2軸で改善を始めました。
改善を実施した際に、ユーザーテスト・ABテストなどの定量定性手法を利用し、ユーザー視点で既存機能仕様の問題点を抽出してから、PDCAで改修を実施しました。
なぜ他職能のメンバーを巻き込んで改善を実施したのか
「UI/UX改善」という言葉を聞くと、デザイナーの専門領域として、デザイナーだけの仕事だと思われる方も多いと思います。
ただ、実際にサービスや機能の改善を実施してユーザー体験を向上したい場合には、デザイナーだけではなく、ディレクターやエンジニア、カスタマーサポートなどの様々な職種のメンバーの意見を集めることで、課題点を幅広く洗い出し、解決策を検討する必要があります。
実はスマホブラウザゲーム画面改善の初期段階では、主に画面UIやレイアウトの角度でパターンを作成して効果検証を実施していました。
しかし、ユーザーがスマホブラウザでゲームをプレイした際には、UI だけではなく、ゲーム画面読み込みスピードやプレイ履歴導線設計などのニーズもあるため、デザイナーの視点だけでは限界があると痛感しました。
他職能を巻き込み客観的にサービス全体を俯瞰して、課題の認識合わせや因果関係の整理を行い改善策を検討した方が、スピーディーな改善を回すことができ、ユーザーによりクオリティ高いサービスを届けられるのです。
他職能のメンバーを巻き込んで改善する取り組み
他職能のメンバーを上手に巻き込んで一緒に改善を行ったときに、意識して行ったことを4つ取り上げます。
【1】共通言語を作って会話する
スマホブラウザゲーム画面改善を実施した初期に、職能によって各機能やUIパーツの名称の呼び方が異なることに気付きました。例として「ゲーム画面」の呼び方であれば、「実行画面」「ゲームプレイ画面」「ゲームUI画面」のようにさまざまでした。これによって、改善内容のすり合わせの際に認識齟齬が発生しました。
そこで改善にかかわるメンバー全員が共通言語で会話するために、サービス機能から細かいUIパーツまで、ユビキタス言語を図解付けて整理しました。
ユビキタス言語によって同じ呼び方で同じ認識を得ることで、コミュニケーションミスを減らし、改善内容のすり合わせ及び意見のヒアリングが円滑にできるようになりました。
【2】理由を明記して提案する
改善提案を作成する際、多くの場合でデザイナーとディレクター・マーケティングプランナー間ですり合わせした後に、エンジニアに共有して実装してもらう流れで進行しています。その際、エンジニアは改善提案の意図や根拠が把握できず、最適な実装を検討するのに時間がかかることがありました。
そこでスマホゲーム画面UIを改善した際に、職能関係なく全員集まって提案の説明をした上で、エンジニアへ提出した提案資料にも詳細のデザイン意図・考慮要素および、改善につながる仮説を記載するようにしました。
ユーザーが見た画面UIそのものだけでなく、ユーザーが画面UIを見て体験させたいこともあわせて他職能のメンバーに伝えることで、お互いに理解し、最適な対応を行うことができました。
【3】検証結果を可視化して共有する
どのようなスマホゲーム画面UIがユーザーにとって一番わかりやすく、使いやすいのかを判断するため、ユーザーテストとAB テストを実施しました。
テスト実施後の結果を他職能のメンバーに共有して、一緒に分析・課題抽出を実施した際に、「この数値はどこをタップした数値ですか？」「この結果の見方がわからない」「この2つの数値を比較する理由は何ですか？」等々、質問が集まりました。
こうした際、短期案件であればその場で内容を説明してディスカッションを行うことができますが、長期改善プロジェクトの場合は関係者全員が、各計測対象の確認と結果の判断基準を把握しないと、改善を実施しても評価できず、PDCAがうまく回りにくい懸念があります。
そこで、FigmaやLooker Studioなどのツールを利用して、改善実施中、ウォッチしないといけない数値・画面遷移および各指標の評価基準情報などをまとめて可視化しました。これにより、定量定性手法やGAなどのツールの使い方を詳しく知らない他職能のメンバーでも、内容を見て結果考察を行うことができるようになりました。
他職能のメンバーと結果を検証したり、わいわいと議論を重ねながら次の課題を抽出し、解決策を検討することで、改善全体の回転スピードも上がりました。
【4】実現したいイメージの認識をしっかり揃える
長期改善案件では、改善目的から外れないように、定期的に実装された仕様の見直しを行いました。その際に、仕様変更意図や実現したいイメージの認識すり合わせもあわせて実施します。
例えば、ゲーム画面メニュー内の「最近遊んだゲーム」導線設置場所を変更する場合。
「導線をメニューの一番上に移動したい、代わりに上部ある〇〇導線を下に移動する」のような伝え方だと、開発メンバーが実装対応した後に、どんな課題を改善するための物だったのか、それが実現できるようになったのかがわからないため、改善効果を評価した際に判断しにくくなります。
一方で、「ユーザーが最近遊んだゲームへの関心が高い傾向にあるため、メニューを開いた際にすぐ直近の履歴を見つけるように、導線を一番上に移動したい」「〇〇導線は下部にあるコンテンツとの繋がりがあるため、下部に移動…」のように、何のために改修したか、どんなイメージを実現したいかを伝えると、対応優先度や実装周りの調整もしやすく、効果評価を実施した際にも参加して一緒に考察できるようになります。
まとめ
デザイナーは常にユーザー・ビジネス・開発視点で、現状に存在する課題や望んでいるビジョンに基づき、デザインを調整して作成します。
以前はよく「職能が違うと全く見当が付かない」という言葉を聞きましたが、デザイナーの「問題を可視化する・情報を整理してまとめる・根拠を持って改善を進める」特性を活かして工夫することにより、職能が異なっても共通言語で会話でき、同じ目標に向かって一緒にわいわい開発を進行できるようになりました。
異なる職能同士で連携して開発を進めることは当たり前と思う人もいるかもしれませんが、今回紹介した取り組みの中に一つでも参考になれば嬉しいです。
最後に、EXONAブラウザプラットフォーム部では、今回のようにユーザー視点から定量定性手法を活用し、全職能連携して新規機能開発や既存機能改善を日々行っています。
他職能のメンバーと常にコミュニケーションを取り、お互いに良い影響を与えながら開発することに興味のある方は、ぜひ以下の募集ページをご確認ください。
