はじめに
個人的経験上、ディレクターあるいは新規機能・機能追加を企画する部署担当者(以下略、サービス企画担当者)が画面設計書を作成し、それをもとにデザイナーが画面のデザインを、エンジニアが画面と機能の実装開発をする流れでした。
ただ、社内の組織体制や人的リソースによって、設計書のフォーマットや書き方も人それぞれです。更新フローの他に、共有方法も口頭説明を合わせて行うこともあれば、設計書のリンクのみ送って各自確認をとったりする場合もあります。
普段フロントエンドエンジニアをしていますが、業務で画面設計書を作成する機会があったので、個人的な考えを交えて言語化することにしました。
一概にこれが正解とは言い切れませんが、今まで見てきた中で良さそうと思ったやり方をベースに書いています。
画面設計書とは
画面内に「どのようなパーツ(画面上の構成要素)」があって、それで「何ができるのか(画面上で提供される機能)」を説明した資料
と、捉えています。
画面設計書を作る目的は、その画面でユーザに何を表示してどうして欲しいかという意図をイメージ・言語化することで、ビジネスサイドやデザイナー、エンジニアと共通認識を図るためです。
Webサイト制作でいうワイヤーフレームに近いものでしょう。
ただ、主な操作が画面遷移のWebサイトに比べて、アプリケーションの場合はユーザ入力とそれに伴う制御、認証、各機能へのアクセス制御、アカウント種別と各種条件による表示切り替えと、考慮する点は様々です。
画面設計書はいつ作る?
- ディレクター・サービス企画担当者が要件をもとに画面設計書を作成
- デザイナーが画面設計書をもとに画面デザインを制作
- エンジニアが画面・機能実装
の流れもあれば、
- PMが要件をデザイナーやエンジニアに共有
- デザイナーが画面デザインを制作
- デザイナーあるいはエンジニアが画面設計書を作成
- エンジニアが画面・機能実装
のケースもありました。
開発プロセスがウォーターフォールだと、前者の画面設計書で認識合わせをした上でデザイン・実装に回すことが経験上多かったです。
後者のように、デザイナーとPM・ビジネスサイドが直接コミュニケーションをとってデザインを先行作成する流れになることもありえます。
個人的には、プロトタイピングでデザイン先行することがあるとしても、最初に多少粗めでも画面設計書があると良いと考えます。機能を整理・ドキュメント化せずデザイナーとやり取りを進めると、その後あれも必要これは不要と後々のフィードバックで散見することが想定されるからです。
なので、いつ作るかについては、デザイン・開発着手する前に画面設計書を作成する方が共通認識を図るタイミングとして良い です。
多少考慮しきれない点があっても、まずは画面設計書に落とし込んでみて、デザイナーやエンジニアに懸念点を相談しつつ共有 してみることをお勧めします。
そこで、「画面設計書にはこう書かれているけど、〇〇した方がわかりやすいし操作性も良いはず」、「〇〇よりも□□の表記が良くないですか」、「〇〇させるのは難しそうなので別アプローチを考えます」といったフィードバックが出てくるので、そうした意見を取り入れつつ設計書をブラッシュアップしていきましょう。
画面設計書は誰が作る?
基本的には、サービス企画担当者が望ましいです。
新規機能や機能変更を推進する側から、どういった目的やサービス課題があったのか、何を表示するべきかという根拠や判断基準を持っているからです。
ただ、サービス企画担当者がいくつもプロジェクトを掛け持って作業できない際、デザイナーあるいはエンジニアが作成することもあるかもしれません。
その場合にも、デザイナーやエンジニアがサービス企画担当者と近い視点で作成できるよう、関連資料や情報の事前共有はされるべきだと考えています。
画面設計書をどのように作る?
画面設計書のレイアウト
一般的に、対象画面のキャプチャとそれと紐づけて説明するテーブル(以下略、詳細テーブル)を併記して表現します。キャプチャは、デザイナーがデザインデータを作っていたらそれを貼り付け、なければ図形ツールを使ってワイヤーフレームのように要素を画面に配置したラフイメージを貼ります。
個人的には2カラム構成で左側にキャプチャ、右側に詳細テーブルを配置するのがしっくりきます。
2カラム構成は、一定以上の領域幅が確保されていないとみづらいのが懸念です。上段をキャプチャで下段に説明のレイアウト構成も考えられますが、ディスプレイで見る際に都度キャプチャの要素がテーブルのどこに対応しているのか、上下にスクロールする手間やストレスが生じてしまいます。
縦向きの紙面やタブレットならそれでも良いでしょうが、人は左上から右下に視線を誘導する習慣上、左右に視線誘導を促す2カラム構成が比較的良いだろうと考えています。
他には、画面キャプチャ内の要素に矢印を引いて、「〇〇の文言に変更」のコメントを添えるようなフリーフォーマットの書き方も見られます。
部分的な変更であればそれでも良いかもしれませんが、新規画面だと全ての要素を説明する際矢印だらけになってしまい見づらくなることが予想されます。
なるべく、キャプチャと詳細テーブルが対応づけしやすいよう目印を最小限にする と良いでしょう。
例えば、画面内の要素が少ない場合は、詳細テーブルと見比べてわかる範囲なら目印をつけないとか、1,2,3…といった番号を該当要素の近くにナンバリングする、要素間の位置が近くてどこの説明か区別しやすいように四角の枠で囲むといった具合です。
この辺りの紐付けも、どういった基準でどのように行うかを標準ルールとして定めておくと、周りと書き方が違うといったことも減らせると思われます。
詳細テーブルのフォーマット
画面キャプチャは左上から右下に視線誘導するよう、要素を配置します。
詳細テーブルも、上から下へ画面キャプチャの視線誘導に合わせて並べていくと良いです。
では、詳細テーブルにはどのような情報を載せると良いでしょうか。
個人的見解ですが、以下のうち最低2つ(ラベルと説明)、できれば5つの情報があれば良いと考えています。
例)
| No. | ID | ラベル | APIデータ | 説明 |
|---|---|---|---|---|
| 1 | heading title | カテゴリー | - | - |
| 2 | search input | - | - | 検索キーワードのインプット プレースホルダー: キーワードを入力 2文字目以降サジェスト検索で結果が表示 |
| 3 | search button | 検索 | - | ボタンをクリックすると、カテゴリー検索画面に遷移 |
| 4 | category title | - | ○ | カテゴリー名 1行で納まらない場合は末尾を「...」 |
| ... | ... | ... | ... | ... |
No.
キャプチャの要素と対応づけるのに使います。キャプチャ内にナンバリングした要素と紐付けたり、仮に紐付けしなくても、その画面にどのくらいの数の要素があるか、No.の数から把握することができます。
ID
画面内で一意となる命名にします。個人的に英語の方が直接的な表現になるので英語で命名が良いと考えています。説明欄で代替できるようになっていれば不要ですが、例えばアイコンだけのボタンは、画面にテキストで表示されないため、IDを使って指し示すことができます。
また、IDの名前があると、サービス企画担当者とデザイナー・エンジニアで仕様確認をするときに
デザイナー「No.2のところなんですけど、~」
サービス企画担当者「(No.2ってどこだったかな...)」
のように、No.でのやり取りは画面設計書が手元にないと、対応づけのイメージがしづらかったりします(No.はキャプチャと詳細テーブルの紐付けに使われるもので、関係者とのコミュニケーションで使うには直感的とは言い難い)。
補足説明を加えて対象要素を伝えても良いですが、一意の名前があると、関係者間でやりとりする共通用語に活用できます。
ラベル
文字通り画面上に表示されるテキスト(見出しや説明文、リスト、注記)やボタン内テキストになります。もう少し掘り下げると、「APIより取得しない、ハードコーディングされた静的テキスト」をここに記載します。
APIデータ
APIより取得するテキストや画像などがあればここに○をつけます。これと上述のラベル列を参照することで、この要素は静的データあるいは動的データかを区別することができます。
説明
主にフォームやリンク、ボタン等インタラクティブな要素に対する、動作の説明を記載します。他にはテキストでも表示条件や出力制御があれば説明に書いておきましょう。
こちらはチェックポイントを交えつつ後述のセクションで解説しているので、そちらをご覧ください。
要素説明の具体性、網羅性
先の説明列には、どういう記載をすれば良いでしょうか。
説明内容で考慮漏れがないか、具体性を伴っているか に留意して書いてみると良いと考えます。
- インプット要素(入力系)
- 必須項目かどうか
- 最大入力文字数の指定はあるか
- 最低入力文字数の指定はあるか
- 最大選択数の制限はあるか *チェックボックスで選択可能な最大選択数の有無
- 入力必須・入力不可の文字種はあるか
- デフォルト値はあるか
- プレースホルダーはあるか
- 編集不可条件はあるか
- エラー文言のバリエーションと表示条件
- ボタン要素
- ボタンの活性・非活性条件
- 画面への表示・非表示条件
- ボタンクリック後にどういう処理を行うか
- リンク・画面遷移系ボタン要素
- 同一タブで遷移するか、別タブで遷移するか
- クリック後に遷移前確認する条件はあるか *入力画面から離脱して良いかなど
- テキスト・その他要素
- 要素の表示・非表示条件はあるか *特定のユーザステータス等で表示
- 省略表記 (…)の条件
上記に沿った参考例として、パスワードを登録するインプットテキストだと以下のようなルールを書くことができそうです。
- 最大入力文字数: 20文字
- プレースホルダー: パスワードを入力
- 〇〇ボタン押下時に以下のバリデーションチェックを行い、エラー文言を表示する
- 未入力: パスワードが未入力です
- 最低入力文字数: パスワードは6文字以上にしてください
- 入力必須文字種がない: パスワードは英字・数字・記号を2種類以上組み合わせてください
このように、デザインデータだけでは表現しきれない挙動をもれなく記載しておく必要があります。
また、テキスト要素だと、特定のアカウント権限では表示させないとか、文字数が長くなる場合を考慮して2行まで表示してそれより溢れる場合は「…」を表示するなどを記載したりします。
入力・出力に関する制限やルールをこの段階で考慮しておくことで、後々デザインや開発後に想定していなかった、こうじゃなかった…ということを減らせます。
画面設計書の作成Tips
画面設計書を作成するにあたり、以下のような点に遭遇したのでその時どうしたのかをまとめてみました。
- ヘッダーやナビゲーションといった画面共通で表示される要素はどうするか?
画面共通で表示されるエリアについては、別途共通パーツの画面設計書を作ると良いでしょう。都度共通パーツの説明を書く手間が減りますし、作成対象の設計書には、共通パーツの設計書リンクを貼っておくことで、画面固有の要素にフォーカスすることができます。
- 画面要素が多くてナンバリングが大変、採番間違えしそう
画面内の要素数が40,50,それ以上あると、キャプチャへのナンバリングで番号をつけ忘れた、番号を飛ばして採番することもあり得ます。
そのような場合は、画面をセクションごとに分割すると採番の負荷も減らせるしセクション内の要素数が多くなければナンバリングをしなくても伝わったりします。
フロントエンドでいうところの、ページ内の要素を関心ごとにコンポーネントとして切り出すイメージに近いと思います。ただし、画面設計書の場合はあまり細かく切り出してしまうと全体感が見えにくくなってしまうため、要素が密集している箇所や画面とは別レイヤーで表示されるモーダルと、大きく分けるくらいに留めると良さそうです。
画面設計書に付随して必要な情報
- 機能目的と背景
なぜこの画面を作る必要があるのかという経緯や目的を記載した資料(〇〇の法律上この要素を表示しなければいけない、管理画面で対象者を特定するのに使用するため等)があると良いです。それがないと、レビューする立場からして、なぜこの画面を表示するのか、この要素を表示させなくてはいけないのかという裏付けがないように見えてしまいます。
画面のデザインや実装には関係のない情報かもしれませんが、裏側にどういう意図があってそうさせているのかという情報を言語化して共有することは必要と考えています。それは、プロジェクトメンバーとして同じ土台で考えるきっかけ作りになるためです。
それと、後々機能のリニューアルをすることになって、当時どういう経緯で表示したかという資料がないと、既存の表示要件を精査する判断もしづらくなってしまいます。
- 画面の遷移フロー図
新しい機能を作る際、単一画面で完結することはあまりなく、複数画面で構成されることがほとんどです。少ない画面数なら画面間の関係や遷移をイメージできるのですが、5画面以上になると画面設計書で1画面あたりの説明だけでは俯瞰したイメージがしづらくなってしまいます。
なので、画面設計書とは別に、画面間をどう遷移するのかがわかる図があると認識ズレを減らせるし、それをもとにイメージを固めることができます。
画面設計書を作るツール
表組や図で表現することから、エクセルやパワポ、AtlassianのConfluence、最近ではNotionやFigmaで画面設計書を作っているところもあるでしょう。
会社によって使うツールが異なるため、これでなきゃいけないというものはありません。なるべく作成・更新にかかる負荷を減らせるよう普段使いで学習コストが低いもの、社内導入のしやすさを基準にすると良いでしょう。
一方で、社内メンバーのツールの習熟度もバラツキがあり、それも考慮してツールを選定する必要があります。
画面設計書を作るメンバーで、ある人はFigmaを使い慣れているため、画面設計書をFigmaで作りました。しかし、周りの人はFigmaを使い込んでないため、新たに作る画面設計書をFigmaで作ると時間を取られて、結果別のプロジェクトで別のツールを使うようになると、作成者によってドキュメントの種類も散漫になることが考えられます。
あらかじめ作成メンバー内のツール習熟度を把握し、中長期的な運用を鑑みて使うツールを1つに絞るのが望ましいです。もし、そのツールを使い慣れていない人がいる場合は、画面設計書作成を目的としたマニュアルを用意したり、作成負荷を減らせるようテンプレートを用意したり、そうした人たちに向けたハンズオンを設けてみると良いでしょう。
画面設計書をどのように共有する?
前の会社では担当者が画面設計書を作ったら、デザイナー・エンジニアに向けて、資料を見せつつ口頭で説明する会が設けられました。
最近関わった仕事だと、画面設計書のリンクを共有してもらう(非同期で各自確認パターン)だけだったりします。
画面設計書が精緻に作られていたり、デザイナー・エンジニアとの関係値が高いなら後者でも良いでしょうが、個人的には 初回だけでも良いので画面設計書と合わせた口頭説明 が望ましいです。
理由は、主に以下の3つがあります。
- 画面設計書の初回レビューで気になる点を最初の段階で質問・指摘するためコミュニケーションコストが増す
- 記載内容によって、関係者間で認識ずれを起こす可能性がある
- 非同期は各人の認知負荷や理解にかかる時間がまちまちになる
- 考慮すべきところを読み飛ばしてしまう
- なぜこの動きを取ったのか経緯を推測して時間を取られる
特に、機能要件が複雑な画面は、こうしたことが起こりやすいと想定されます。
なので、要素や挙動の意図・経緯を口頭で説明することで、大事なポイントを関係者に共有し、1時間の説明会ならその時間内で仕様理解を揃えられるし、ぱっと見気になったところをデザイナーやエンジニアがその場で確認して早期解消するきっかけにもなります。
画面設計書をはじめてレビューするタイミングは、デザイナーやエンジニアはいちユーザに近い位置で確認するため、違和感を感じたり懸念となる箇所、そもそも必要なのかというツッコミは貴重です。
それに対して説明できる根拠を準備しているのか、ない場合はそうした意見を深掘りしつつ、ブラッシュアップで改善できるようにすることが大事だと考えます。
画面設計書をどう管理する?
画面設計書の運用には、主に2つのアプローチがあると考えています。
- マスター管理(全分管理)
- 差分管理
前者は、画面の新規作成から現時点までの変更点を同じドキュメントで管理するやり方、後者は変更ごとに別のドキュメントで管理する手法です。
マスター管理は、ナンバリングを付け替えたりと運用時の変更が影響して余分な作業が発生する点はありますが、画面仕様はこのドキュメント内に集約されていて俯瞰して見られる、現行機能を確認しやすいというメリットがあります。
差分管理は、変更点以外の箇所については他の設計書を遡って見なくてはいけないデメリットはありますが、変更点のみ注力できるので作成コストは低いのが利点です。
一長一短な側面はありますが、個人的には マスター管理の方が中長期的な観点から良い と考えます。画面設計書が分散化してどこにどの機能の説明があるか探す手間はなくなるし、新規メンバーが入った時にも、画面内の機能を1つの設計資料で押さえられるからです。
最後に
画面設計書のプロセスで大事なのは、関係者間で作りたいイメージが齟齬なく伝わることだと思います。まずは一度やってみて、そこで出た課題や良かった点を定期的に振り返り作成方法や共有フローなどを見直してみると良いと考えます。
わたしもこの記事を書いているときに、「でもわたしが今良さげと思っているポイントも今後改善するかもしれない」と思って、記事のタイトルに(仮)をつけました。
画面設計書を作る側だけでなく、レビューする立場からも「ここは〇〇の書き方をすると伝わりやすい」「マスター管理の更新方法で〇〇するのはどうかな」と作成担当者に提案して、次のプロジェクトや機能開発へ活かせるようなサイクルにつなげられたらと思います。