なぜウェブで Pixel Perfect を追求すべきではないのか

We’re always optimizing for whatever’s most important to us right now

Pixel Perfect はそれが本当に重要な場合にのみ意識すべきであり、そうでなければ往々にしてお互い損をする結果に陥ってしまう。

この問題には、僕が思うに2つの根本的な原因がある：

なぜグラフィックデザインをそのままウェブに適用できないのか

グラフィックデザインは通常、固定されたサイズやレイアウトを持つため、視点がまったく異なる。フォントサイズも pt のような固定サイズでタイポグラフィやデザインを行うことが多い。

しかし、ウェブは生まれつき多様なインタラクションやサイズを前提としている：

フォントサイズやフォントの種類さえも、ユーザーの設定によって影響を受ける。（匙を投げて文字を画像として書き出さない限りは）

一度 Pixel Perfect の思考に囚われると、それはプロダクトにおいて「複数のデバイスに適応するための最適化」ではなく、「特定のサイズのためだけの最適化」として現れてしまう。

例えば、CSS Grid の auto-fill や auto-fit を使って「画面（あるいはコンテナ）の幅いっぱいに敷き詰める」レイアウトは、このように書くことができる。

特定の状況、特にワイドスクリーンのメリットを活かしたい場合、このような UI は非常に有用だ：

しかし、このような UI 表現はデザインカンプ上で明確に定義することが難しく、特にウェブ UI 出身ではないデザイナーにとってはなおさらだ。この時に Pixel Perfect を追求してしまうと、かえってユーザー体験にとってより良い選択肢を真っ先に捨て去ることになってしまう。

テーブルデザインは奥が深い学問だ。僕が以前の記事で書いたように、ウェブでテーブルをデザインする際にはいくつか気を配るべきポイントがある。例えば：

一般的にテキストは左揃え、数値は右揃えにする
数値が変動する場合、数値の変化によって幅がガタガタと動くのを防ぐために、font-variant-numeric: tabular-nums を追加する（フォントがサポートしている場合）

こうした細部は、デザイナーが知らず、開発者も気を配っていなければ、実装されないままになってしまうかもしれない。

CSS において vh/vw は非常に便利な単位だが、Pixel Perfect の思考に縛られていると、最終的に手っ取り早く済ませるために、直接固定値を書き込んでしまうかもしれない。

iOS の Safari ではアドレスバーの配置場所を選択できるし、iOS 12 以降には Safe Area と呼ばれる利用可能な領域やレイアウト効果がある。このような状況で、すべてのデバイスを一つひとつ網羅しようとすれば、開発にとってもデザインにとっても大きな負担になる。

双方が追求している目的が何なのかを知る必要がある。デザイン側からすればカンプの UI が完璧に表現されることを望み、開発側からすればメンテナンスしやすくレスポンシブな方法で UI 要件を満たしたいと望む。

僕たちが本当に求めているのはデザインシステムだ。余白、スペーシング、フォントサイズなどの設定を一度定義しておけば、さまざまなデバイスに適用できるものだ。

RWD（レスポンシブウェブデザイン）は今なお色褪せない。CSS はますます進化しており、10年前に比べればこれをうまく実現することは格段に容易になった。

最近、ある Design Engineer —— jhey の Twitter をよく追っている。彼は現在 Shopify で Design Engineer を務めており、以前は Vercel や Google に在籍していた。

彼の CSS は円熟の域に達しており、多くの UI アニメーションやインタラクションは、CSS の動向を長年追い続け、かつ独創的な発想があって初めて実現できるものだ。彼が CSS に精通しているからこそ、ウェブ上で生き生きとした効果を生み出すことができる。

僕が考える理想的な UI デザイナー（ウェブに関して言えば）は、少なくとも CSS に精通しているべきだ。しかし、台湾でこれを実現するのは難しいかもしれない：

前職では幸運にもウェブ UI をかなり理解しているデザイナーたちと一緒に仕事ができた。CSS を書くのは非常に骨が折れたが、とても面白く貴重な経験だった。