【ユーザインタフェース】考えるべき11のこと【具体例図解付き紹介】

過去にスクラッチ開発で新システムを開発・導入を担当した際、要件定義工程及びその後のシステム設計工程にて検討したユーザインタフェースについて解説します。

私自身、当時検討漏れがあったり、検討の詰めが甘かったりして開発ではかなり苦労した苦い経験があります。

そこで、今回はその時の経験を活かし、備忘録的にどのようなユーザインタフェースを検討しなければいけないのか、当時の私に伝えたい内容を一気に列挙します。

具体的にどういった内容を検討して決めなければいけないのか、かなり具体的な事例を挙げて１つにまとめてみましたのでぜひ参考にしていただければ幸いです。

昨今高まるユーザインタフェースはシステム開発のベースとなります。

この記事がユーザインタフェースを検討する際の１つの道しるべになれば幸いです。

この記事を読んだらわかること
考えるべきユーザインタフェースの具体例
まとめ

この記事を読んだらわかること

ユーザインタフェースとして考えなければいけない11個のことが具体例とともにわかる

考えるべきユーザインタフェースの具体例

ここから一気に11個の検討事項について具体例と共に記載しています。

何をどのように考えるべきか気になるところだけでも御覧ください。

一覧表示方法

検索画面や〇〇一覧画面などの一覧系の画面の表示方法についての検討事項です。

〇件数表示

検索結果件数、一覧表示した時の表示件数を表示するかどうか、表示位置はどこにするかを定義します。

〇表示件数、検索件数

１ページ当たりの表示件数、最大検索件数を定義します。

例えば、１ページあたり10件表示で、検索条件に合致するデータが600件あったとしても、最大検索件数が500件であれば500件までしかそもそも検索されません。SQLでいうSELECT TOP 500 のようなイメージです。

やや内部的な処理の検討になりますが、1ページあたり10件で500件の検索結果が該当するということは、50ページ分のページングが可能になります。この時、システムによっては最初に500件分を取得しておくのではなく、最初の検索スピードを速めるために１ページ目の10件分だけを検索しておき、ページングの度に次の10件を検索するような処理を採用するような場合もあります。最初我慢するか、ページングの度に我慢するか、どちらを採用するかはシステム全体の共通の考え方として定義が必要になります。

〇ページング

ページングに関しては、１ページごとのページングか、５ページずつのページングか、最小/最大のページにはジャンプできるようにするかを決めます。

〇列固定、列順

固定表示する列があれば定義します。Excelの列表示固定のようなものです。

例えば、表示列が多く横にスクロールできるような場合に、受注番号などのキー情報は常に左端に表示しておきたいといったような場合に利用します。

〇列表示/非表示

表示する列と非表示にする列を定義します。

コード設計されるようなコード＋名称で成り立つ項目、例えば、１：見積中、２：受注中といったようなコンディション定義について、コード部分を表示するかどうかを決めます。

例えば、画面上確認するだけであればコード部分の表示は不要かもしれませんが、一覧表示した結果をそのままCSV出力するような機能があった場合には、コード値があった方が集計がしやすいという要望も偶に聞くため確認が必要です。

〇ソート

一覧表示する際のソート順について共通ルールを定義します。受注番号などの主キーの昇順にするか、降順にするかをシステム全体の共通ルールとして定義します。

受注番号がインクリメントされる場合、降順にすることで新しい受注ほど上位に検索されるようになります。

〇画面遷移の方法

検索画面から受注番号を選択して、受注画面を参照するといったように更新/照会画面に遷移するような場合は多いです。そうした場合に、受注番号をダブルクリックすることで遷移させるか、何か別のボタンを押下させるかなど、画面遷移する際の挙動はシステム全体で統一されるように定義します。

〇列幅の変更可否

採用するフレームワークによってはそもそも実現できる、できないが変わってきますが、検索結果や一覧表示結果のグリッドを編集できるようにするかどうかを決めます。

一部の列のみ可変を許容するような場合があるかどうかについても検討します。

また、ツールチップを使用したい場合があるかどうかも合わせて定義しておくと良いです。

〇登録/更新/照会画面から戻った時の挙動

先ほどは更新/照会画面に遷移する時の挙動を定義しましたが、今度は戻ってくる時の挙動を定義します。

更新/照会画面から戻った時に、遷移前の検索条件や検索結果は残しておくかどうかを決めます。

こちらも採用するフレームワークによっては実現が難しい場合もあるため、実現可能性を調査すると共にユーザの要求としてどのようにしたいかを定義します。

メッセージ

続いて、システムから発せられる各種メッセージについての取り決めです。

〇メッセージの種類

完了（処理が完了したことを知らせる）、警告（処理は続行できるが問題がある状態であることを知らせる）、エラー（とある原因によって処理が完了できないことを知らせる）といったメッセージの種類を定義します。

また、それぞれの場合でどのような表示、見た目とするかも定義します。

〇メッセージ表示エリア

メッセージの種類に応じて画面上のどこに表示するかを決めます。

画面上段に表示する場合、下段に表示する場合、メッセージが複数ある場合に上段には１つだけを表示し、下段に残りを表示するなど共通のルールを決めます。

〇表示用画面（ポップアップメッセージ）

メッセージの表示エリアと一緒に、メッセージ表示をポップアップで知らせるかどうかを決めます。

また、表示用画面についてもメッセージの種類ごと使用するアイコンなどを定義します。

〇単項目チェック、相関チェック

エラーチェックに関しては、単項目チェック、相関チェックを漏れなく定義します。

単一項目としてのチェック、例えば、入力された日付が今日以降かどうか、入力された数値が１以上であるかどうかをチェックします。

相関チェックとしては、複数の日付の前後関係のチェック、ある項目が入力される時はもう一方の項目も入力されている必要があるといったチェックを行います。

〇エラーの出し方①

複数のメッセージが表示されるような場合に、どのようにメッセージを表示するかを決めます。

例えば、単項目チェックの結果、複数項目でエラーが出た場合、エラー箇所は複数一気に確認できた方がユーザにとっては親切です。内部処理としては、Exceptionにエラーを溜め込んでおき、一気にエラーを吐き出すような処理が望ましいですが、すべてのチェックを一括で行うことができなかったり、処理の都合で途中で区切らないといけなかったりと個別の事情もあります。

また、似たようなエラーを複数出すと見た目もわかりづらいため、同系統のメッセージはまとめて１つのメッセージにできる場合はメッセージの出し方も工夫する場合もあります。

〇エラーの出し方②

単項目チェックや相関チェックの結果エラーが出た際、該当する項目に対してカーソルを当てる、赤く囲うことで目立たせるかなどを決めます。

複数のエラーメッセージがある場合に、どの項目にカーソルを当てるかなどの細部まで検討して定義しておきます。

フレームワークによっては実現できない場合もあるため、実現可能性の検討ともに実施が必要です。

文章ルール

続いて、システム全体の共通ルールとして表示する文章、言葉についての検討事項です。

〇英数字

システムの中で使用する文字、特に英数字、カタカナについて半角に統一するか、全角に統一するか、使い分ける場合にはそのルールを定義します。

画面によって同じ単語が異なる表記をされていると違和感を覚えてしまうため、一定のルールを設けます。

〇西暦、和暦

平成から令和に変わるタイミングで西暦に統一したシステムも多いです。しかし、システムによってはまだまだ和暦を利用するケースもあります。システム内では西暦を使うが、対外的な帳票では和暦を利用するケースも多いです。

また、システムによっては、西暦、和暦を使い分けたいという要求もあるため、使い分けのルールや、システムにおけるスタンダードを定義しておくと良いです。

クライアント環境

ユーザがシステムを利用する際の想定環境に関する検討事項です。本項目は非機能要件とも密接にかかわっている部分であるため、非機能要件定義の結果を参考にしつつ、逆にユーザインタフェース定義で決めたことを非機能要件にフィードバックしながら決めていきます。

〇利用場所

ユーザがシステムを利用する場所を想定します。事務所や営業所などオフィスで利用することのみを想定しているか、外からスマートフォンを通じて利用する場合があるかなどを確認します。

外からアクセスすることが想定される場合はネットワークセキュリティなど非機能要件についての検討がさらに必要になります。

〇画面サイズ

システムとして想定する画面のサイズを確認します。

Webシステムの場合、レスポンシブデザイン、リキッドデザイン、フレキシブルデザイン、グリッドデザインなどどのレイアウトを採用するかの参考にします。採用するフレームワークによっては最初から決まっている場合も多いため、プロジェクトの初期段階で確認しておくことがおすすめです。

どのレイアウトを採用したとしてもシステムとして基準となる画面サイズを確認しておくことは、画面レイアウトを設計するうえでの重要な情報となります。

〇解像度

画面サイズと同じく、システムが想定する標準の解像度を決めておきます。

ユーザによっては必ずしも解像度を100%にしている訳ではありません。本番稼働後に、字が小さくて読めないなどといったクレームに繋がらないように設計・開発前にユーザの利用環境は事前に確認しておきます。

〇OS

WEBシステムかクラサバかでも大きく異なりますが、利用するユーザのOS環境は確認しておきます。言わば、システムが動作保証するOSを定義しておく必要があります。

Windowsを想定したシステムにもかかわらず、iOSユーザから挙動がおかしいと、本番稼働後にクレームに繋がりかねません。

〇標準ブラウザ

OSと同じく、システムが動作保証するブラウザを定義しておきます。WEBシステムの場合、前述したメッセージの表示方法についてはブラウザの仕様に影響する部分も非常に大きいです。そのため、システムの開発者として想定ブラウザを定義しておくことは重要です。

最近では、IEが廃止され、Edgeに変りました。この時、システムのバージョンアップを待たずにユーザが勝手にEdgeやChromeを使い始め、ヘルプデスクに問い合わせが殺到したという話もよく耳にします。

事前に想定するブラウザを定義しておくことで利用環境を明らかにしておくことはユーザに混乱をさせず、ベンダー自身を守るという意味でも重要です。

デザイン

システム全体のデザインに関する取り決め事項です。

〇色味

システム全体のテーマカラーを決めます。または、テーマカラーをユーザ自身が変更できるような仕組みにするかどうかを決めておきます。

〇ロゴ

システムのロゴを決めます。パッケージシステムの場合は導入するシステムの名称が決まっていますが、スクラッチ開発の場合は名称も一から決めます。稼働後も”新基幹システム”、”新データ統合基盤”なんて呼び方はしません。

名称が決まったら、ユーザから親しまれるロゴを決めます。

システム内、例えばホーム画面に盛り込む場合はサイズが決まっていることもあるため、想定しているサイズなどと一緒に作成することがおすすめです。

〇アイコン

ロゴの次はアイコンを作成します。これもパッケージシステムの場合は最初から決まっていますが、スクラッチ開発の場合は一から決めることが可能です。

こちらも採用するフレームワークやシステム形態によっては検討の余地がないため、事前に確認しておきます。

メニュー

続いて、システム全体の共通定義としてメニューバーの在り方を検討します。

〇タイトル位置

システム名や画面名をどこに配置するかを決めます。

画面、機能によってバラバラでは統一感がなく、良いシステムとは言えません。

〇メニュー位置

システムには必ずメニューがあります。このメニューをどこにどのように表示させるかを決めます。

サイドバーを用意するのか、画面上部にショートカットリンクを付けるのかなど決めます。

再三にはなりますが、ある程度フレームワークによって制約が出てくる部分も大きいため事前確認、または要求要件に応じたフレームワークの採用が必要です。

〇メニュー構成

システム機能、画面が決まった後、メニュー構成を決めます。

販売管理系の画面、購買管理系の画面を一塊にしたり、帳票系は別の塊にしたり、ユーザが直感的にわかるような構成にすることでユーザビリティを向上させます。

メニュー構成については、スクラッチ開発で一から開発する場合に限らず、エンハンス開発で新機能を追加する場合にも開発する画面・機能をどこのメニューから呼び出し可能にするか検討が必要になります。

画面部品

各画面における画面項目、画面コンポーネントに関する定義を行います。

全体を通して採用するフレームワークやプログラミング言語に依存します。事前の確認は必要です。

〇フォーマット

数字、金額、日付などについて共通のフォーマットを定義します。

数字、金額であればカンマ区切りを入れる、日付であればyyyy/MM/dd、yyyy.MM.ddなどのフォーマットを決めます。

また、数値に関してはシステム共通の有効桁数を定義しておき、例外的に表示したい場合にのみ個別に定義するといった場合もあります。例えば、利益率などはシステムの基本ルールとして小数点第一位まで表示と決め、特に断りがない限り小数点第一位表示とする。一方で、化学物質の含有率は小数点第二位まで表示することを機能設計にて個別定義するような場合が考えられます。

〇右寄せ、左寄せ、真ん中寄せ

テキストボックスやテキストエリアに入力された値も含めて、各オブジェクトに入力された値を右寄せ、左寄せ、真ん中寄せ、それぞれどのようなルールを基本とするかを定義します。

操作（キー、タブ）

続いて、ユーザが画面操作する時に関係してくる検討事項について定義します。

〇キーボード操作、ショートカットキー

登録ボタンにはF12を、閉じるボタンにはF11、検索ボタンにはF4を割り当てるなどといったように画面間で同じボタン（機能）には同じショートカットを割り当てるようにします。

受注登録画面の登録ボタンはF12だが、購買登録画面の登録ボタンはF10、入金登録画面の登録ボタンはショートカットキーの割り当てがないといった具合に統一感がないシステムは言うまでもなく利用しづらいです。

気を付けるべき点は同じ機能を指しているが、画面間でボタン名称が若干異なるような場合、例えばバッチ一括処理を行う画面の「実行」ボタンと受注登録画面で短票を登録する時の「登録」ボタンといったような場合に同じショートカットを割り当てるかどうか注意を払います。そもそも同じ言葉になるように用語の定義がずれている場合には是正をします。

〇タブ順

画面におけるタブ順を決めます。一般的にはZ順（画面左上から右上、次に左下に流れるように進んでいく）が多く採用されます。

タブ順を定義しないとタブがそもそも機能しない画面が開発されたり、滅茶苦茶な順序の画面が開発されたりしてしまいます。

〇IME制御

IME制御を設けるかどうか、設ける場合の基準を定義します。

例えば、テキストボックス、テキストエリアに対しては一律でIME制御を行うなどを決めます。

ただし、使用するブラウザによって制御が変わります。したがって、前述したような標準ブラウザの定義が必要になる理由がここからもわかります。

入力補完

操作に続いて、ユーザが入力処理をする時の操作についての検討を行います。

〇カンマ、スラッシュの自動補完

金額や数値を入力した時、ロストフォーカスしたタイミングで、カンマ表記に直すかどうかを決めます。数値としておかしいな値（例：11ab234）が入力された時の挙動についても決めます。

また、日付も同じくyyyyMMddと入力し、ロストフォーカスしたタイミングで、yyyy/MM/dd表記に自動で直すかどうかを決めます。日付の場合も入力された値がyyyyMMdd形式でなかった場合も想定しておきます。

ロストフォーカス時に処理しない場合、画面読み込み時に表示する値を整形するため一度登録処理が必要になることもあるため、自動補完を行うかどうかは決めておく必要があります。

データチェック

ユーザがデータを入力後にシステムが行うチェック処理について共通の定義を検討します。

〇タイミング

入力された値のデータチェックを行うタイミングを決めます。

先ほど定義した単項目チェック、相関チェックのタイミングとして、入力フィールドからロストフォーカスしたタイミングでのチェックをするか、ロストフォーカス時にはチェックせずあくまで登録ボタンが押下されたタイミングでチェックするかを検討します。

同じ単項目チェックであっても、日付型チェックや数値型チェック、桁あふれの入力など書式や規制に関係するチェックはロストフォーカス時に、単一項目として業務上の要件を満たしているか、例えば見積金額を入力した結果、粗利が1%以上になっているかどうかなどのチェックは登録ボタン押下時に行うなど、チェックの内容によってもそのタイミングを使い分けます。

また、ボタン押下後のチェックに関しても、「登録しますか？」といった確認メッセージの前にチェック処理を走らせるか、後に走らせるかについても統一のルールを定義しておくことである。画面によってエラーメッセージが出るタイミングが異なると統一感がないシステムが出来上がってしまいます。

このあたりはユーザインタフェース要件として定義しておかないと開発者の感性によって特に挙動が変わってきてしまうため、共通定義を設けることが大切です。

〇種類

データチェックを行う種類を決めます。必須チェック、フォーマットチェック、桁数チェックなどが該当します。

それぞれのチェックに関してもエラーを知らせるタイミングはシステム全体で統一します。

〇方法

メッセージのところで先に触れましたが、エラーの出し方や単項目チェック、相関チェックについては前述したようなタイミング、種類とともに漏れなく検討しきります。

特に相関チェックについては、業務要件とも深く関わるためユーザインタフェース要件からのアプローチではなく、業務要件からアプローチすることがおすすめです。