Webチームの蔵下です。先日、弊社デザイナーの高森が公開した記事「コンポーネントを活用したアプリケーション群のデザイン」で紹介したように、aptpodではフロントエンドエンジニアとデザイナーとで、頻繁に議論を重ねながら開発を進めています。
開発中もコミュニケーションを取り合うことでお互いの認識齟齬は減らせるのですが、実装着手前にデザイン面で不確定要素が多いほど手戻りの手間（工数）が膨らんでしまいます。
実装着手前にすべての不確定要素を解消することは難しいですが、開発中に議論になりやすいポイントにはいくつかのパターンがありました。それを実装着手前のデザインレビューで確認できるようにチェックリストとしてまとめましたので紹介します。
チェックリスト
現在もブラッシュアップ中のチェックリストです。アプリケーションごとにチェック項目は変わりますが、議論になりやすい項目を中心に解説します。
1. 画面サイズ ・最大・最小幅でも崩れないデザインになっている ・画面構成要素ごとに可変・固定幅のルールが決まっている 2. フォント ・使用するフォントのライセンスに問題がない ・OSの違いによるフォントの差異が考慮されている 3. テキスト ・最大文字数が考慮されている ・表示領域を超える文字数のテキストが入った場合の挙動が決まっている 4. UI ・ボタンのhover, active, disable状態のデザインが作成されている ・最小幅表示でもダイアログが欠けないように考慮されている ・フォームのバリデーション結果を表示する領域が考慮されている 5. 例外 ・API実行箇所のエラー表示が考慮されている ・データ件数0件の表示が考慮されている 6. アニメーション ・アニメーションを設置する場所・イメージが共有されている
1. 画面サイズ
・最大・最小幅でも崩れないデザインになっている ・画面構成要素ごとに可変・固定幅のルールが決まっている
アプリケーションは表示する画面サイズによって見え方が変化します。通常の画面サイズできれいに収まっているレイアウトでも、仕様上の最小サイズだと要素が1画面で表示できずレイアウトが崩れてしまう恐れがあります。
実装着手前に、目の前のデザインが画面サイズごとにどう見えるのかをイメージすることが重要です。 画面を構成する要素ごとに、幅のルール*1や、表示のルール*2をデザイナーと事前にすり合わせておきましょう。
2. フォント
・使用するフォントのライセンスに問題がない ・OSの違いによるフォントの差異が考慮されている
ネット上にはWebフォントの技術的な話題は多いですが、ライセンスについて言及されている情報はあまりありません。フォントファイルをそのままサーバーへ設置して配信することは問題がありそうということは想像しやすいですが、 サブセット化がフォントの改変にあたるためフォントによっては規約違反 であることは見落とされがちです。デザインで使用されているフォントの実装方法がライセンス的に問題がないか*3、念のためデザイナーに確認しましょう。
アプリケーションによっては、OSにプリインストールされているフォントでデザインを構成する場合もあります。デザイン作成作業はmacOSで行われることが多いため、Windowsで適用されるフォントでもデザインに問題がないかデザイナーに確認しておきましょう。
3. テキスト
・最大文字数が考慮されている ・表示領域を超える文字数のテキストが入った場合の挙動が決まっている
アプリケーションの開発中は、領域内に収まる理想的なダミーテキストで実装を進めがちです。そのままの状態で実装を進めると、重要な情報なのに途中でテキストが欠けてしまう、文字数が多くなってしまい想定外の折返しが発生するなどの不整合に気づくのが遅れてしまいます。
仕様策定の段階で最大文字数をクライアントとすり合わせ、どうしても運用してみないと判断できないという箇所は、想定する最大文字数を超えたときの挙動も検討しておきましょう。3点リーダーで省略しても問題ない情報なのか、問題がある場合はツールチップなどで全文表示できるようにするといったところまで検討できると安心です。
4. UI
・ボタンのhover, active, disable状態のデザインが作成されている ・最小幅表示でもダイアログが欠けないように考慮されている ・フォームのバリデーション結果を表示する領域が考慮されている
UIは、ユーザーアクションやAPIのレスポンスによって影響を受けるため、デザイン作成時点で見えづらい部分が多いです。使用するUIの種類によっても確認ポイントが変わってくるため、デザイナーと認識を合わせておきましょう。
5. 例外
・API実行箇所のエラー表示が考慮されている ・データ件数0件の表示が考慮されている
例外のパターンはデザイナーから見えづらい部分のため、フロントエンドエンジニアの方で事前にリストアップしておくと、デザイン作成の漏れを減らせます。例外とは少しニュアンスが違うかもしれませんが意外と見落としがちなのが、データ件数が0件の表示です。実際の運用に入ると目に触れる機会も減るため不要に感じますが、検索結果の0件表示などと共通化して用意しておくことで、アプリケーションのUXが向上します。
6. アニメーション
・アニメーションを設置する場所・イメージが共有されている
アニメーションは、アプリケーションのUXに大きな影響を与えます。過度なアニメーションはユーザーへ不快感を与え、適切なアニメーションはユーザーの行動をサポートし安心感を与えます。
アニメーションにはさまざまな手法があり正解はないのですが、私は普段から 統一感 を意識しています。無理に複雑なアニメーションを多用するのではなく、シンプルなアニメーションをアプリケーション全体で統一することで、ユーザーも無意識に規則性を認識でき、わかりやすさにつながります。
アニメーションの解説だけでも記事が1本書けそうなので本記事では深堀りしませんが、シンプルなアニメーションだけで心地よさを伝えられるコツを一部紹介します。
- 使用するeasing, 秒数は用途によって統一する
- easingに関しては linear + もう1種類くらいが喧嘩しない
- 細かなeasingの確認はイージング関数チートシートがおすすめ
- 数あるeasingの中で緩急をいい感じに出しやすい Expo がおすすめ
- inとoutで同じ秒数・easingにこだわらない
- inはユーザーへのわかりやすさのため、outは次の操作への邪魔にならないようにするため
- よくやる組み合わせ（秒数は例）
- in（MouseOver）は0.5sで Expo
- out（MouseOut）は0.2sで linear
まとめ
フロントエンドエンジニア目線でのデザインチェックリストを紹介しました。本記事で一番伝えたかったことは、 一つの要件をフロントエンドエンジニアとデザイナーの異なる目線で見ることで、一人では気づけなかったことを互いに補いあえる ということです。実装に入る前にお互いに意見を出し合うことで、実装が始まっても納得感を持って突っ走ることができます。
今後もさまざまなアプリケーションへ実戦投入し、チェックリストをブラッシュアップしていければと思います！
*1:画面サイズによって幅が伸縮する可変幅、画面幅が変化しない固定幅のどちらにするかを決めます。
*2:画面サイズによって表示・非表示を切り替えるのか、表示させる場合はどう表示するか（最小サイズ時はナビゲーションを畳んで開閉できるようにするなど）のルールを決めます。
*3:フォントのライセンスについてはこちらの記事「フォントのライセンスまとめ」で詳しく紹介されているので参照ください。
