デジタルビジネス部所属Webデザイナーの今井です。
動的サイトのデザインというのは静的サイトに比べると変化が多く、その分考慮すべきことがたくさんあります。
今回はWebディレクターやデザイナー向けに手戻りの少ないテンプレートを作成するポイントをご紹介します。
文字数の増減による変化
商品名やニュース記事のタイトルなど、文字数が一定ではない情報は動的サイトには数多く存在します。
ECサイトの一覧では画像の下にタイトルと金額が、ニュースサイトでは画像の下に記事タイトルや日付等が入るのはよくあるパターンですが、このタイトルがすべて同じテキストであるというのもワイヤーフレームやデザインではよくあるパターンです。
しかし実際にはタイトルはデザインの想定通りにはまらないことも少なくありません。
タイトルを2行で想定したデザインの場合、タイトルが1行分しかなかったらその下の要素は上につまる？それとも位置は変わらない？
デザインにあるより長いタイトルもそのまま全部表示する？それとも2行を超える場合は「…」と省略する？
タイトルの表示方法についてはシステムの仕様はあまり深く関わらないため組み込みで戻ってくることは少ないです。
しかし見栄えに関わるため、実態に近い状態を想定してUIを考慮して決めておくことで実装後の修正を防ぐことができます。
要素の増減による変化
文字数の長短以外にも、要素そのものが増えたり減ったりすることもよくあるケースです。
閲覧したアイテムを他のページで一覧表示する場合、1列5件まで表示できるとして、6件以上あったらどうなるのか。
最大5件までしか表示しない？それとも2列目もある？あるいはスライダーが起動する？
これはシステム要件とも関わるので、事前に確認しておきたいポイントです。
バリエーションの網羅性
ECサイトの場合他にもよくある変化として、購入可能、完売、予約、再入荷待ちなどのステータスがあげられます。
また、新着やおすすめなどのタグデータを持つものもあるし、セール価格を表示することもあります。
ワイヤーフレームでは考えられるすべてのパターンを網羅し、必要なだけデザインのバリエーションを作成しておくことで、コーディング時に必要なパーツを網羅することができ、組み込み時のパーツ不足による手戻りを防ぐことができます。
データの表示方法
動的サイトでは多くの項目がデータベースの値を出力することで表示されています。
ここで気をつけたいのは、データベースから出力されるデータにはタグを挿入できない、ということです（元々のデータにタグが入っている場合は別ですが）。
例えば商品名や記事タイトルのような要素はデータベースでは１つのデータとして格納されていて、テキストの一部だけ太字にしたくてもできないし、読みやすいように途中に改行を入れることもできません。
日時表示をする際に、日付と時間が1つのデータとして扱われていたら、時間だけ小さく表示する、ということはできません。しかし、日付と時間がそれぞれ別のデータとして存在していたら、時間だけ小さく表示することができます。
データベースにどのようにデータが格納されているかはデザインに落とし込む際に大事なポイントです。
ボタンクリックによる挙動
Webページには多くのボタンやリンクが存在します。
クリックして遷移する、フォームが送信される、jsによるインタラクションが発生するというのが予想される挙動ですが、動的サイトのコーディングをする場合ページ遷移を実装するかどうかは場合によるため、基本的に実装しておくべき挙動がある場合はコーダーに挙動に関する情報を共有しましょう。
特にモーダルやtoggleのような要素は、テンプレートをコーディングするコーダーが起動するところまで実装するのか、システムに組み込む際にエンジニアが実装するのか線引きが曖昧な部分があるため、コーディング時に何を実装すべきかは組み込むを行う開発者と協議して明確にしておいた方がよいでしょう。
toggleする要素の変化
メニューボタンをクリックすると折り畳まれていたメニューがtoggle展開する。よくある仕組みです。
また、最初の数行だけ表示して「もっと見る」を押すと残りがtoggle展開で表示されるというケースもよくあります。
一度展開した要素を再び閉じることができるのか、閉じることができるなら「もっと見る」のテキストが「閉じる」に変化するのか。
よくあるがゆえに「普通こうなるだろう」という思い込みで挙動に関する情報が足りないことがあります。
「もっと見る」は「閉じる」に変わるのが普通かもしれないし、「もっと見る」を開いた後は閉じられなくなるのが普通かもしれません。
当たり前の挙動をする場合もコメントやデザインで明示しておくことで、当たり前を共有することができます。
モーダルの挙動
メッセージや拡大画像、情報を表示する際によく使われるモーダル。
情報やフォームを表示する場合、モーダルで表示されるコンテンツがブラウザの高さにおさまらない場合、ブラウザ全体がスクロールするのか、モーダル内でスクロールするのかというのがまず大きなポイントです。
モーダル内でスクロールする場合、見出しや下部にあるボタンは固定されるのか、固定される場合、それぞれどの程度の領域が必要になるのかをデザインの段階までに決めておかないと、コーディング時に思ったより固定される領域が大きくてコンテンツが見づらい、ということが起こります。
また、モーダルは基本的に閉じる手段が必要です。
×ボタンや閉じるボタンが設置されているか、すべてのモーダルで同じ位置にあるか、あるいはモーダル内から別ページに遷移させるために閉じられないようにするのかを、システムの仕様も踏まえて決めておく必要があります。
画面全体を半透明のオーバーレイで覆っている場合、オーバーレイをクリックして閉じるかどうかも必要な情報です。
0件/エラーパターン
一覧で0件だった場合、フォームの入力エラーなどは必要ながらもつい忘れられがちな要素です。
特にフォームのエラーはシステム的に出力されるので、デザインを作成する際にはすべてのフォームで統一されたデザインにしておく必要があります。
フォームが存在するすべての画面にエラーデザインを作ることは時間もコストもかかりすぎるため、通常はピックアップされた2〜3画面にエラーパターンを追加する程度になりますが、フォームはエラーがでることを念頭にデザインを作成すると良いでしょう。
最後に
動的サイトで変化するポイントは他にもいろいろありますが、これまで私が経験した多くのWebサイトに当てはまるポイントをご紹介しました。
どこがどう変化するか、というのは想像力も必要です。上記のポイントを踏まえて、自分が作成しようとしているワイヤーフレームやデザインが実際に動くとどうなるかを想像してみてください。今のワイヤーフレームやデザインでは足りないパーツや、必要なパターンが見えてくるかもしれません。
