見出し画像

はじめての設計をやり抜くための本【設計編】第3章外部設計の手法⑤画面設計

画面設計の進め方
画面設計で作成するもの
・UIポリシー
・画面遷移図
・画面一覧
・画面モックアップ
・画面入力チェック仕様書

画面設計とデザイン
画面設計はシステム担当者が技術的な視点で設計するもので、機能要件で定義された機能をシステムが提供できるように設計する。システム担当者とデザイナーが行う業務は分ける(担当者の力量、時と場合によりさまざま)
どのようにわけるかは明確に合意する必要がある。
[システムとデザインの境界]
○システムの領域:画面項目、ボタン・リンク、画面遷移
○中間の領域:構成、配置
○デザインの領域:色調、ロゴ・画像、フォント

ユーザビリティ(特定の利用状況において、特定のユーザーによる使いやすさ)はシステムとデザインの中間の領域にあり、機能、デザイン両方の側面から考える必要がある。例:ボタンの配置など

Webデザイナーにデザインを依頼する場合は可能な限りHTML/CSSで納品してもらうことが重要。ドローツールで書かれたデザインとHTML/CSSで
書かれたものをWebブラウザで見比べると印象が違うため。
※画面はユースケース記述と概念モデルを元にして、業務担当者にヒアリングしながら検討する。

画面の種類
・GUI ※CUIではない

画面設計に関する代表的なクライアント技術
●ファットクライアント
クライアント/サーバー型システムにおける形態。専用アプリケーションをインストールして使用する。また、クライアント側で動作するためのデータや機能を全て持つ。クライアントマシンの性能に依存する。
●シンクライアント
クライアント/サーバー型システムにおける形態。専用アプリケーションをインストールして使用する。ほとんどのデータと機能をサーバ側に任せる。
クライアントマシンの性能が低くてもサーバーへNW経由で接続できれば動作可能。
●リッチクライアント
クライアント/サーバー型システムにおける形態。専用アプリケーションをインストールして使用する。専用アプリケーションはクライアントマシンのネイティブアプリケーションなので、高度な操作性が実現できる。サーバーと連携して必要なデータをダウンロードして動作する。
●Web
インターネットの普及に伴って広まったクライアント。プロトコルはHTTP(S)で、表示形式はHTML/CSS。汎用Webブラウザで操作可能。


UI設計ポリシーの作成
画面数は大きいシステムでは数百〜数千になる。これらの画面のデザインや構成がバラバラだと利用者が使いにくい。開発するにも画面の部品を共通化できないので効率が悪い。UI設計ポリシーは、個々の画面に統一感のあるユーザービリティを実現するためのもの。

UI設計ポリシーの検討項目
・前提条件
・画面レイアウトパターン
・画面機能パターン
・画面項目パターン
※技術的な問題だけではなく、ユーザービリティやデザインについても検討する。そのため、必要な場合はユーザービリティやデザインの専門家も検討に参加してもらう。

画面設計の前提条件
下記の項目の内容を検討する。
・対応ブラウザ
ブラウザによってはCSSやHTMLタグの属性が異なる。JavaScriptもブラウザによって仕様が異なるため、使用する場合は検討する必要がある。
・ディスプレイ解像度
前提とするディスプレイ解像度を縦と横で検討する。主にシステムを利用するのがデスクトップPCなのかノートPCなのかで解像度が異なる。
・画面レイアウト幅
ディスプレイ解像度に関連して、画面レイアウトの幅を固定幅にするのか、ブラウザ幅にあわせた可変幅にするのかを決める。固定幅の場合は具体的なピクセルなどを指定する。
・文字コード
出力するHTMLファイルの文字コードを決める。最近では「UTF-8」が一般的に使用されている。

画面レイアウトパターン
画面レイアウトパターンの検討ではヘッダー、フッター、メニュー、ボディなどの画面の共通レイアウトを設計する。

該当書籍の画面レイアウトの例

画面レイアウトの例


画面機能パターン
画面機能パターンでは、検索画面、一覧画面、登録・更新画面などの機能に応じて、画面レイアウトにおけるボディの構成と画面遷移をパターンとして検討する。
・検索画面パターン
情報の検索条件を入力するパターン
・一覧画面パターン
情報を一覧表示する画面パターン
・登録/更新画面パターン
情報を登録/更新する画面のパターン。確認画面と完了画面を含める
・削除画面パターン
情報を削除する画面のパターン。確認画面と完了画面を含める

検索画面の例

検索ボタンは検索条件の下に中央寄せで配置されている。検索条件が多い場合はスクロールして隠れる可能性があるため、ボタンの配置についても統一したポリシーが必要。検索画面パターンには、検索条件に何も入力されずに検索ボタンを押された時、エラーメッセージが表示することにする。その場合はメッセージ表示位置やメッセージの色を明確に規定しておく必要がある。また、各行を色分けするかどうかも合わせて検討する。

一覧画面の例

一覧画面では表示件数が多い場合にページ制御を行う。(◯件中◯件から◯件まで表示し、次のページを見たい場合はリンクを押す)そのような場合に
単に「前へ」、「次へ」だけなのかいくつかのページ番号を横並びに表示してリンクを表示するかなど明確に規定する。

ページ番号にリンクを表示する例

登録画面、更新画面は検索画面とほぼ同様。
確認画面パターンは下記の図

確認画面の例

完了画面では完了メッセージを表示するのみ。ただし、それに合わせて
トップページに画面遷移するためのリンクを配置することがある。
この点についても統一がひつようになるのでUI設計ポリシーで検討する。

完了画面の例


最後に画面遷移の流れ図を表示します。

登録画面、確認画面、完了画面の遷移


画面項目パターン
画面項目パターンでは画面に配置する項目の形式を検討する。項目には表示項目と入力項目がある。
◯電話番号の例
入力:市外局番、局番、番号を3つの入力項目とする。
表示:市外局番、局番、番号を半角ハイフンで区切って表示する
◯都道府県の例
入力:リストボックスで表示/選択する、リストボックスは都道府県コード(JIS X0401)の昇順とする。
表示:テキストで表示する。
◯住所の例
入力:市区町村、町名番地、アパート、マンション名3つの入力項目とする
表示:市区町村、町名番地、アパート、マンション名を半角スペースで区切って表示する。
※入力項目の入力された値の妥当性のチェックはここでは検討しない。

UI設計ポリシーが完成した後、実際にHTML/CSSで各パターンのテンプレートを作成する。デザインも取り込めれば尚良。
このように事前にテンプレートを用意したほうが効率が良い。また、HTMLファイルをブラウザで顧客にみてもらい、UI設計ポリシーの不備に気づくことができる。


画面遷移図の作成
UI設計ポリシーの画面機能パターンとユースケース記述を使って、画面遷移図を作成する。シナリオを実現するにはどのような画面が必要でそれらの画面はどのように関連しているか図で表現する。

画面遷移図を記述する目的
・ユースケース記述を実現する画面を洗い出す
・ユースケース記述を実現する画面遷移を洗い出す
・ユーザービリティを考慮した画面遷移を洗い出す

ユースケース記述の主シナリオと拡張シナリオを実現する画面と画面遷移w記述する。
[画面]
画面名と管理のための画面IDを付ける。
→画面名と画面IDは開発プロジェクトごとに命名ルールを決める。
画面例:「会員登録画面」のように「主語+動詞+画面」の形式
画面ID例:「MEM-001」のように会員系画面を表す「MEM」と通番の組み合わせ
[画面遷移図]
さまざまなクライアント技術がある。Webであれば画面はHTMLで表す。
画面遷移はフォームかリンクを指す。これはWebであれば暗黙的に画面遷移がサーバーの呼び出しを表すため。

画面遷移図の作成にはVisio、Cacooのようなツールを使用。画面遷移図は頻繁に更新されるので使い勝手のいいツールを選ぶべき。特に画面間の関連を簡単に付け替えることができ、画面遷移の分岐を表現できるようなツールが良い。Excel、PowerPointは✕。


画面一覧の作成
画面遷移図に登場した画面を整理して、画面一覧を作成する。画面一覧では画面IDを採番して管理する。


画面モックアップの作成
UI設計ポリシーと画面遷移図を作成した後、具体的な画面のイメージを作成する。
モックアップ=意味「実物大の模型」

画面モックアップ作成の目的
・画面項目を明らかにする。
・画面項目の配置を明らかにする
・画面遷移を確認する
・実装前の画面イメージを確認する

画面モックアップの時点で、画面項目、画面遷移、その他の画面全般について仕様を確定する。この後、画面入力チェック仕様書の作成や内部設計を行うがわかりにくい内容なので画面モックアップで確認する。
画面モックアップは実際にHTMLのリンク<A>や<FORM>を記述して画面遷移できるようにする。これにより画面モックアップの操作性は上がる。
顧客も見やすくなる。


画面入力チェック仕様書作成
画面モックアップに沿って画面入力項目の入力チェック仕様をまとめます。
画面入力項目には文字列、リストボックス、チェックボックス、ラジオボタンも含む。

画面項目の横軸のチェック項目

●注意点
画面項目にはおなじような項目が多いので重複しないように気をつける。
例えば、会員住所と社員住所は同じ住所なので、「住所」という標準チェック仕様をまとめておく。
DBの情報を使って行うチェックには注意が必要。例えば入力された値がDBに登録済か未登録か確認するなど。このようなDBにアクセスする必要があるチェックは画面設計ではなく、ビジネスルールの範囲である。


第3章外部設計の手法⑤画面設計について記載しました。
次は⑥外部システムI/F設計について記述します。


この記事が気に入ったらサポートをしてみませんか?