見出し画像

【DIST:管理画面から考えるUX】勉強会レポ

久々のオフライン勉強会への参加したので、そのレポをば。LT4本とメインセッション2本の構成で、スピーカーの皆さんの会社の事例をもとに管理画面UXに関する学びや工夫について話を聞くことができた。

Cosense(旧Scrapbox)で実現するコンテンツ管理画面

株式会社Helpfeel CTO 秋山 博紀(AKIYAMA Hiroki)

Helpfeelさんの管理画面(CMS)において、解決したかった課題としては以下のようなポイントであったと思われる。

  • プロダクトごとに様々な個別ニーズがあるが、一方でベースとなる立ち上げ時の機動性は損いたくない。

  • 毎回フルスクラッチで作るのは作業コストが高すぎる。

そこで、企業向けの機能としてカスタム機能(=プラグインのようなイメージ)を実装して、基本の機能の機動性を確保しながら個別のニーズに対応できるように拡張性を持たせた。


管理画面における反復操作のUXを突き詰めた話

株式会社CRUTECH リードデザイナー 堀田 愛子(HORITA Aiko)

CRUTECHさんでは外国人の在留証明を登録する作業がUXの中に存在するが、これは毎月発生する業務らしく「できるだけ簡略化したい」というのが今回のニーズ。

行政の用意したデフォルト画面は専用画面で1件づつ登録する必要があるが、作業者は毎月複数件の登録を行う必要があるので、いかに慣れていても1件につき90秒かかってしまう。

そこで作業対象がリスト化されている自社の管理画面と並列で行政の登録画面を表示させ、リストでの作業管理と登録作業を1画面でできるようにした。
また、視線移動を極力減らすために画面の右側で重要な操作が完結するよう設計。

結果として90秒かかっていた操作を30秒へ短縮成功。とはいえ、スピード重視になると誤操も増えてしまうため、取り返しのつかない操作については2人目の確認担当による承認制へ。

前提として、中級者向け(特定の人が利用頻度高く使う)サービスのため、「いつも使う人が効率よく使えることにフォーカスした」というUX設計とのことだった。


管理画面の全体UXは利用時品質モデルで考える

株式会社まぼろし インターフェースデザイナー 松田 直樹(MATSUDA Naoki)

管理画面の着眼点として「好きで使っている人いない」というポイントから話ははじまる。だいたい、組織の決済者や役職のある人が「これ使って」と実際の作業者に依頼することが多い。1番よく管理画面を使う人は、好きでそのサービスを使っているわけではないのだ。

そこで、いい体験は作れないが価値のある体験をどう作れるか?と考えたときに、エンドユーザーにとってのそれは「面倒なことが早く終わること」だ。

その方法の一つとして、品質を担保することを紹介。確立された規格であるSQuaRE(Systems and software Quality Requirements and Evaluation:国際規格のISO/IEC 25000シリーズ、国内企画のJIS X 25000シリーズなどが含まれる)や利用時品質の重要指標およびその測定などの紹介があった。

好きで使ってるわけではないサービス、せめてエラーのない使いごごち(品質が担保された利用体験)で製品としての価値を高めようという話。


オペレーショナルエクセレンスの実現に向けた管理画面の改修

株式会社マイベスト バックエンドエンジニア/Opex開発リード 井上 周(INOUE Amane)

ここで取り扱った管理画面開発での課題は主に2つ

  • 現場からの要望ベースだと、どうしても下請けっぽくなってしまう(現場の温度感で優先度が決まってしまい、改善時の効果測定が難しい)

  • ユースケースごとに個別最適をしてしまうと競合する変数が現れたりして困る。

そこで、開発チームが主体となって仮説検証をまわすという取り組みの紹介がされた。複数の改善指標を定め、改善の案を出すところから、それを検証可能な要素にまで分解して、実装を行う。またそれを事業部側と共通認識を揃える。

これができたらかなり地に足のついた改善ができそうだと感じた一方、ここまでやるには相当な労力がかかりそうに感じた。LT時間が限られていたためサラッとした共有だったが、社内でフレームワークとして確立されているならば詳細が気になる。


効果的な管理画面を最短でデザインをするために避けるべき5つの罠と対策

Ubie株式会社 デザインエンジニア 大木 尊紀(OHKI Takanori)

管理画面デザインにおいて、避けるべき5つの罠と対処方が紹介された。

1) 既存のオペレーションに引っ張られすぎる問題

現場の人に話を聞くと「今まではこうやってたので」という前提で、改善できる部分を見逃してしまう。ゼロベースでオペレーションの目的を整理して、全体の設計から入っていくことが重要だ。

つまり、オペレーション自体をデザインするところからUXデザインは始まっているのだ。改善後のオペレーション体制で教育コストや利便性のバランスを見ながら、1番インパクトがありそうなところから改善していく。

2) オペレーターのマインドとデータ構造が一致しない問題

エンジニア視点では、データ構造を考えていると利用者の視点が抜けがちになるとのこと。「データ構造的にはこっちの方がすっきりするよね〜」っと思って作ると、UIにしたときに不都合が出てくることがしばしば。つまり、オペレーターのメンタルモデルとデータ構造はある程度一致している必要がある。

データ構造がオペレーションに耐えられる作りになっているのか?
初期の開発だと有識者を巻き込めないことも多く、UIを作ってからだと開発が遅くなったりもする。ということで、まずはオペレーション、メンタルモデルの整理からエンジニアも入る。そして逆にデザイナーもデータ構造が耐えられる作りになっているか確認する必要がある。1エンティティ1画面にこだわる必要はなく、メンタルモデルに合わせて1画面で複数のエンティティをまとめて表示したりCRUD可能にするのもあり。

3) 階層が深くなりすぎて今どこにいるのかわからない問題

これにはナビゲーション設計が肝。グローバルナビゲーションからどこでも行けるし、子ページから逆検索ができるようにする。階層ツリーで考えた時に、上から下に向かって検索することもあるし、下から上を検索できるようになっていると効率が上がる。ただし、これはユースケースにもよるのでオペレーションによっては必要ない場合もあるとのこと。

4) Tableの呪縛から逃れられない問題

管理画面では気を抜くと全部テーブルになってしまうことがある。Railsだと特にそうなるとのこと。

Tableの問題は情報の強弱がつけられないことである。重要度の同じ情報をいっぱい並べたい場合や、見る人によって必要な情報が変わるので強弱がつけずらい情報群などはTableが向いているが、情報の中で優先度をつけたいものがある場合はTable以外の表現方法が良い。

5) 汎用的に作りすぎて誰も使い易くない

みんなの願いを叶えたい!いろんな人が使うからみんなの願いを詰め込んだ結果、「誰にも使い易くない」ものができてしまう。1番重要度の高いユーザーが誰なのか明確にしてUXを設計する必要がある。管理画面で言えば、1番ミスをされては困る人などは重要度が高いだろう。企業の管理画面では操作ミスで数億円の損害が生まれる場合もある。必要であれば画面やプロダクトを使う人によって分けるのも手段になる。


行政職員が「ふつうに使える」をめざした管理画面のUX設計とデザインシステム推進

株式会社グラファー デジタルプロダクトデザイナー 佐野 彩、デザインエンジニア 松倉 千春(SANO Aya、MATSUKURA Chiharu)

スピーカーの佐野さんは、メインユーザーが行政であるプロダクトの開発に2022年に途中参入したが、その時点で以下のような課題があった。

  • ユーザーのビジネス課題:DX投資したいが普段の業務が忙しく後手に回っている

  • ユーザーの使い勝手課題:プロダクト利用時の作業負荷と学習コストが大きい。

  • IA:情報設計の整合性がとれていない。

  • 実装面:アクセシビリティ対応が困難なフレームワークを利用していた。

このように多方面から課題があったため、これらを解決して「ふつうに使える」を目指した、いわば王道的な改善の流れを紹介。

管理画面開発のあるあるだが、利用者のドメイン知識ありきの体験設計なので、デザイナーは情報をとりに行かなくてはならない。書籍や社内知見として既存の2次情報はもちろん、可能なら1次情報をとりにいくこと。

ペルソナごとにペインを整理し、ユーザーが異なっても共通利用できるようにOOUIで用件を整理する。ワイヤーフレーム、HiFiプロト、ユーザーテスト、と一連の流れで改善を重ねる。王道フローを堅実にやったおかげか、大きな軌道修正も起こらずにデザインFixへ。

また、開発して終わりではなくデザインシステムの運用を続けていくのも重要なことである。新コンポーネントの実装フローや社内布教など、プロダクトの拡張と社内利用の両方面から持続可能なデザインシステムを目指した。


Harmonia/私としてのTake(学び)

さて、今回の勉強会で自社のUXデザインに活かせそうな部分を考えてみる。

UIで言うと、堀田さんの既存の外部サービスの画面をプロダクト利用時に表示するというのは斬新だった。これは行政のサービスを利用するために他に選択肢がなかったという産物なのかもしれないが、既存の外部サービスをiFlameみたいにプロダクト上に埋め込める方法があれば、自社でスクラッチからデザインを考えるより、工数の短縮およびMVP検証に役立ちそうだ。一方で、自社デザインのトンマナが崩れてしまうリスクもあるので(例えば、情報の優先度設計が崩れるなど)、使える場所が限られたり、多少はデザイン調整を工夫したいところではある。

あとは秋山さんのユーザーごとに拡張機能を提供すると言う話。私としては実際の提供方法よりも概念の応用にメリットがあると感じた。ユーザーごとに全く違った機能が求められる場合は、これを個別のアップグレード要素として外部モジュールのようなプランを用意しておき、その接続数によって課金体系を調整できるといいなと。ビジネス的にもユーザーは必要ない機能にお金を払わなくていいし、逆に必要な機能に見合ったコストをかけられるので支払いへの納得度も高いだろう。特にマシンパワーが必要になる機能ではその恩恵が大きい。お金をかけられないユーザーの利用ハードルを下げ、本当に機能が必要なユーザーに納得度の高いサービス提供ができるだろう。

そのほかで今回の勉強会の特筆すべき点は、デザイナー以外の登壇が多かった点だと思う。とくに技術者、CTOやエンジニアからの話も聞けて、彼らのもとめるデザイナー像や、UXまで一歩踏み込んで考えてくれるエンジニアのありがたさが垣間見れた。今日の内容をきっかけに社内のエンジニアと意見交換したいと思った。そういう話を通して、逆に弊社にあって他社にない強みなんかにも気がつけるかもしれない。


Harmonia/私としてのGive(今テーマでの私事例)

もし私が「管理画面とUX」というテーマで知見共有をするとしたら、どんな話ができるだろうかと考えた。いくつかパッと思い浮かんだのはこの辺だ。

  1. ユーザーと共に成長する管理画面:ユーザーの課題を解決していたら、新しい世界と課題が見えてきた話(これは0→1ならでは)

  2. 管理画面と心理ケアのUX:欲しい機能はたくさんあるが、プロダクトから伝えたいメッセージは何か?ユーザーをポジティブに導いてあげるためのUX設計の話(脱:やらされ感)

  3. キッチンの設計で考える管理画面のMVP:MVPをたくさん作ってみて、車と自転車の絵では腹落ちしなかったから、独自のキッチン理論を展開するぜ。

かなり主観的というか、ハルモニアのユーザー体験の持ち味…?から独自に生まれた小話や私個人の体験が実はたくさんある。言葉で説明しずらい体験設計のTipsや、新しい発見を求めている人の何かのヒントになるかもしれない。

もし、この中にみなさんの気になるネタがあったらいつかどこかで話してみたいな。詳しく聞きたいものがあったらぜひコメント欄で教えてください。

それでは、管理画面から考えるUX勉強会のレポでした。

サポートがあったら書籍購入や勉強会参加の資金にさせていただこうかと思います。先人の知識をたくさんの人へ広める潤滑剤になれれば嬉しいです。