新しくサービスを立ち上げるときにデザインリソースをどのように管理するのかは、デザイナーにとってとても大事な問題です。
いくらデザイン段階で良いものができても、コンテンツを適切に管理できなければ品質が落ち、信頼感のあるアウトプットが難しくなるからです。
今回はAtomic Designの概念を活用して作ったName Generator「 Naming Tracker」を利用して、Sketchのシンボルのネーミングと管理作業を効率良く適切に行う方法についてお伝えしようと思います。
例えば、途中で何度もリニューアルがあったり、複数のデザイナーが参加している大規模プロジェクトだったりすると、デザインリソース（今回の場合はSketchのシンボルやスタイルなどの要素）の命名規則がぐちゃぐちゃになり管理が難しい状況になることはしばしばあります。
そのような課題を解決するために今回私たちが作ったのが、Name Generator「Naming Tracker 」です。
【課題】
① 作業者によってデザインリソースのネーミングの仕方がバラバラ
② ネーミングに悩む時間がもったいない
③ プロダクトごとに独自ルールがあり、横断的な業務がしにくい
Naming Trackerを使って命名規則を決めておくことで
① Sketchファイルの効果的な管理が可能になり（あるべきものがあるべき場所に置かれ、必要な時に使いやすい！）、
② デザイナー同士のコミュニケーションが円滑になり（「これなんだっけ？」「あれどこいった？」がなくなる！）、
③ 作業スピードが早くなり（そもそもネーミングに悩む時間がなくなる！）、
結果として生産性向上に貢献できます。
「Naming Tracker 」は、デザインリソースの命名規則を守るためのName Generatorであり、このName Generatorを投入することで複数のデザイナーが作業する時に起きる問題を解決し、デザインリソースをより効果的に管理することができます。
※Prefix(接頭辞)＝「pre」や「re」「anti」など、意味を持った言葉で、単語の頭につけて、元の言葉に意味を付加するものです。
必ずしもそうである必要はありませんが、ルールを決めるのは運用管理しやすくするための一つのやり方です。
例 btn, bt (×) → Button(○)、ico, ic (×) → Icon(○)
※短縮語の使用は禁止します。
機能ではなく「形」に合わせて名付けた方が良いでしょう。
例えば、「<」の場合、機能的には「 History Back / Undo」を意味しますが、シンボル名は「Icon / Arrow / Left 」のように形に合わせて直観的な名前をつけます。
同じ形の「<」が他のページでは別の機能として再活用される場合もあるからです。
一貫性を持った命名規則があれば、システムが大きくなったとしてもシンボルの属性や、それがどこで使われているのかがわかりやすくなります。
明確な命名規則1つでデザイナー全員が作業の目標を素早く把握できるように導くこともできます。 そしてデザイナー間、チーム間のコミュニケーションを円滑にしてくれるでしょう。
決められた命名規則は、新しくジョインしたデザイナーであってもすぐに理解できなければなりません。
当然のことですが、決まりもなく、複雑で、難解な専門用語を適用したシンボル名はコミュニケーションに混乱をもたらします。可能な限り各プロジェクトでよく使う名称で名付けた方が良いでしょう。
※一度命名すると修正が煩雑なため、仮の名前は付けないようにご注意を。
これからNaming Trackerで使う命名規則を簡単に説明します。
関連性があるディレクトリ別にグループピングするのが最も効果的です。
大文字のI(i)と小文字のl(L)のように間違えやすい文字があるので、頭文字は大文字を使用します。
また、可能であれば1つの単語で表記するのが一番良いですが、2つ以上の単語を使う場合、間に半額スペースを入れます。
例 Naming Tracker
リストが見づらくなる原因となるため、各単語の間に 「 - 」「 _ 」は入れないようにしますが、リストの一番上に出したい場合は「_」を名前の前に付けます。
※ GuideやSpacing (Margin, Gutter, Column)など、サイト全体で使われる共通要素はリストの一番上に出した方が使いやすいでしょう。 ちなみに、世の中でよく使われている略語の場合は全てを大文字で表記します。
例 Social Network Service → SNS
※ Sketch60からComponentsでグループ分けをすると自動的に「/」が入るようになりました。
例）個社ロゴを含コンバージョンボタンの中で、一番大きいサイズのシンボル名
Button / Conversion / Brand Include / xLarge
このリソースは何？
という質問に対しての答えだと思えば分かりやすいと思います。
アイコンは Icon、ボタンは Button など、Asset Typeで分けます。
このリソースはどこにあるのか？を意味します。
複数の画面で使われるアイコンは、下位クラスに属するLocationに該当するネームスペースを追加します。
例えば、ランキンで使われるアイコンの場合は「Icon / Ranking」、メニューで使われるアイコンの場合は「Icon / Menu」で区分できます。
リソースの固有名です。 該当のリソースを最もよく説明できる「固有名詞」 (or Metaphor)で名付けます。
代表的な名詞がなければ、具体的で特徴的な描写、またはメタファーとして名付けします。
例えば、決済手段で使われるPaypalアイコンの場合は「Icon / Payments / Paypal」と表記します。①+②+③の組み合わせでシンボル名を付けたが、同じシンボル名を持つ複数のシンボルが存在する場合、付加的に(Qualifier)を追加する要素です。
可能な限り順番を守ってネーミングをした方が良いです。
この命名規則を守ることで、重複せずに各デザインリソースの特徴を表す名前を作ることができます。
※Google Spreadsheetで管理します。
※実際使われているSketchのSymbolsリソース
命名規則を守ることでデザインリソースを綺麗に管理できます。
どこで使うリソースなのかが一目で分かるでしょう。
最初は整理する時間が少しかかると思いますが、実際に使ってみるとどれだけ便利なのか実感できます。
アウルのデザイナーたちは、デザインリソースを効果的に管理するため Atomic Design Systemを適用して作業しています。
Naming Trackerは、『個人のルール』で決めていたものを『チームのルール』として明確化してくれました。デザイナー間で同じルールで作業をすることは、特に大きなプロジェクトではとても有効だと思います。これを導入することで、料理で例えると仕込みの時間が簡略化され工程がスムーズに終わり、よりクリエイティブな作業に時間を費やすことができると思います。
ネーミングは個人で作業してしまうと直感的で一貫性のないものになりがちです。
ルール決めや、それを既存の（無秩序なネーミングの）ファイルに適用させていく作業はなかなかの気力と労力が必要だと感じてしまうでしょうが、チームで働くデザイナーは必ず超えなければいけない壁だと思います。
そして、大事なのはそのルールをみんなが継続して守り続けることです。
部屋と同じで、気を抜くとすぐに散らかってしまうので、整理整頓を心がけましょう。
それから、Atomic Designの概念を取り入れたルールを作ることで、デザイナー間だけではなくエンジニアとのコミュニケーションも円滑になるはずですよ！
