エンジニアがUIにフィードバックするうえで大切にしたい3つの観点
UIデザインの現場では、デザイナーとエンジニアの間で様々な問題が起きることがあります。いざエンジニアが実装しようとすると思わぬ矛盾が見つかったり、運用するとき予期せぬデータによって表示が崩れてしまったり…そうしたトラブルは、事前に実装・運用目線からフィードバックする機会があれば防げるかも知れません。そこで今回は、エンジニアが技術的な目線を持ってデザインにフィードバックするポイントをピックアップしてご紹介します。
筆者はWebアプリケーションを専門としており、本稿の内容も基本的にはWebサイト・Webアプリの構築を前提としています。ネイティヴアプリケーションについてはこの限りではない可能性があります。
なぜエンジニアがフィードバックをすべきなのか
UIとは実装されて初めて完成されるものであり、実装するうえでの技術的な実現可能性や、デザインが破綻することなく運用に耐えうるか、といった視点で制作しなければなりません。しかしUIデザイナーは情報の構造化からビジュアルデザインまで、非常に広範な領域をカバーしなければならないため、一人で全ての視点を往復しながらUIを作るということは難しいと感じています。
その中でもとりわけ難しいと思われるのがエンジニアリングに関わる知識です。今日のWebアプリケーションを構築する技術スタックは非常に複雑なうえ進歩が早く、数ヶ月単位でトレンドが移り変わっている状態であり、ただでさえビジュアルデザインについて膨大なインプットを求められるUIデザイナーが独力でキャッチアップすることはあまり現実的ではありません。そこで、そうした領域に専門性を持つエンジニアがデザインフェーズに加わることで、UIを多角的な視野で吟味し、その質を高めると共に、実装・運用に関する不確実性を削減することが可能になると考えられます。
こうしたエンジニアとデザイナーの協業について取りうるアプローチは様々だと思いますが、ここでは最も手軽に取り入れることができる「フィードバック」に焦点を絞り、そこでチェックすべき観点について書いていきたいと思います。
観点1. 量と質
WebメディアやUGC (ユーザー生成コンテンツ) を扱うサービスのUIである場合、デザイン作業を行う際にはダミーデータを用いることになると思います。しかし、そうしたデータが「あるもの」として仮定してしまうことで見えづらくなるリスクは大きく、運用フェーズに入った後でデザイナーが想定していなかった「例外」が発生することが少なくありません。こうした問題に対しては、投稿、テキスト、画像など、様々なコンテンツの量的な変化が質的な変化へと転換するポイントを注意深く探る必要があります。
こうした変化を起こすものとして
- コンテンツ (メディアであれば記事など) の量
- テキストの量
- 画像の縦横比
などが挙げられます。
一般的な例としてWebメディアの投稿一覧のようなページを考えたとき、長いタイトルが入ることにより行が溢れることがあります。この時、複数行に展開されることを許容するのか、行末に「…」を付与して1行に収めるのか、ということは予め話し合っておくべきでしょう。コンテンツの優先度付けや、実際に運用する場合どの程度の長さのテキストが入る可能性があるのか、といったことは運用担当者の方に判断を仰いでみてもいいかもしれません。
タイトルの行溢れ制御の例。カードUIなら要素の高さそのものが変わる可能性もある。
また、キーワード検索などの結果表示にも同様のデザインを用いるなら、半端な数になってしまう場合や、結果が存在しなかった場合も考慮する必要がありますし、サムネイルとして実際の表示と縦横比が異なる画像が使用された場合にトリミングするのか、あるいは余白を作るのか…といった様々な論点があります。
こうした問題は仕組みがあったうえで見た目を調整する、という文脈における話ですが、もしも可能なら仕組み (デザインシステム) を作る段階からエンジニアとデザイナーの間で共通認識を取っておくことが望ましいと思います。その際も極力さまざまなエッジケースに留意する必要がありますので、 “Zero one infinity rule” などが参考になるかもしれません。
ちなみに、意外と忘れがちなのがログインサービスなどでよくあるヘッダーの端にユーザ名を表示するタイプのUIにおける行溢れです。「そんなに長い名前使う人いないでしょ」という結論が出がちですが、UIを作るのであればルール上許容されているコンテンツ全てに対応できるのが前提です。そういった議論を可能な限り早い段階で行っておくことで、後から発覚して緊急対応することになるリスクを減らせそうです。
観点2. スタイルの規則性
デザインツール上のスタイルは個別に設定してしまえばその通りになりますが、実際の環境ではそういう訳にいきません。Webサイト・Webアプリの実装においては基本的にCSSを用いたスタイリングを行うため、こうしたレイアウトを特定の「ルール」として記述する必要があります。必要以上に複雑なルールを組んでしまうとメンテナンスが困難になると同時にエッジケースを発生させやすく、表示崩れの原因となるため、常にできるだけ単純なものに保つことを心がけなければなりません。
具体的には:
- 画面幅やコンテンツが変化したらどういう規則で変化が起きるのか
- タイポグラフィや色にはどういった意味が与えられているのか
という感じです。
Webメディアの例に戻ると、フッターなどに配置される「リンク集」のようなものは極めてレイアウトが不安定であることが多いです。ホワイトボーディングなどを行い、どういった挙動をすれば様々な状況で意図した通りのデザインが再現可能かを検討しましょう。
固定幅の余白を保ちつつ等間隔で左合わせのテキストエリアが伸縮するナビゲーション。実際は各コンテンツの最小幅や余白を含めたコンテナ全体の最大幅なども検討する。
こうしたレイアウトに関するものに加えて、文字の大きさや要素の色などに関するルールは見た目よりも意味に着目して共通認識を取っておくことをおすすめします。「大きなテキスト」「赤色」といった見た目は、その根拠となる「見出し」「警告」といった意味的な性質に基づいています。そうした部分に関する合意があれば、他のページでスタイルを誤用してしまったり、デザインレベルで矛盾が生じたときにも間違いに気づきやすくなります。
観点3. 表現と使い心地
UIデザインは情報を構造化して「分かりやすさ」を追求するだけでなく、様々な視覚的表現を用いてユーザに特定の感情を呼び起こすことも求められます。そうしたインパクトを求めるグラフィックデザイン的なアプローチやWebGLなどを駆使したリッチなコンテンツは企業のWebサイトやキャンペーンサイトなどで頻繁に用いられますが、ページパフォーマンスやアクセシビリティに悪影響を及ぼすようであれば、その必要性を問い直すべきです。
「アクセシビリティ」という言葉は本来、身体にハンディキャップを抱えている人たちだけのものではなく、“access (アクセス)” + “bility (できる)” という言葉が意味する通り「誰でも」コンテンツにたどり着いて情報を得られるようにすることです。ウェブ標準化団体W3Cは以下のように述べています。
ハードウェア、ソフトウェア、言語、文化、所在地、物理的/精神的能力にかかわらず、ウェブは基本的にすべての人に向けて設計されています。ウェブがこの目的を達成できると、さまざまな聴力、視力、認知能力をもつ人々がウェブにアクセスできるようになります。
具体的には、
- 画面の小さな端末でも正しく表示できるか
- 標準的なスペックのマシンでアニメーションが再生できるか
- コンテンツの閲覧に必要なスクロール量は適切か
のような観点です。
例として、ファーストビューにインタラクティブなアニメーションを配置するとします。Lighthouseなどを利用して測定したページパフォーマンスが著しく低下する場合、動画への差し替えや、必要性が低いと判断できればコンテンツそのものを取り除くという対応も検討すべきでしょう。とにかく優先すべきなのは「一部のユーザーを感動させること」よりも「全てのユーザーが問題なく閲覧できること」です。
さいごに
「エンジニア視点でデザインにフィードバックする観点」として3つを紹介しました。
今回紹介したものは極めて初歩的な内容であり、これだけでは実装・運用時の思いがけないデザインエラーをゼロにすることはできません。しかし、こうした不確実性に対して真剣に向き合い、素晴らしいユーザー体験を実現しようとする試みはデザイナーだけでなくエンジニアも行うべきであり、そのマインドセットを共有すること自体が大きな一歩となり得るのではないかとも思います。エンジニアの皆さんもぜひ専門性の垣根を越え、作り方を「デザイン」していきましょう。
グッドパッチでは、領域を超えてプロダクトをデザインするGo beyondなエンジニアを募集しています。気になった方は是非、まずは気軽に話を聞きにきてください！
