2018年末に考えるSketchデザインデータ

この記事はDesign Tools Advent Calendar 2018 11日目の記事です。
中盤になってくるとネタ被りに怯えてきますね〜。

前置き

本編の前に、現在の環境について少しだけ前置きを書きたいと思います。
仕事は主にC向けサービスのデザイン（WEB版）をしております。
ツールは普段からSketch+Abstractを使用しており、担当デザイナーは私だけで、他のデザイナーと共同作業することはほぼありません。またHTML+CSS(+見た目に関わるjsなど)は自分で書くことが多いです。
なので、Abstractはバージョン管理＆クラウド＆たまに他の人への共有として利用しています。（インスペクタ機能もアルよ!!使ってない!!）
サービスの規模は中〜大向けの記事になるかと思います。
それでは早速本編に入りたいと思います！

使用アプリケーション

Sketch
Abstract

Sketchのライブラリ機能を使う

ライブラリ機能が実装される前に始まったプロジェクトの場合は特に、ライブラリを使用するかどうかが悩むポイントになるかもしれません。
私の担当サービスでも、ライブラリに移行するかどうかしばらく悩みました。

結局、これからも更新が続く・後からデザイナーが入っても大丈夫な状態にするという理由でライブラリに移行することにしました。
サービスの規模が小さい場合・単発で更新性がない場合はあまり恩恵が受けられず運用が大変になるのであまりおすすめしません。

ライブラリ機能のメリット・デメリット

ライブラリファイルは、ライブラリの修正→デザインファイル側で「Library Updates Available」をクリックのフローを取らなくてはいけないので面倒です。

またSketch Mirrorに繋げた状態で、ライブラリファイル⇄カンプファイルの行き来を頻繁にしているとすぐ固まります。個人的にアートボードの行き来より、ファイルの行き来の方がかなり重く感じます。

しかし複数人でデザインする場合はライブラリ機能を使った方が良いなと思います。
複数人で作業する場合は、どうしても自分と他の人との作業環境には違いが出てきます。
（実際に運用しているわけではないので、運用したことがある人からすると他にもメリデメはあるかと思いますが…）

そんな時UIの統一性を担保するには、Masterとなるコンポーネント群（ライブラリ）を作成し、自分の作業ファイルにリンクさせるのが安心安全です。
また、ライブラリが更新された時のdiffも分かりやすいです。

ライブラリを更新したい場合、作業ブランチを切って、ずっとそこで作業していてはライブラリの意味がなくなってしまうので、細かくコミット→プッシュ→マージをしていくと良いかもしれません。

ライブラリに移行する

1人で管理する場合も、規模が大きいサービスなどではコンポーネントが増えてきたり、後から複数人で管理することになったりするのを見越してライブラリで管理すると良さそうです。

途中で移行するのはなかなか大変で面倒なのですが、
Move to Libraryというプラグインを使えばシンボルを全部ライブラリに移動できます。
また、Symbol Swapperというプラグインでシンボルをライブラリに置き換えることができます。

Move to library
Symbol Swapper

カラーはレイヤースタイル&ライブラリで管理

以前まではカラーもシンボルで管理していましたが、レイヤースタイルでシンボルのオーバーライドができるようになってからはこちらで管理するように変更しました。
カラーのレイヤースタイルもライブラリ側で管理しておくと便利です。

シンボルにも言えますが、カラーもあまり階層を深くしていると使うのが面倒になるので注意。
↓このようにオーバーライドできて便利!

カラーのオーバーライドはマスクでも塗りでも同じような挙動をしますが、マスクにしていると少々書き出し時に面倒だなと思いました。pngの場合問題ないですが、svgで書き出す場合は注意です。

命名規則

より分かりやすいデータを作るために命名規則についても考えます。
細かくルールを決めすぎて命名に悩む時間ができると勿体無いので、ある程度自由度のある命名規則を決めました。

アートボード

{{ ページ名 }} – {{ 画面名・状態名など }} – {{ 画面名・状態名など }} のように階層構造が崩れないように命名していきます。

ex)
Top – Trend
Top – Feed
Top – Feed – Empty

レイヤー

レイヤーは一番上の階層のもの（アートボード直下）は、シンボルの場合を除いて、なるべくわかりやすい名前をつけます。難しくなくて良く、ListとかBlock/element-name程度でも良いというルールにしました。
Groupとかのまま残しておかないのが大事です。

シンボル

シンボルはなんちゃってAtomicDesignです。（Atomsから作っていってないため..）
Lv1(Atoms)~Lv3(Organisms)までにコンポーネントを分けていきます。
これってAtoms？Molecules？みたいな記事はたくさんあるし、正直人やチームのルールによるので割愛します!!
シンボルはLv◯/Element-Name/name(_size_state….)みたいなルールを決めておくと使いやすいです。（スラッシュで区切ると自動で階層化される）
単語を区切る時は-(ハイフン)、nameと状態などを区切る時は_(アンスコ)のようにBEMっぽい感じで命名しています。

ex)
Lv1/Button/normal
Lv1/Button/primary
Lv2/List/article
Lv2/List/article_coming-soon
Lv3/Block/article-list

みんな大好きSymbol Organizerというプラグインで、サンプルデータはこんな感じで並んでます。

プラグイン

環境に依存するプラグインは、自分以外の人が困らないように良く検討してから導入するのが良いと思います。

私がよく使うプラグイン厳選↓↓
Runner
Icon Font
Stark
Symbol Organizer

デザインデータを作るときに気をつけたいところ

Resizingをよしなに使う

シンボルが無駄に増えないのと、複数の画面幅でデザインするときに有用です。
しかし全部に適用するのは時間がかかるので必要になった時だけ適用させるのが良いかと思います。
Resizingを適用するにはアートボードを選択してAdjust content on resizeにチェックを入れておきます。

こんな感じに設定しておくと↓のようになります。（DescriptionTextのとこはHeightを設定しないとこのような挙動にならないのでご注意。）

コントラストチェック

Starkというプラグインで簡単にチェックできます。全部クリアするのはキツいのですが、あまりスコアが低くなることがないように気をつけたいところです。

Starkでは色盲・色弱の方の見え方をシミュレーションすることもできます。

書き出すデータ

svgで書き出すのか？pngで書き出すのか？それ以外なのか？先に考えておくと後から困りません。
svgで書き出したい場合、データに余計なものがなるべく入らないように、シンプルな構造を意識して作っておくと良いです。

それ実装できる？

私はcssの知識しかないのでWEBの話になりますが、
簡単にcssで再現できるのか？めっちゃ頑張れば再現できるけどかなり面倒なのか？再現不可能なのか？というのを考えながら作っています。
デザインの幅が制限されるからあまり気にしなくて良い派の人もいるかと思いますが、それはチームでよしなにやっていただければです。
ちなみに最近自分で作って一番後悔したベストofめんどくさいコンポーネントは

こちらのborder付きの吹き出しです。

いけてるサンプルデータ..

リリースするものが日本語のサイトであるならば、Lorem ipsumやオシャレな外人の画像などを仮データとして置くと、後からなんか違う!となりかねません。
なるべく実際のデータに近いものを使う習慣をつけておくと吉です。
ただこの前のアップデートでSketchが公式にサンプルデータを挿入できる機能を実装してくれたので便利に使えます！

小ネタ

オーバーライドしないレイヤーはロック

ロックしておくとシンボルのオーバーライドの欄に出てこなくなるので、ちょっとスッキリします。

リストのボーダーをシンボル化or透明にする

ボーダーを作る場合、インナーシャドウor1pxの長方形のどちらかになると思います。
基本的には幅いっぱいの時はインナーシャドウで作っておくと良いかと思いますが、リスト系のUIの場合1pxの長方形だと便利なこともあります。
ボーダーをシンボルにしておけば、ボーダーの有無をオーバーライドで切り替えられるので、一番下のリストアイテムにはボーダーいらない場合とかに便利です。
シンボルが増えて嫌な人は、transparentみたいな透明のカラーのレイヤースタイルを用意して、塗りを透明にするやり方もあります。（サンプルファイルではこちらのやり方）