はじめに

システム開発においてのデザインの重要性は言うに及ばないと思います。
最近では業務システム（社内システム）であってもデザインを疎かにせず、デザイン会社に発注する場合もあります。
デザインの外注が当たり前となった現在、開発者として何を観点に納品物をチェックした方が良いのかをまとめたいと思います。

「POSTリクエストの『登録』ボタンがaタグになっていた！！」なんてことを納品チェック後に言わないために。
（いや、別にaタグの押下がトリガーでもPOSTしようと思えば出来ますけど・・・）

チェックの前に

発注の方法によって変わるとは思いますが、大抵の場合は叩き台としてのレイアウトと画面項目の一覧を渡してのデザイン依頼になると思います。
デザイン会社はその「開発者が作ったお粗末なレイアウト」をUI/UXを意識した素晴らしい物へと昇華させてくれます。
素晴らしい物になってはいるはずですが、当然納品物の確認は必要です。そして、納品物のチェックに入る前に以下の質問をする必要があります。

なぜそうデザインしたのか

特に叩き台レイアウトと差が大きい箇所でこの質問をする必要があります。

デザイナーはデザインのプロです。
「なんとなく」でデザインを決めているわけではありません。
意図をこちらがわからずに修正依頼を出すことで、優れたUI/UXが潰されてしまう可能性があります。
こちらが指摘をした際にデザインの意図を説明してくれる場合は問題ないのですが、あくまでも「お客さん」という立場のため、「客要望」として指摘をそのまま取り込んでしまう可能性があります。
なので、なぜそうしたのかをこちらから確認する必要があるのです。これは私たちの勉強にもなるので一石二鳥でもあります。

デザインのチェック

まずはデザイン自体のチェックです。

☑１．画面項目の漏れがないか

☑２．誤字脱字はないか

特に専門性の高いシステムの場合、一般的に使用しない単語を使うこともあるので注意が必要です。

☑３．表記ゆれがないか

過去にあった例ですが、画面によって「歳」と「才」で表記ゆれがありました。
他にも「yyyy年MM月dd日」と「yyyy/MM/dd」といったバラつきも注意する必要があります。
数値や英字の半角・全角も統一していなければいけません。

☑４．文字サイズは適切か

☑５．文字間隔は適切か

☑６．余白は適切か

☑７．フォントは統一されているか

☑８．項目を増やしても減らしてもレイアウトが崩れないか

検索条件や検索結果一覧などで項目を増やしてレイアウトが崩れないかをチェックします。
検索結果一覧では件数0件の場合もレイアウトが崩れないか確認します。

☑９．最小・最大文字でレイアウト崩れが起こらないか

ブラウザの開発者ツールでHTMLを変更しながら確認すると効率良くチェック出来ます。

☑１０．文字の折り返しが適切か

最大許容文字数が多すぎる場合、文字の折り返しがないと見づらい画面になってしまいます。
「レイアウト崩れが起こらないか」という観点だけでなく適切な折り返しがされるかもチェックします。
その際に「半角英数だけ」で最大許容文字数の文字を入力してみてください。
実装によって「半角英数だけ」の場合に折り返しが効かないことがあります。

☑１１．異なるブラウザでレイアウトの差異が出ないか

事前に合意したすべてのブラウザでのレイアウト確認をするべきです。

☑１２．指定幅でレイアウトが変わるか（レスポンシブの場合）

コーディングのチェック

次にコーディングのチェックです。

☑１３．ブラウザのエラーが発生しないか

大前提です。
ブラウザで開発者ツールを立ち上げて、コンソールを確認しエラーが発生していないかをチェックします。

☑１４．全イベントが動作するか

ボタンやチェックボックス等すべてブラウザエラーを出さずに動作するかチェックします。
欲を言えばデザイン会社がコーディングしたJavascriptはすべて動かしておきたいです。

☑１５．GET/POSTを意識したコントロールになっているか

これは一番の落とし穴かもしれません。意外と見落としがちで、修正も面倒です。
「POST送信するイベントのボタンがaタグになっていた」など良く聞く話です。
aタグをボタンのように見せる場合はGETリクエストの場合だけにしましょう。

☑１６．nam・id・class属性が適切な命名になっているか

特にnameはPOST時にパラメータとして使用されるため重要です。
item1,item2,item3・・・のような命名になっていると開発時に修正しなくてはなりません。

☑１７．CSS・Javascriptは適切な粒度で分かれているか

ひとつの画面でしか使わないスタイルやJavascript関数を共通部品に書くべきではないです。
画面固有のCSS・Javascriptの外部ファイルを作成するべきです。

☑１８．CSSにて隣接セレクタを多用していないか

これは個人的に悩まされたことがあるので観点に入れています。
隣接セレクタが悪いと言うわけではないのですが、コーディング中に独自にdivタグ等を入れたくなる場合があります。
意図を持ってタグを追加した際に隣接セレクタを多用したデザインだとレイアウトが崩れてしまいます。

☑１９．そのデザインは実現可能か

「jQuery.validationEngine」等の入力内容のリアルタイムチェックを例に説明します。
入力内容のリアルタイムチェックを行うサイトが増えていますが、入力チェックにDBの様々なレコードをチェックしてそれなりに時間がかかる場合があります。「Ajaxで通信⇒DBから値を取得⇒チェック処理⇒結果を返却」の一連の流れで1秒ほどかかるとしましょう。そうした場合にリアルタイムチェックだと入力してから入力結果が表示されるまでタイムラグが発生します。
このように、開発者目線での実現可能かのチェックは必須です。

☑２０．コーディングしやすいソースになっているか

「このデザインに動的処理を実装するなら」を良く考えながらチェックすれば良いと思います。
これは具体例をあげるのが難しいですが、例えばコンボボックスをdivタグだけで作っていたらコーディングしづらいとわかると思います。
そのようにチェック時にその後の工程であるコーディングを意識するべきです。

さいごに

上記のチェック項目はデザイン発注時に予めデザイン会社に共有しておくと手戻りを減らせるかもしれません。
他にも思い出したら追記しようと思います。
「こんな観点でも見た方が良いよ」というアドバイスがございましたらコメントください。

以上です。