Webフロントエンドエンジニアにやさしいデザインファイルの作り方

Sketch - The digital design toolkit

画像はSketch最高っていう顔です。

HTMLやCSSを書くWebフロントエンドエンジニアにとって、Webデザイナーが用意した理想像を現実に落とし込むことは1つの使命であり、費用対効果への葛藤に揺れる中で「技術的に難しいから」という理由でデザインを却下したくないのは誰しも同じだと思います。一方で、技術的に難しくなくとも、デザインファイルの作り方次第ではエンジニアの実装効率も多少なりとも変わってきます。そこで、僕のデザイナー及びエンジニアとしての経験則から、HTML/CSSで実装しやすい（≒Webフロントエンドエンジニアにやさしい）デザインファイルの作り方を、Sketchでの用例も挙げつつまとめてみます。近年はFigmaが注目されつつありますが、基本的な話は共通すると思います。

本来ならばデザイナーにこそ読んでいただきたい記事ではありますが、デザイナーからしたらこれらはエンジニアのエゴであり、エンジニアからすればデザイナーのプロフェッショナル性を問うテーマでもあります。それらを踏まえて、この記事は「エンジニアが先導する形で、デザイナー“と”一緒に読んでほしい記事」として、Qiitaに投稿しておきます。

おことわり

• 記述している内容は、あくまでWebフロントエンドにおける知見であり、ネイティブアプリケーションのUIデザインなどにおいては事情が異なります
• 本記事では便宜上、HTML及びCSSの記述を主担当とする職種を“エンジニア”、Webページのデザインを主担当とする職種を“デザイナー”と表記しています
• 納期の関係や開発スタイル、プロダクトの特性などによって、必ずしもエンジニアにとって嬉しい知見になるとは限りません
• エンジニアから「これを読んでおいて」と一言で済ますような知見の押し付け合いは最悪であり、こういった知見はエンジニア/デザイナー双方合意のもとで効果を発揮するものであるため、必ずコミュニケーションを取って開発スタイルを決めましょう

1. デザインツール

1-1. デザイン関連のサービスやツールを絞る/デザインデータの種類を絞る

至極当たり前のことではありますが、プロダクト開発において依存するサービスやツールは少ないことに越したことはありません。スマートフォンの普及でインターネットがとても身近になった今、デザインの重要性は以前よりも増していることでしょう。それに伴い、プロダクト開発におけるデザインプロセスも多様化し、便利ツールなるものが乱立している状態にあります。10年前にはまだ存在していなかった、プロトタイピングツールやデザインファイルのバージョニングツールが挙げられるでしょう。

これらのツールを使うことは決して悪いことではありませんが、デザイナーだけでなく エンジニアも巻き込む形で“使わなければならない”ツールを増やすことは避けておきたい ところです。UIデザインツールとしてSketch、Figma、Photoshopの3つを同時利用するのではなく、SketchならSketchで1本にしぼり、エンジニアには .sketch のSketchファイルを渡すようにしましょう。Photoshopを写真編集ツールとしてのみ利用するのであれば、 .psd のPhotoshopファイルを渡すのではなく、JPEG（またはPNG）などの“完成した”画像形式でエンジニアに渡すようにしましょう。

2. レイヤーとアートボード

2-1. SketchのPagesを利用するか決める/運用スタイルをエンジニアに伝える

SketchのPagesを用いる/用いない場合、その運用スタイルをエンジニアに伝える ようにしましょう。

Pagesの機能を使うデザイナーもいれば、使わないデザイナーもいます。特に『Abstract』のようなデザインファイルのバージョニングツールを利用する事例が増えた今、Pagesを利用せずWebページごとにSketchファイル自体を複製する……といった運用スタイルを採用するチームも目にするようになりました。

エンジニアはどのUIがどのSketchファイルに入っているのかを、Sketchファイル名から推測するかと思いますが、Pagesの中は見落とす傾向にあります。「お問い合わせボタンのスタイルを探すために お問い合わせ.sketch ファイル内をくまなく探したところ、デザイナーに確認すると Page 2 に入っていることが分かった」など、無駄な時間の浪費は避けておくためにも、そもそもPagesを積極的に利用するのか、それとも利用しないのかを話し合っておきたいところです。

もしPagesを利用するのであれば、 それぞれのPageには適切な名前を付けましょう 。自動生成される Page 1 や Page 2 などの名前は、Sketchファイルが複雑になるほど混乱を招いてしまいます。

2-2. レイヤーのロックを解除してSketchファイルを渡す

エンジニアへ渡すSketchファイルには、ロックされた状態のレイヤーをできる限り含めない ようにしましょう。

レイヤーのロック機能はデザイナーにとって便利な機能ですが、アートボードから直接レイヤーを選択することができなくなります。エンジニアは、アートボードからレイヤーを1つ1つ選択し、それぞれのスタイルを確認→コーディングという流れで作業します。この際にレイヤーがロックされていることでレイヤーを選択できないとなると、ロックされているレイヤーをレイヤーパネルから探し、解除するという手間が生じます。エンジニアにとって各レイヤーのスタイルを簡単に見られないことは、想像以上に大変な問題となるわけです。

とはいえデザイナーにとってレイヤーロックを一切使えないことは、作業効率を下げる要因の1つになってしまいます。ロックはできる限り抑えつつも、“兄弟関係のレイヤーを複数ロックする場合は、グループ化した上でグループにロックを掛ける”など、ロック解除の回数を減らす工夫をしておきたいところです。

2-3. ブラー効果は、常にオフにする

パフォーマンスの観点から、Sketchのブラー効果は常にオフに しておきましょう。

Sketchでは、ブラー効果を簡単かつ非破壊でレイヤーに適用できます。多くのデザイナーは、これを写真に対して用いているでしょう。
残念ながらブラー効果を適用したレイヤーがアートボード内に存在する場合、そのSketchファイルを表示する際の負荷が急激に高くなってしまうのが現状です。これは、Photoshopのスマートフィルターのように、Sketchのグラフィック処理がまだそこまで最適化されていないためです。

エンジニアが操作するコンピュータ性能のリソースは、エンジニアリングに集中させるべきです。デザインファイルを表示したがために、本来のエンジニアリングに支障がでるようでは本末転倒。したがって、Sketchファイル表示時のパフォーマンス低下を防ぐために、ブラー効果をオフにした状態でSketchファイルを渡しましょう。

2-3-1. ブラー効果を適用した画像を取り込む

なにも決して“ブラー効果を使ってはいけない”という意味ではありません。またデザイナーからしてみれば、Sketchファイルを渡すときにブラー効果をオフにするというのも、デザインの俯瞰的なチェックに悪影響を与える要因の1つとなるでしょう。

経験的に、ブラー効果は写真などのラスター画像に対して用いるケースがほとんどです。そのような場合、 Sketch上でブラー効果を用いるのではなく、Photoshopなどでブラー効果を適用した画像をSketchへ取り込む ほうが、ブラー効果を細かく調整できるデザインの観点からも上述のパフォーマンスの観点からもメリットがあると思っています。
また写真以外にも、モーダルの背景に映り込むUIに対してブラー効果を適用させたければ、それこそ背景画像はダミー画像でも問題ないため、こちらもブラー効果を適用したダミー画像を背景画像として取り込んでおきたいところです。

2-4. アートボードは 1x サイズで作る

アートボードは等倍サイズで作成 しましょう。

日本で販売されているほとんどのスマートフォン/タブレットは、iPhoneのRetinaディスプレイを始めとする高精細ディスプレイが搭載されています。特に近年はスマートフォンだけでなく、パソコンも高精細ディスプレイを搭載することが多くなりました。これらのディスプレイは、 2px または 3px 四方を 1px 四方として表示することで、人間の肉眼でドット（ピクセル）を認識することが難しいくらい細かく表示しているわけですね。

Webページでラスター画像を高精細ディスプレイでもキレイに表示するには、等倍時の2倍のサイズで書き出し、等倍時のサイズを指定する必要があります。

<!-- 画像のサイズは 480x80 -->
<img src="/static/logo.png" alt="My Website" width="240" height="40">

このようなこともあって、アートボードのサイズを2倍のサイズで作成するデザイナーもごくたまに見かけますが、 Sketchはベクター画像を扱うツールなので、2倍サイズで作成する必要はありません 。 等倍サイズで作成しましょう 。Photoshopと同様、Sketchも書き出し時に画像サイズの倍率を指定できるため、書き出し時に2倍と指定すれば良いだけです。

また色数が少ない図形に関しては、SVG形式で書き出すのが良いでしょう。SVG画像はWeb上で手軽に扱えるベクター画像で、どのようなサイズで表示してもキレイに表示されます（そのせいか、SketchでSVG形式で書き出す場合は倍率を選択できません）。

余談ではありますが、個人的に、画像の書き出しはエンジニアに任せたほうが良いと思っています。どのような画像で書き出すとコーディングしやすいか、なども直感的に分かるからです。

2-5. 使用しないアートボードは、待避するか削除する

使用しないアートボードは、待避するか削除 しておきましょう。

Sketchファイルにおいてのアートボード構造は、デザイナーしか正確に把握できない情報です。使用するアートボードと使用しないアートボードが混在していた場合、それを識別できるのはアートボードを作成/編集したデザイナー本人だけです。
使用しないアートボードが混在していたことで、本来使われないデザインをエンジニアが実装してしまう可能性も考えられます。手戻りやこういった混乱を避けるためにも、使用しないアートボードは待避するか削除するべきです。

2-5-1. デザインファイルのバージョニングツールを用いる

使用しないアートボードを残したいデザイナーの多くは「もしかしたら後々使うかもしれない」という再利用の可能性を考慮していることがほとんどです。

そこで知っておきたいのがデザインファイルの“バージョニング”です。バージョニングとは、自分の任意のタイミングでコメントともにその時点のファイル状態を保持しておく、という概念です。エンジニアは『Git』などのツールを用いてプログラムのバージョニングを行うことが古くから当たり前になっていますが、デザイナーにもこのバージョニングの重要性が浸透しつつあると思います。

エンジニアが用いるバージョニングツール『Git』を用いて、デザインファイルをバージョニングするのも1つの選択肢として挙げられるかもしれませんが、1ファイルあたりの容量を考慮すると決して最善の選択肢とは言えないでしょう。大容量のファイルをGit上でうまく扱うGit LFSを用いたとしても、クローンやプルに膨大な時間がかかってしまいます。

過去に何度か方法を模索しましたが、結局 デザインファイルのバージョニングを行うのであれば、それに特化したツール/サービスを用いるのが現状のベスト でしょう。デザインファイルの本格的なバージョニングツールの先駆けとなった『Abstract』は多くのチームで採用されており、また最近ではSketch純正の『Sketch for Teams』も有力な候補となるでしょう。

2-5-2. アーカイブ用のPagesを追加し待避させる

大企業や一部の企業はツール1つ導入するだけでも稟議のハードルが高かったり、コストの観点から導入を却下されることもあるでしょう。そこで 私が推奨するお手軽かつシンプルな方法は、“待避用のPagesを追加し、待避させたいアートボードをそこへ移動する”という方法 です。この方法は、一度ボツになったデザインを再び採用するような場面でも、すぐにアートボードを探せますし復元も簡単です。

この際に、 old や archive アーカイブ などといった、使用されないことを示す単語をPagesの名前として採用する必要があります。個人的には、Pagesの接頭辞として _ を追加する管理方法が好きです。 _ が過去のデザインであるということを示すことができれば、Pageの名前を大きく変更せずアーカイブとして扱えるからです。多くのエンジニアは _ のような記号が接頭辞についていると「何らかの意味があるんだな」と推測してくれます。

• Top … トップページのデザイン
• About … アバウトページのデザイン
• _About … 過去のアバウトページのデザイン

ただし念の為にも、上記のような運用スタイルをエンジニアに共有しておきましょう。

2-6. Webページの最低横幅を決める/モバイル向けデザインは、最低横幅で作る

アートボードのサイズは、チームで決めたWebページの最低横幅で作るべき です。

まず第一に、Webページはモバイル向けネイティブアプリ以上に、多様な横幅で閲覧される媒体です。パソコンのOS上にウィンドウとして表示されるWebページは、ウィンドウをリサイズすれば横幅10pxでも10,000pxでも表示することができるわけです。 多様な横幅での表示に対応するために、Webページの最低横幅を決めておきましょう 。そして、 モバイル向けデザインのアートボードは、その最低横幅で作成 しましょう。

エンジニアはCSSの min-width プロパティを用いることで、最低横幅以下の横幅でWebページを見られたとしても、Webページ内に横スクロールが生じるように制御できます。しかしアートボードが最低横幅より大きいサイズで作られている場合、最低横幅で表示した場合のデザインが考慮されていないため、いざ実装するときにエンジニアから修正依頼が届くかもしれません。

個人的には、最低横幅を 320px にすることを、以下の観点からオススメしています。

1. 日本においてのiPhoneユーザは非常に多く、また（レンダリング時に） 320px という横幅を採用した『iPhone SE』がそれなりに流通している
2. 『iPhone SE』で利用可能なiOSがまだサポート中
3. 横幅 320px 未満の解像度を持ち、なおかつシェアの高いAndroid搭載スマートフォンが存在しない

とはいえ、現代において 320px という狭さはデザインの幅を狭める要因にもなるため、プロダクトのユーザ層の閲覧環境を考慮して決めましょう。 エンジニアリングの観点から、一度決めた最低横幅を広げることは大した問題になりませんが、最低横幅を狭めるのは結構な実装コストがかかってしまいます 。

2-7. PC向けデザインは、横スクロールが表示され始める最低横幅で作る

PC向けデザインのアートボードは、ウィンドウの横幅を縮めていったときに、横スクロールが表示される最低横幅で作る ようにしましょう。

2-6と同様、エンジニアがWebページを作成するときは、必ず“どこまでウィンドウを縮めれば横スクロールを出せば良いか”を考えなければいけません。Webページはウィンドウの中で表示されるドキュメントであるため、ユーザがウィンドウサイズを変更しても、レイアウトが崩れることのないデザインを実装する必要があります。

ちなみに、PC用デザインの横幅として、昔は 960〜980px 、数年前までは 1024px で作成されてたWebサイトが多かったものの、最近は 1200〜1280px で作成されているWebサイトをよく目にします。

2-7-1. Smart Guidesを活用する

エンジニアとしてありがたいのは、Smart Guidesを用いて最低横幅を示したSketchファイル です。最低横幅分をSmart Guidesで引いておき、最低横幅以上のアートボードを作成することにより、最低横幅よりも広い解像度を持つディスプレイでみたときのデザインも実装しやすくなります。

開発環境によっては、Smart Guidesが非表示の状態でSketchファイルが開かれることもあるので、Smart Guidesを使う場合はエンジニアにその旨を伝えて、Smart Guidesを表示するよう意識してもらう必要があります。

2-7-2. 横スクロールバーを表示させない

ネットサーフィンをしていると、横スクロールバーを表示させないレスポンシブなWebページを目にすることがあるでしょう。

レスポンシブ構造は端末の解像度に依存しないため、UXが向上される反面、横幅に応じて柔軟に要素の並べ方を変更させる必要があります。このようなデザインを採用する場合、どこまでウィンドウサイズが縮んだとき、どの部分をどう表示するのかを明確にしておく必要があります。エンジニアの腕だけでなく、デザイナーによるデザインのパターンも多く求められる高度な開発になります。

3. 図形とサイズ

3-1. サブピクセルを使用しない

0.5px や 3.3px などといった サブピクセル（小数点を含むピクセル）を使用してはいけません 。

Sketchではサブピクセルがサポートされています。これは、レイヤーサイズだけでなくフォントサイズ・位置などでも同様です。世の中のほとんどのパソコンやタブレット/スマートフォンは、最小単位として px を採用しています。つまり、画面内で表現できる最も小さな値が 1px なので、それを下回る 0.5px という値は本来扱えないはずです。

ではサブピクセルをCSSなどで記述した場合に、画面上にまったく表示されないかと言うとそうでもありません。サブピクセルをWebブラウザで表示した場合、周辺ピクセルを中間色で塗り潰すことによって、 1px 以下のサイズに見せるよう処理されます。しかしその機能はWebブラウザに依存するだけでなくOSやディスプレイにも依存するため、やはりサブピクセルを使うべきではありません。

スマートフォンのネイティブアプリの場合は事情が少し異なり、最近のほとんどのスマートフォンはiPhoneのRetinaディスプレイを始めとする高精細ディスプレイが搭載されています。そのようなディスプレイを搭載しているデバイス向けにデザインする場合は、サブピクセル（またはサブポイント）を指定しても問題ないパターンがほとんどです。
しかしパソコン……高精細でない格安の外部ディスプレイでも表示されることが予想されるWebページにおいては、サブピクセルがどう表示されるかは環境に依存してしまうのです。

これらのことから、 サブピクセルの使用は、Webブラウザやディスプレイの解像度によって表示内容に差異を生じさせるため、使うべきではありません 。よくネイティブアプリのデザイナーがWebデザインをする際に 0.5px のボーダーを多用している場面を見ますが、環境によっては表示されなかったり、または滲んで見えてしまいます。サブピクセルの利用は、要素のサイズだけでなく、フォントサイズや字間も同様に避けておいたほうが良いでしょう。

3-2. 繰り返し表示する画像は、パターンの単体画像も用意する

背景として 横方向/縦方向、または全方向に繰り返し表示するようなデザインにする場合は、パターン画像も用意 しましょう。

ページ全体の背景画像、見出しの背景画像、罫線のデザインなど、ウィンドウの幅に応じて繰り返し表示される画像は、それ1つで繰り返し表示しても違和感のない“パターン画像”をレイヤー（またはSymbols）かアートボードで用意しておきましょう。パターン画像1つさえあれば、エンジニアはCSSの background-repeat プロパティで簡単に繰り返しを実装できるようになります。

エンジニアにSketchファイルを渡す前に、作成したパターン画像が繰り返し可能か検証しましょう。例えば格子状の背景をデザインした場合、パターン画像は四辺にボーダーが設定された四角形ではなく、二辺にボーダーが設定された四角形になります。

3-3. Edge to Edgeなデザインは、引き伸ばし/繰り返し可能にする

Edge to Edgeなデザインは、引き伸ばしまたは繰り返しが可能なデザインに しましょう。

画面/ウィンドウの端から端までを覆うEdge to Edgeデザインは、今ではよく見られるデザイン手法の1つではありますが、ウィンドウの可変性を考えると、そこまで柔軟性の高いデザインではありません。

写真をEdge to Edgeで表示する場合、その写真を引き伸ばしても成立するようにデザインしましょう。引き伸ばしといっても、CSSの background-size プロパティに cover を指定することで、アスペクト比を固定したまま引き伸ばせますが、写真に映る重要な要素が領域外に出てしまう可能性も考慮しなければいけません。

写真ではなく図形をEdge to Edgeで表示したい場合、その図形は繰り返し表示可能か、もしくは引き伸ばして表示しても問題ないかを確認しましょう。

3-4. Smooth Cornersで角丸にしない

角丸の四角形を作成するとき、Smooth Cornersで角丸にしてはいけません 。

理由は単純で、技術的に実装するのが難しいからです。単純な角丸はCSSの border-radius プロパティで実装可能ですが、Smooth Cornersを実装するには、それなりの計算が必要になります。

どうしても用いたい場合は、画像として書き出し、そのまま埋め込む形でWebページに掲載されることを許容しましょう。

3-5. ボーダーを中央表示しない

ボーダーを設定する場合は、中央ではなく外側か内側に表示する ようにしましょう。

こちらも理由は単純で、技術的に実装するコストがかかるからです。外側か内側にボーダーを表示するだけならば、CSSの border または box-shadow プロパティを用いれば簡単に実装できます。

.outside {
  box-sizing: content-box;
  border: 2px solid red;
}
.inside {
  box-sizing: border-box;
  border: 2px solid red;
}

.outside {
  box-shadow: 0 0 0 2px red;
}
.inside {
  box-shadow: 0 0 0 2px red inset;
}

もちろん、外側表示と内側表示を組み合わせることで中央表示を擬似的に実装することは可能ですが、よほどのこだわりがない限り、コード的にも分かりづらい実装方法を強いるデザインを選ぶべきではありません。

3-6. 汎用的なコンポーネントをSymbols化する

よく使い回すコンポーネントは、Symbols化しましょう。

Symbolsを簡単に説明すると、レイヤーグループを一元管理し、どこからでも呼び出せるようにするというものです。そして一元管理もとのレイヤーに何らかの変更を加えると、そのSymbolsを呼び出したすべてのレイヤーに変更内容が同期されるといった特徴もあります。

例えば、5枚のWebページのデザインを、5つのアートボードで作成したとします。グローバルヘッダーはすべてのページに含まれるので、先ほどの5つのアートボードすべてにグローバルヘッダーのレイヤーをコピー＆ペーストしました。
さて、グローバルヘッダーのデザイン変更が必要な場合、Symbolsを使わないなら何をするべきでしょうか？やるべきことは1つです。最新のグローバルヘッダーのレイヤーを、5つのアートボードすべてに貼り付け直す作業です。ここで、もしも最新のデザインを貼り忘れたアートボードがあったとしたら、エンジニアは混乱してしまうでしょう。

先述したように、Symbolsは元のレイヤーに変更を加えると、呼び出されたSymbolsすべてに変更が適応されます。 アートボード単位でレイヤーが最新かどうかを管理する必要がなくなり、またエンジニアの混乱を防ぐためにも、使い回すコンポーネントは必ずSymbolsで管理 しましょう。

3-6-1. Overrides を活用する

Sketch 3.7から、Symbolsの管理はより便利になりました。大きな特徴として、Overrides（オーバーライド）が挙げられるでしょう。

エンジニアにとって“オーバーライド”という言葉は馴染み深いものかも知れませんが、デザイナーに向けて簡単に説明しておくと“もともとのSymbols内で使用していたテキストや色を、呼び出し元でだけ改変できる機能”です。

例えば“送信”という文言が含まれたボタンをSymbol化します。しかしページによっては、ボタンのスタイルはそのままで“キャンセル”といった文言に変更したいこともあるでしょう。そこで“送信”という文言をオーバーライドすることで、Symbol自体の文言を変更することなく、その呼び出したSymbolレイヤーの文言のみを変更することができます。オーバーライドを使わない場合、“送信”ボタンのSymbolsを解除して文言を変えるか、“キャンセル”という文言のためだけに新たにSymbolsを作らなければいけません。

3-6-2. 背景色に依存しないSymbolsを作る

あらゆるページのあらゆる箇所で使用するコンポーネントはSymbolsとして作成するべきですが、 背景色に依存しないSymbolsとして作っておきましょう 。

例えば、Symbolsを作成したときのアートボードが白色だった場合、黒色に不透明度を設定することで灰色を表現できますが、背景が赤いアートボードでそのSymbolsを使用すると、灰色として表示されなくなってしまいます。

意図しない色のコンポーネントが生まれてしまうことを避けるために、背景色に依存しない形でSymbolsを作りましょう。もっとも、4-4に準拠していれば、このようなことは起こり得ないはずです。

4. 色

4-1. カラースキームを可視化する/Document Colorsを使う

デザイナーはデザインの作成にあたり、あらかじめカラースキームを定めると思いますが、 カラースキームを何かしらの形で可視化するか、SketchのDocument Colorsを使って管理する ようにしましょう。

カラースキームの可視化はデザイナーとエンジニア双方に良い影響を与えます。デザイナーにとっては使用色数を抑えることに繋がります。エンジニアにとっても、エンジニアは使用する色をコード上の変数で一元管理することが多いため、どの変数を用いれば良いかが分かりやすくなります。

4-1-1. Global ColorsとDocument Colors

Global Colorsは、使用者のMac上で開いたSketchファイルすべてから参照できるカラーパレットです。使用するMacによってパレットは異なり、Sketchファイルにはカラーパレット情報が記録されません。

Document Colorsは、そのSketchファイル内からのみ参照できるカラーパレットです。Sketchファイルに直接カラーパレットの情報が記録されるため、同じファイルを開けば同じカラーパレットを参照できるようになります。Document ColorsはLibraries化したSketchファイルからも参照できます。

ロゴなどのプロダクト全体で使うデザインを集めたSketchファイル上で、Document Colorsを用いてカラースキームを管理し、そのファイルをLibraries化するとグッと扱いやすくなります。

4-1-2. 不透明度のバリエーションがある色は、不透明度100%でDocument Colorsに追加する

不透明度のバリエーションがある色は、不透明度を100%にしてからDocument Colorsに追加 しましょう。

例えば #ff9000 という色に対して、不透明度80%・50%・20%を設定した色を適用させたいとき、Document Colorsに追加される色数は #ff9000 の不透明度100%のみに絞りましょう。エンジニアは不透明度100%の色さえ分かれば、簡単にコードで不透明度を変更できます。またデザイナーが管理すべき色数を増やさないためにも、不透明度100%のものだけをDocument Colorsに追加するべきです。

4-2. レイヤー自体に不透明度を設定しない

できる限りレイヤー自体に不透明度を設定してはいけません 。

実際、レイヤーではなくボーダー色や塗り色に対して不透明度を設定すれば済むケースがほとんどで、上の画像のようにレイヤーにも塗り色にも不透明度が設定されたレイヤーなんて、最も避けておきたい事態です。不透明度の設定数を減らし、また不透明度の設定箇所を統一することは、エンジニアの実装漏れなどを防ぐことにつながります。

上の画像の場合、塗り色に35%の不透明度を持たせることで、不透明度設定が簡潔になりますね。

4-3. レイヤーグループ自体に不透明度を設定しない

できる限りレイヤーグループ自体に不透明度を設定してはいけません 。

こちらも4-2と同様です。エンジニアがレイヤーのスタイルを目視しつつ実装する流れにおいて、レイヤーグループを選択することはあまりありません。レイヤー1つ1つを選択していくため、レイヤーグループに透明度設定が施されていた場合、透明度の実装漏れに繋がる可能性があります。

上の画像では、青色の円形の塗り色に対して50%の不透明度が設定されています。

この2つの円はとあるレイヤーグループに含まれており、このレイヤーグループ自体には50%の不透明度が設定されています。多くのエンジニアは、レイヤーグループに不透明度が設定されているなんて気付かないでしょう。それならばレイヤーグループではなく、円形に25%の不透明度を設定すれば済む話です。

1つのコンポーネントに対して複数の不透明度設定が混在すると、エンジニアは1つ1つのレイヤーやレイヤーグループを細かく見なければいけません。これは非常に効率が悪くなるので避けておきたいところです。

4-4. 灰色を表現するためだけに、不透明度を設定しない

灰色、または白みがかった色を表現するためだけに、不透明度設定をしてはいけません 。

意外とよく見かけるのが、アートボードの背景が白色であることを前提に、灰色を表現するためだけに #000000 に対して不透明度を設定するアンチパターンです。あらゆる背景色に対応するために意図的に不透明度を設定する場合はこの限りではありませんが、灰色として表示したければ不透明度100%のまま、灰色を指定しましょう。

Webページにおいて、影 box-shadow や不透明度 opacity 、角丸 border-radius などは、微量ながらもレンダリングパフォーマンスに影響を与えます。パフォーマンスの悪化に怯えて利用を控えるほどのものではありませんが、パフォーマンスに影響を与えるものを無駄に利用する必要はないでしょう。

5. フォント

5-1. 環境に依存しないフォントを用いる

どのようなフォントでも崩れないスタイルを優先 してください。

Webはデジタル世界で最大のクロスプラットフォームである反面、どのような環境でも崩壊しないレイアウト・デザインを採用しなければいけない難しさがあります。ヒラギノフォントはmacOSのみ、特にHiragino Sansは『OS X El Capitan』以降でのみ採用されているフォントであるため、それを前提にデザインしてしまうと、WindowsやAndroid端末だけでなく旧macOSで閲覧したときに、大きなレイアウト崩壊を招く恐れがあります。

原則として、“明朝体か否か（SerifかSans Serifか）”、“太字か太くないか”のそれぞれ2択から選ぶ粒度にしておく べきです。macOSはデフォルトで様々なフォントがインストールされており、またどれも商用利用可能¹です。しかし他の環境では丸ゴシックが搭載されていなかったり、OSデフォルトフォントのウェイト（太さ）も、2種類しか存在しなかったり。

5-1-1. Webフォントという選択肢

Webフォント TypeSquare [タイプスクウェア] / Webフォント・サービス「FONTPLUS」 | Fontworks

どの環境からでも同じフォントを使用したい場合は、特定のフォントをWebページ自体に埋め込む、通称“Webフォント”という技術を用いることで解決します。Webフォントは、閲覧者の端末に特定のフォントがインストールされている・されていないに関わらず、指定したフォントをページ内で使用できるようになります。

デメリットとしては、ページの表示速度が低下する他、そのフォントがWebフォントに対応しているか、ライセンス的に問題ないかなどの確認作業が必要となる点が挙げられます。特に日本語フォントが有するグリフ（文字）数は相当のもので、1つのフォントだけでも10MBを超えることもザラにあります。

大手フォントメーカーのモリサワやフォントワークスなどではWebフォントサービスを開始しており、ページ内で必要なグリフのみを提供することでフォントの通信量を削減するといった工夫²も施されています。とはいえスマートフォンにとってページ表示速度の低下は、UXの低下だけでなくSEOにも多少なりとも影響を与えるため、本当にWebフォントを導入すべきか、じっくり検討しましょう。

5-1-2. 部分的に画像を用いる

一部の見出しなど、部分的に特定のフォントを用いたい場合は、Webフォントではなく画像を用いた方が総合的なコストを抑えられる場合もあります。画像の場合は、Webフォントで挙げられたデメリットを深く考える必要がなくなりますが、誤字脱字などによるテキスト修正時は都度画像を書き出す必要があります。

5-2. 丸ゴシックを使わない

Webフォントを使わない限り、 丸ゴシックをWebページで用いてはいけません 。

macOSには、欧文和文問わず丸ゴシック体のフォントが標準搭載されていますが、すべてのOSが丸ゴシックを搭載しているとは限らないのが現状です。Webフォントを使用しない限りは、互換性の観点から丸ゴシックを使わないデザインにしなければいけません。

それでも丸ゴシックを採用したい場合は5-1でも述べたとおり、Webフォントか画像を使うと良いでしょう。

5-3. フォントウェイトは、“太い”か“太くない”の2択から選ぶ

フォントウェイトは、“太い”か“太くない”の2択から選ばなければいけません。

Sketchは、そのMacにインストールされたすべてのフォントの、すべてのフォントウェイトから書体を選ぶことができます。フォントがOSに依存してしまうことは周知の事実ですが、特に見落としやすい部分がフォントウェイト（文字の太さ）です。

環境によってフォントウェイトの選択肢は大きく異なるため、細かなウェイトの指定はすべきではありません。事実、 同じmacOS上であっても、Sketchで表示したmacOS標準フォントと、Webブラウザで見たときの標準フォントの太さは全く異なります 。Webブラウザでは、Illustratorのレイヤーをアウトライン化したときのように、フォントサイズが大きくなるほど太さも太くなります。一方Sketchは、どれだけフォントサイズを大きくしても、フォントウェイトはそれなりに保ったままです。

またエンジニアの観点からは、CSSの font-weight プロパティでは bold のようなキーワードの他に、 500 といった数値も利用可能です。しかし上述の理由から、あまり利用すべきではないでしょう。
もっとも、プログレッシブ・エンハンスメントのようなアプローチで「様々なフォントウェイトを持つフォントが搭載されたOSでは font-weight: 500 を適用、そうでない場合は normal 相当でいい」というような設計であれば、 font-weight に対して数値を利用するのも選択肢の1つとしてなり得ます。

最後に

Webフロントエンドエンジニアは、Webフロントエンドを実装する以上、デザインから逃れることはできません。一方Webデザイナーは、Webという世界にデザインを落とし込まなければ完成しない以上、エンジニアと協力しなければいけません。どちらかが傲慢な態度ではチームもプロダクトもうまく回りませんし、お互いの仕事を尊重しつつ、お互いが気持ちよく働ける環境を築くことが重要です。

Webフロントエンドの技術的な要素はもちろん、デザインツールやデザインに対する思想/あり方などは日々変化しています。お互いが利用するツールを熟知する必要はありませんが、必要に応じてお互いが求めるツールを導入するなどして、お互い高め合っていけると良いですね。

おひたしおひたし。