はじめに
はじめまして。
ARIでUIデザイナーをしているアンビルと申します。
私はこれまでWebサイト、LPのデザインとコーディング経験が中心でしたが、ARIに入社して業務システムのUIデザインに携わるようになりました。
最初に感じたのは、「考えること・やることがこんなにWebデザインと違うのか…！」という大きなギャップでした。
この記事では、タイトルの通り私自身が業務に携わって驚いた話をしています。
基本的には、私と同じようにWebデザインからUIUXデザインに転向していたり、UIデザインや業務システムの開発経験が浅めのデザイナーに向けて書いています。（開発経験が浅めのエンジニアにも参考にしていただけると思います。）
私の体験が、少しでもヒントになれば幸いです。
業務に携わって驚いたこと
ここからは、実際に業務に携わって驚いたことと、そこから学んだことをご紹介します。
１．一見シンプルでも、考えることが想像以上に多い
初めての案件で金融系システムの一覧画面を作成していた時のことです。
苦戦しながらも何とかテーブルデータを作成し、先輩に提出しました。そして確認していただいた時に質問をされました。
「この画面、幅が広くなったら各項目の見え方はどうなりますか？」
その時に、初めて作成時の画面幅だけを考慮して作成していたことに気づきました。テーブルって、何となくシンプルなデータのイメージがありませんか？しかし、実は考えるべきことが沢山あります。
これまでに携わっていたWebデザインでは、画像をきれいに見せたり、幅に合わせて見せ方を調整するなど、主にビジュアルの作り込みや整えることをメインに作成していました。そのため、同じように「見た目を整えれば成立するもの」という感覚がどこかにありました。指摘されてはじめて、その感覚でいることに気づきました。
画面幅が変化することがわかっていても、その際にどの列を固定にするか、どの項目がどう変化するか、増減する可能性があるか等、それぞれのデータにも影響が出ることまで考えが及んでいなかったのです。
具体的な例を挙げると、
- 0件表示の場合、反対に何千件もある場合はどう表示されるのか
- 並び替え機能や絞り込み機能は必要なのか、どのような機能でどこに配置するのが適切か
- 各データの文字数が多くなったらどう表示するのか
では、どのように考える必要があったのか。
情報量が多い場合、ページを分けるのかスクロールで読み込むのか。情報をわかりやすくするために、検索・並び替えなどの機能をどこまで用意するか。文字数が長くなった場合は省略・折り返しなどで調整するのか…など、より細かく意識する必要がありました。
それぞれの列は、文字数、幅、項目の並び替えなど、参照と同時に操作対象でもあり、項目自体も増減したり変化する可能性があります。ユーザーはテーブルに並んでいる情報から、必要な情報を探し、確認し、そして必要に応じて追加、編集、削除などの操作をすることもあります。
またシステムによっては、数万〜数十万件といった大量のデータを扱うこともあります。データ量が増えても破綻せず、ユーザーが迷わず操作できることを視野に入れる必要があると感じました。
テーブルのように一見シンプルに見えるパーツや他の画面でも「きれいに見せる」だけでは不十分で、ユーザーが実際に参照、操作する前提で設計する必要があると学びました。
2.ボタンのバリエーションが多い
こちらも初の案件で金融系システムの画面をデザインしていた時、エンジニアからこんな質問を受けました。
「読み込み中のボタン表示はありますか？」
その時は、「その状態のボタンを考えることすら想定していなかった」 という状態でした。（この時はエンジニアにコーディングで対応していただきました。）
Webデザインでは、ボタンは「必要なときに一回押されるもの」という感覚があり、状態も hover や disabled を考えておけば十分な感覚でいました。
Webサイト等でも業務システムと同様に、マウスやキーボード操作が行われる場面は多くありますが、業務システムでは同じ操作を何度も繰り返すことが多く、操作頻度や効率をより強く意識する必要があると感じました。
具体的な例を挙げると、
- データ量が多く、保存や送信の処理に時間がかかる場合がある
- 同じボタンでも選択と選択解除など状態を切り替えるケースもある
こうした場面では、きちんとボタンを選択できているのか、押した後で処理中なのか等、「今どんな状態なのか」が分からないと、ユーザーは不安になってしまいます。
先ほどのボタンの例を出すと、「default：通常の状態」「hover：マウスオーバーした時の状態」「selected：選択された状態」「disabled：操作不可」「loading：読み込み中や処理中」など、ボタン1つでも、状態ごとに複数パターンが必要になると気づきました。また次回から事前確認も考慮して取り組みたいと思いました。
この経験を通して、ボタンに限らずどんなパーツも「想定すべき状態は想像以上に多く、パターンが必要である」ということを学びました。
3.ユーザーは、いつも落ち着いて操作しているとは限らない
あるシステムの一覧画面をデザインしていたときのことです。担当画面を作成し、確認してもらっていた際に先輩からこんな質問を受けました。
「今の状態だと編集機能がありませんが、もし仮にユーザーが間違えて登録していたらどうなりますか？」
その瞬間、「確かに今の画面では直すことができない」とハッとしました。
それまでの私は、システムに登録されているデータというものは、基本的に正しい情報であるという前提で画面を作成していたのです。
なぜかそう考えていたのか自身を振り返ると、Webデザインでお問い合わせフォームを作成してきた経験が関係していたなと気づきました。確認画面を用意してそのうえで送信するため、「送信＝確定」という感覚がどこかにありました。また情報を入力するのであればユーザーは比較的落ち着いた状態で操作してくれている、というイメージや前提で画面を作成していました。
このやり取りを通じて、その前提自体が業務システムでは必ずしも当てはまらないということを実感しました。
具体的な例を挙げてみると、
- うっかり本来の操作とは異なる操作をしてしまう
- 他の作業や業務を並行している事も多い
- デスクワーク以外の業務がメインで、パソコンに触れる機会が限定的というユーザーもいる
など、様々なケースが出てきます。
ここでユーザーの状況や背景を想定して対応策を考えると、入力したデータの編集導線を用意する。削除などデータに大きな影響を与えるものについては、ダイアログでアラートを表示させる。一時保存機能の設置を検討する…などが考えられます。
UI設計の判断基準としてユーザーと業務に対しての理解だけでなく、ユーザーの背景にある状況まで意識する必要があると学びました。
まとめ
今回紹介した話に共通していたのは、UIをどう見せるかだけではなく、どのようなユーザーが、どのような業務を、どのような手順で行い、どんな状況の中で使われるのか想像する必要があるという点でした。業務システムのUIを設計するためには、業務理解はもちろん、ユーザーについて理解することも重要と学びました。
今振り返ってみると、どれも当たり前ですが、業務に携わり始めた当初は上記の視点が持てていなかったな、と感じます。まだ勉強することは多岐にわたりますが、今回の記事がUIデザインや業務システムの開発に携わった経験が浅いデザイナーやエンジニアの方にとって、「知っておくと少しでも楽になる視点」になれば幸いです。
みなさんも普段使用しているアプリやサービスについて、細かなUIの変化や体験など意識して見てはいかがでしょうか？今までと違った目線で使用してみると、新しい発見や気付きがあるかもしれません。
最後までお読みいただき、ありがとうございました！