業務系システムのフロントエンドを実装する上で気をつけてること
はじめに
初めまして、ホシノと申します。WEB系のフロントエンドエンジニアをやってるものです。
普段は業務系のWEBシステムを要件定義から画面設計、実装まで色々とやっております。
エンジニア始めた当初からシステムの画面丸ごと任せていただくことが多く、色々と書籍を漁ったりFBを受けたりしながら頑張ってたところ、ある程度の知見が貯まってきました。
備忘録がてら記載させていただきます。
本記事の対象者
本記事は業務系システムを作成する際に、筆者が最低限気を付けたいことを記載しています。
「デザインわからんけどそこそこ使いやすい画面を作らなきゃいけなくなった！」という方に、ぜひご一読いただきたい内容となっております。
最低限の内容になっていますので、デザインやフロントエンドの高度な技術を求められている方には、少々物足りないかもしれません。
本記事の構成
スタッフを管理するシステムのサンプルを例に、デザインやフロントエンドの実装で気をつけてることを書いていきます。
チェックリストのようにしたかったので、大項目で機能、次項目で疑問系の形式で記載していきます。
注意点として、PCのみで動作するWEBシステムを想定しております。
予めご了承ください。
サンプルについて
良い例と良くない例のサンプルページをNuxt3で作成し、Github Pagesで公開しています。
よかったらご確認ください。
サンプルページ
リポジトリ
どちらの例も、スタッフ情報のCRUDが行えます。
Nuxtのみでサーバーと接続はしていないため、画面を更新したら元に戻ります。
以下、FVのスクショです。
😄:良い例
😰:良くない例
移行で記載する参考画像に、上記の絵文字とユーザーの心の声を添えて記載していきます。
参考資料
この記事の殆どが以下の本で書かれてる内容になります。
もし興味持っていただけましたら、ぜひご一読下さい。
全般
様々な画面で共通して気をつけたいことを記載します。
余白は整ってる？
FVを見ていただけたら分かる通り、けっきょくよはく、ということです。
余白どころじゃ無いだろという声が聴こえてきそうですが…
実際に、良くない例のFVで横幅だけ揃えてみました。
これだけでだいぶ見やすくなったのでは無いでしょうか。
😰:見やすくなった…？
基本的に、余白を決められたルールでしっかり取っていれば、それほど酷いUIにはならないと思います。
VuetifyなどのUIライブラリを使うと勝手に余白を取ってくれるのでお勧めです。
気をつけておきたいのが、デザイン４原則の近接の法則です。
近いものはグループ化されて認識されてしまいますので、分けるべき要素が近くなり過ぎてしまう場合、余白を大きく取るようにしましょう。
使う色は決められてる？
こちらも予め決められた色を、役割で分けて使うのが良いでしょう。
色数が多いとダサくなりがちです。
Material Designの記事が参考になります。
ユーザーの目線を意識してる？
ユーザーがどういう順番でシステムを見るか、は意識しておきたいです。
有名なのがF型とZ型ですね。
SmartHRのデザインシステムの記事が分かりやすく、参考になりました。
左上が最も目に付くため、システムのタイトルやロゴを置くことが多いです。
ユーザーの目線を理解した上で、目線に沿って触らせたい要素を配置していくと、使いやすい画面になります。
画面スクロール要る？
不必要な画面スクロールは行わないようにしたいです。
スクロール自体がそもそも手間なのと、画面スクロールで操作や確認したい要素を隠してしまうデメリットがあるためです。
一覧表示や登録フォームなど、どうしても縦長になる場合はありますが、基本的にスクロールせずに画面の全貌がわかるようにした方が良いでしょう。
高さが出てしまう部分にはラッパーで囲み、ラッパー内でスクロール(スクロールボックスと呼んでます)させるようにしましょう。
スクロールボックスを作る際に気をつけたいのが、画面スクロールと併用してしまうことですね。
画面をスクロールしてたはずがスクロールボックスの方をスクロールしてしまって、ストレスになる可能性があります。
😰:急にスクロールが引っかかった…
処理の成否がわかる？
全ての処理において、成否の表示は必須です。
失敗時のエラー表示はもちろん、成功時にも何かしらのメッセージを表示させるべきです。
また、成否の表示方法はシステム内の全ての画面で統一させた方が良いでしょう。
😄:更新できてるっぽい！
一覧表示機能
特定の要素を並べて表示する機能です。
業務系のUIで最も重要視されがちなのが一覧性です。
一覧性は人によって解釈が分かれやすい言葉なので、この記事では一度に多くの要素を表示できていて、各要素の状態がわかりやすいことを、一覧性が高いと定義します。
一覧性を担保する上で気をつけたい点を後述します。
何を一覧表示しているかわかる?
一覧表示する要素の設計があまり出来ておらず、何かよくわからないデータの集合体を一覧表示したこと、あるかと思います。
実装してる時は暗黙知になってしまって、後で使ってみて何だこれってなるケースが多いですね。
対処法としては簡単で、一覧の上にタイトルをつけましょう。
何を一覧表示してるか明言するだけで、かなりわかりやすくなります。
😰:スタッフ情報っぽいけどスタッフにロールなんてあったっけ…？
😄:わかりやすい！
要素が何の情報を持ってるかわかる?
一覧表示する要素がどういう情報を持ってるか、はわかりやすくするべきでしょう。
これによって大きく表示の仕方を変えた方が良いケースもあります。
業務系では要素の情報が多くなるため、基本的にExcelのようなテーブル形式のUIになりがちです。
テーブル形式のUIの場合、列が多過ぎて画面に入りきれないことが多発します。
この場合、列の表示と非表示を切り替え可能にしたり、横スクロールできるようにしてスクロールヒントをつけたりなどして、見えてない部分があることをUIで明示した方が良いでしょう。
結局のところ重要なのは、ユーザーは一覧表示で何を確認したいか、です。
不必要な情報はノイズになってしまうし、ユーザーの本来の要望によってはもっと適切な表示の仕方がある場合もあります。
ユーザーの要望を可能な限り深掘りしましょう。
一覧から特定の要素を見つけやすい？
一覧表示の中で特定の要素を見つけるため、一覧表示には検索機能がほぼセットで必要とされます。
検索機能には、APIリクエストで検索する場合と、画面で絞り込む場合があります。
APIリクエストで検索する場合
この場合、画面でサーバーに送る検索条件のフォームデータを作成することになります。
検索条件の項目が多い場合、画面を覆い尽くしかねないので注意が必要です。
この場合、検索条件を折り畳みパネルやダイアログの中に収納できるようにしましょう。
また、検索条件を収納できるようにした場合、検索条件を設定中であることが分かるように、収納先の折り畳みパネルやダイアログの起動ボタンに、バッチなどを表示しましょう。
また、検索機能はGETリクエストにし、画面のURLと同期するようにしたいところです(URLで検索と呼んでます)。
URLで検索できるようにしておくと、検索結果を共有する時に便利です。
後述のページングの際にも有用なのでおすすめです。
😰:検索条件邪魔過ぎる…
😄:検索条件設定してることが分かる！URL検索もできてる！
画面で絞り込む場合
APIリクエストで検索しない場合、特定のタイミングで一覧表示する要素を全て取得した上で、画面上で絞り込み処理をかけることになるかと思います。
基本的に、画面での絞り込み処理はフリーワード検索で十分かと思います。
この場合、フリーワード検索欄のラベルなどで、何を対象に絞り込みしているのかを明示しましょう。
😰:何を絞り込んでるかもわからない…
😄:わかりやすい！
要素の強調
検索に限らず、一覧表示自体に見つけやすくする工夫もできます。
定番なのが、一覧の要素の背景色を交互に変えていくやつです。
ただ、要素の情報を表示する色と背景色が衝突し、逆に見にくくなる可能性もあるため要注意です。
また、よくあるのが異常な要素のアラートです。
一覧で強調するのも大事ですが、要素が多いと隠れてしまうため、一覧の外にもアラートは出しましょう。
一覧の外に出したアラートから、アラートを出してる要素の詳細を表示、とかできたらよりスマートですね。
😄:すぐに見つけれた！
※この例では検索欄を操作していますが、スクロールとかの方が良きだと思います。
ページング要る？
大量の要素を一覧表示するにあたり、表示負荷を軽減するために考慮すべきなのがページングです。
定番になってるため実装する流れになりがちです。
しかし、ページングは実装で考慮すべき事が増える割にそれ程使われない印象があるので、使わないことも検討するようにしたいです。
※こちらの項目はサンプルでは未実装です。
ページングを使う時に気を付けること
一覧表示時のサーバー負荷や、表示する要素の性質にもよりますが、全要素数が300件を超すようであれば、ページングを使った方が良いでしょう。
ページングを使う上で、表示していないページの要素については強く気をつけておきたいです。
筆者は以下のような場面で、表示していないページの要素に対する処理を忘れがちでした。
- 一覧内の異常な要素に対するアラート
- → 表示していないページの要素がアラートの対象に含まれてない！
- 一覧上で選択した対象への一括処理
- → 表示していないページの要素が選択できてない(選択できない)！
- 一覧の要素数の表示
- → 表示していないページの要素が数えれてない！
表示していないページの要素に対しても正しく処理ができているか、よく確認しましょう。
登録機能
新しく要素を登録する機能です。
登録に関しては、簡単に登録できることが重要視されます。
後から更新もできるため、後述の機能に比べてミスを防ぐことよりも要求される傾向があります。
何を登録するかわかる？
一覧表示に引き続きですが、気を付けておきたいところです。
ちゃんと明記しておかないと、ユーザーは何が登録されるのかわからない可能性があります。
何を登録する画面なのか、しっかりと明記しましょう。
😰:何を登録する画面なんだ…
入力項目のラベルと一覧表示のラベルが合ってる？
「メールアドレス」として入力した項目が「ID」として表示されてる…なんて経験はないでしょうか。
上記は極端な例ですが、業務系は1つの要素に対する情報が増えがちになるため、混乱を防ぐ為にも気をつけたいところです。
表示順も揃えた方がより受け入れやすくなると思います。
😰:入力項目と列が違い過ぎて怖い…
😄:入力項目と列が揃っててわかりやすい！
適切にdisabledできてる？
登録確定後に「未入力の項目があります」とバリデーションで弾かれて、「先に言ってよ〜😇」となった経験、あるのではないでしょうか。
フォームが登録処理を実行できる状態で無い場合、登録確定する要素はdisabledにして押せなくするのが良いでしょう。
この時に注意しておきたいのが、何が原因で登録出来ないのかわかるようにすることです。
登録出来ない原因がわからないままだと、ユーザーが何をすればいいかわからなくなってしまいます。
登録ボタンの横に羅列されてるととても親切ですね。
例外として、バリデーションをサーバー側に依存してる場合は上記は当てはまりません。
😄:優しい世界
デフォルト値設定してる？
未入力が問題になるなら、事前にデフォルト値を入力してしまおう、という発想です。
前述の「未入力がある場合に登録ボタンをdisabledにする」を対応してる時に思い付きました。
ユーザーの入力の手間も減るし、バリデーションを起こす必要も無いしで良いことづくめですね。
ただ、デフォルト値を設定することで編集せずに登録できるようになると、ユーザーが入力をよく確認せずに登録してしまう場合があります。
後で自由に更新ができる場合は問題無いですが、更新しにくい項目がある場合、空欄にしてユーザーに確実に入力してもらうのが良いでしょう。
更新機能
特定の要素の状態を更新させる機能です。
ダイアログを開いて更新や、入力した内容が即時更新など、色んな更新方法があります。
頻繁に処理を行う業務系では、ミスが起きないことが最も重要視されがちです。
即時更新してもいい？
即時更新にする場合、すぐに元に戻せることはマストにしておきたいです。
また、他のシステムへの影響も加味するべきでしょう。
すぐに元に戻せて、更新して問題ないものであれば、即時更新で問題無いと思います。
サンプルの例だと備考欄ですね。
しかし、その他の項目に関しては即時更新してしまうと大問題になる予感がします。
もし、更新する際に慎重になる必要がある場合、チェックボックスなどでワンクッション置くのが良いでしょう。
登録ボタンをdisabledにするのも忘れずに。
😰:こんな簡単に更新できていいの…？いつ更新されてるの…？
😄:勢いで更新してしまうところだったけど防げた！
削除機能
特定の要素を削除する機能です。
こちらも更新機能と同じく、ミスが起きないことを重要視されがちです。
ワンステップ置いてる？
削除機能に関しては、実行後に高確率でユーザーが触れなくなってしまうため、更新機能よりも慎重になりましょう。
ダイアログなどで必ずワンステップ置いて、ユーザーを落ち着かせるべきです。
良くない例のように、ノータイムで削除してしまうのはやめましょう。
😰:削除が早すぎて全くわからない…
😄:危なかった！
警告できてる？
ユーザーに危険な動作であることを、色や形で示した方が良いでしょう。
色であれば、赤系統を使うのが一般的です。
形はバケツアイコンを使うことが多いように思えますが、×を使うケースもあります。
システム内で統一しましょう。
😰:ヘッダーに書いてるけどわかりにくい…
😄:危なそう！
まとめ
いかがでしたでしょうか。
ざっくりまとめると以下になります。
- ある程度良いUIを作るのに必要な条件
- 余白を決められた条件で取る
- 色は役割で決めた色を使う
- ユーザーの目線を意識する
- 業務系で重要視されがちな要素
- 一覧性が高い
- 登録が簡単
- ミスが起きない
ここまでお読みいただきありがとうございます。
何か参考になる箇所がありましたら幸いです。
業務系といえば一括処理が大変になりがちだったので、気が向いたらそちらも書きたいと思います。
Discussion