年始なので、題して『自分の苦手分野の遅れを取り戻そう企画』👏👏👏

私は、チームではなく、デザイナー1人でプロダクト作りに携わることが多かったので、運用に関しては手を抜いてしまっていました。

アトラエのデザイナーの三上くんのデザインファイルを見た時に、その綺麗さに焦りを感じ、
「来年からチームでデザインしていくだろうに、このままじゃやばいぞ・・・迷惑かけるぞ・・・」
そう思い、前に読んだデザインシステム関連の記事などを引っ張り出してきて、整理しようと試みたのがこのnoteです。

・（私のように）デザイン運用に手を抜いてしまっている方
・デザインシステム？デザイン運用？よく分からないけど、大枠を掴みたい方
・デザインシステム関連の記事を読み漁りたい方（沢山貼り付けています！）

に読んでいただけると、実りある時間になるんじゃないかなぁと思います（願望🙇‍♂️）

前置き

💡『そもそもデザイン運用とはなんぞや？』
デザイン運用を行う上で学ぶべきものとして
● デザイン運用の概念
　　- デザインシステム、Atomic Designなど
● コンポーネントの命名規則
● ツールごとのデザイン運用  - sketch、Figmaなど
● スタイルガイドの作成
● ファイル管理（バージョン履歴など）
などがあります。耳馴染みのある言葉もあると思います。


💡『デザイン運用に心掛けるとどんなメリットがあるの？』
● 全体的なデザインの統一感や一貫性を担保できる
（同一プラットフォーム内、ないしは別のプラットフォーム同士　- ブラウザ / ios / android）
●（シンボルを作成することによって）あとでデザインを変更する際の工数の削減に繋がる
● エンジニアの開発効率が上がり、コードの統一化を測りやすくなる
などのメリットがあります。


💡『デザイン運用の流れは？』
① 運用ルール決め
② 命名規則を意識してコンポーネントを作成
③ シンボル化して、コンポーネントライブラリにまとめる
（ボタンやフォームなどのUIに使われるパーツをまとめたもの）
④ スタイルガイドの作成
（デザインのルールをまとめたもの）
⑤ バージョン履歴とファイル管理

デザインシステムとは

一貫性をもってプロダクトを作るための様々な要素から構成される仕組み（引用元 eureca engineering）

チームでプロダクトを制作し運用する際に、共通の言語で繋がれるように、再利用できるコンポーネントとガイドラインをまとめたもの
スタイルガイドとコンポーネントライブラリから構成されている
（引用元 UX MILK）

デザイン運用を行うにあたって、『デザインシステム』という仕組み/システムを取り入れます。
そして、デザインシステムを構築する上で代表的な『Atomic Design』という仕組み/システムを導入するといいよ〜！っていう話です。

Atomic Designとは

パーツを合体させて、再利用が可能なエレメントやテンプレートが作成できるシステムを構築すること
すべてのデザインシステムは共存するブロックが連続して構成されるという考えに基づいている（引用元 UX MILK）

💡コンポーネントの分解方法
（UIは複数のコンポーネントを組み合わせて作っていきますよね。
そのコンポーネントを一定の単位で分解して、シンボル化したブロックにしておくと、スムーズな運用ができますよ〜！という分解方法の一例です。）

・原子（Atom）
それ以上の分解が難しい要素
デザインシステムを構成する基本的なブロック
例）ラベルなしの単体のボタン、テキストスタイル、カラー、イメージなど

・分子（Molecules）
Atomを組み合わせることによって構成される要素
例）検索フォームや入力フォーム（ボタン＋テキストフィールド）、ブロック（inputフォーム、）

・有機体（Organisms）
AtomとMoleculesが繋ぎ合わさった複雑な構造のUI
例）ヘッダー（ロゴ＋複数のボタン＋ナブバーなど）、バー

・テンプレート（Templates）
Organismを組み合わせることによって構成されるワイヤーフレーム

・ページ（Pages）
最終的なプロダクトと同等のようなもの

コンポーネントの命名規則

『Symbol Organizer』というシンボルの管理ができるプラグインを導入し、『レベル性』と『半角スラッシュ（ / ）』を用いて命名すると、シンボルを階層ごとに構造化することができます。

コンポーネントの命名例

『 lv3 : bar / nav / serachbox 』
（レベル : コンポーネントの種類 / コンポーネント名....続く）

（参考文献 CrowdWorks DESIGNER BLOG）

💡レベルごとの要素について
Atomic Designのブロック要素と、lv（レベル）を掛け合わせて、コンポーネントに命名していきます。

● Atoms ＝　lv1
・ic - アイコン
・color - カラー（シンボルよりもスタイルガイドに登録する派）
・txt - テキスト（シンボルよりもスタイルガイドに登録する派）
・img - 写真
・border - 境界線
・decoration - 装飾（dot / arrow / line ）

● Molecules = lv2
・list - リスト（ simple / double / multiple ）
・btn - ボタン
・block - ブロック（ label / tag ）

● Organisms ＝ lv3
・block - 複数の要素でできたブロック（ pagenation ）
・bar - ナビゲーションバー、タブバー（ nav / globalNav / localNav / status bar / search）
・form -フォーム（Textinput / Chekbox / Radiobuttons / Dropdowns）
・card - 複数の要素でできたカード
・default（OSなど） - iphoneの標準UI

● Templates ＝　lv4
● Pages ＝　lv5

sketchにおけるデザイン運用

sketchでは、コンポーネントはシンボルを作成し、カラーやテキストスタイルはレイヤースタイルに登録して、デザインを運用していきます。
（シンボルは作成すると自動的に同じページに集めてくれる😊）

💡レイヤースタイルの活用
登録したいテキストやカラーをファイル上に用意
▶︎ 右側の『APPEARANCE』の『No Text Style』をタップ
▶︎『Create new Layer Style』でレイヤースタイルが登録される

※ 登録したレイヤースタイルを変更するには？
スタイル適用状態でスタイルを変更
▶︎『No Text Style』をタップ
▶︎『Update Layer Style』をタップ
同じレイヤースタイル適用中の全てのオブジェクトのスタイルが更新

figmaにおけるデザイン運用

figmaでは、繰り返し使用するパーツはComponent 化して、Master Componentをまとめたページを作成する。（コンポーネントライブラリ）
（シンボルは作成すると自動的に同じページに集めてくれないの😂だから、自分でコンポーネント化したシンボルを同じページに並べておいてね）

そして、Master Componentをコピペする形でパーツを利用していきます。
必要に応じてインスタンスを解除しましょう。

スタイルガイドの作成

スタイルガイドとは、デザイナーやエンジニアが一目で分かるように、デザインに関する共通ルールをまとめたもの

▲SmartHRさんと、CODEALさんのスタイルガイド例参考になります。
ネットに沢山サンプル落ちてるので、参考にしつつカスタマイズして使うと良いかもです。

デザインデータの管理方法 【figma版】

💡『なぜ管理のルールを決める必要があるの？』
チーム内でデザインデータの管理に関するルールを決め、共通認識を持つことによって
・デザイナーが施した微修正をエンジニアが見逃してしまう
・デザインデータの最新版、最終決定版がどれか分からなくなる
・どのファイルを見て実装すればいいか分からない
などの問題が解決することができます。

💡管理の方針
『1つのプロダクトは1つのデザインファイルにまとめて、ページごとに管理していく』

（参考文献：GitHubのようにFigmaを使う【デザインファイルの運用方法】）

① ページ名はデータの状態を提示する

💡 データの分類
① 全ての最新デザインデータ
ページ名称の例）『Master -PC』『Master-SP』など

②デザイナーの作業中のデータ
ページ名称の例）『Branch / login』『作業中 / login』

③デザインが確定し、レビューしたもらう用データ
ページ名称の例）『Review / login』『レビュー中 / login』

④デザインが確定し、エンジニアに実装してもらう用データ
ページ名称の例）『Development / login』『実装中 / login』

⑤リリース済みのデータ
ページ名称の例）『Released / login』『リリース済み / login』

② version historyの保存
Figmaではバージョン履歴を残しておくことができる

💡バージョン履歴の残し方
①『Show Version History』からバージョン履歴を記載
②『Hide Version History』で戻る

💡バージョン履歴を残すタイミング
・デザインレビューをする前
・レビューを終えて修正し、実装に入る前
・リリースした時（リリース時のバージョンとデザインデータのバージョンを合致させる）
など

③ワークフロー

✅デザイン作成→レビューを貰う→実装→リリース
各段階でデザインデータのページ名を変更する
✅実装が完了したデータはMasterページにコピペし、『リリース済み』へとページ名を変更する

その他参考になる記事まとめ

デザイン運用、デザインシステム

Atomic Design

命名規則

デザインシステム導入事例

もっと勉強したい！そんな方への発展的な内容