デザイナーが集まって命名ルールを話し合ってみた

週に1度、クラスメソッドのデザイナーが集まり勉強会をしています。実務に直結しそうなUIデザインに関する暗黙知の共有や意見交換をしてみよう第1弾として、命名に関する共有会を実施したので、ブログにまとめてみました。

コトの経緯

クラスメソッドというとAWSのイメージがありますが、CX事業本部では受託開発をメインで行なっています。また新規事業統括部では自社サービスの開発もしており、実は受託・自社事業どちらにも関わられる環境なのです。

大半のデザイナーはCX事業本部に所属し、プロジェクトごとにアサインされる仕組みをとっており、プロジェクトによって性質が異なるため、標準化的なことが難しいという問題があります。とはいえ、新しく入社するひとがいたり、プロジェクトを引き継いだりすることもあるため、暗黙知になってることをきちんと共有して、活かしてみようという趣旨で始めました。

ひとまず今回に関しては、情報共有して認識を合わせることが目的のため、「クラスメソッドではこうしてます！」みたいなものではない点はご了承ください。

名前の表現

まずは名前の付け方です。

文字種

特殊なケースを除き、半角英数（＆一部の記号）を使うというのは全会一致でした。

書き出しファイル名にはオブジェクト名が使われることになりますが、半角英数字以外だとサーバにアップロードすれば文字化けしたり、プログラムでは未知の不具合に遭遇する可能性があったりします。

リネームの手間や、そのまま間違えてアップロードしてしまうといった事故を防ぐためにも、半角英数字を使うのは基本ですね。

文字区切り

スペース・キャメルケース（スネークケース併用）・スネークケースの3パターンが使われていました。

スペース区切り

アートボードやフレーム、コンポーネントなど、デザイナーがつけた名前がそのまま使われない場合に限っては、ナチュラルなスペース区切りを使います。

当然、書き出しするものは、スペースは好ましくないため、アンダーバーやハイフンに置き換えています。

キャメルケース（スネークケース併用）

キャメルケースは、スペース直後の文字を大文字にする方式です。（細かくういうと、アッパーとローワーがある）

また長い名前すべてをキャメルケースにすると可読性が落ちるため、ステータスや接頭辞・接尾辞の類は、スネークケースを併用します。

スネークケース

スネークケースは、スペースを「_（アンダーバー）」で区切る方式で、キャメルケースとの併用はしません。

スネークケースのみを使用することで、どこまでをキャメルにするかスネークにするかの判断や、他の名前との一貫性を保つといった手間がなくなります。

その他

略語の使用については、略すことで誤って伝わったりそもそもわからなければ意味がないので、名前が長くなっても略さないことが基本という認識で共通していました。（btn といった確実に市民権を得ているものは、例外的に可とする）

命名

アートボードにユニークな識別子

番号やバリエーションなどを表す識別子について、つける場合とつけない場合があります。

プロジェクトの規模が大きい場合は付けることが多い傾向です。 これは規模が大きい＝アートボードが多くなり、同じような名前で識別しづらくなるため、識別子がIDの役割を果たすメリットがあります。

識別子に関しては、数字やアルファベット順など順序のある識別子の他に、ランダムな英数字を使うパターンもありました。

順序がある識別子では、割り込みがあると整合の解決が必要ですが、ランダムな英数字を使うことで、順序の整合性を気にすることなく自由にアートボードを追加できます。具体的にはツールで5桁のランダムな英数字を生成し、接頭辞としてアートボード名に入ます。

つけない場合は、逆にプロジェクトの規模が小さく、アートボードが多くならないため、わざわざ識別子をつけるほどではないという状況でした。

（アートボートの名称を使わないアプリもありますが、キャンバス直下のフレームを表現すものとしてあえてアートボードとしています）

コンポーネント関連

プロジェクトによってプラットフォームが異なるため、大筋でプラットフォームに準拠したカテゴライズや名前をつけるのがベストだよね、という見解になりました。

例えばiOSのナビゲーションバーに相当するコンポーネントは、ウェブではヘッダーと呼ばれることが多いかと思います。プラットフォームに応じた名称を使えば、誤解も生じにくいですし無駄なコミュニケーションコストを払うこともなくなりますね。

実際の機能ではなく見た目ベースにはなりますが、以下のような関係性かと思います。（他あったり認識違うんじゃね？ってのがあったりすれば教えてください）

iOSのSheetsは、ハーフモーダル・セミモーダルでも通じるかも…

またアートボートと異なり、フレームでグループ化したり名前にスラッシュを含めて階層化したりできるため、識別子は基本的につけていません。

その他のアセット

アイコン関連

アイコン名にサイズを入れるかみたいな議論もありました。

スケーラブルなファイル形式を使うことが多く、1つのサイズをプログラム上でリサイズするケースがほとんどのため、あえてサイズは明記しないことがほとんどです。

例外的に、使用サイズに合わせて見た目を調整してい場合は、区別がつかないためサイズの明記が必要という結論に落ち着きました。

色

グレースケールや特別なケースを除き、色そのものの名前は付けず、primaryやsecondaryなど役割ベースで名前をつけることが多いです。

同色のバリエーションは、数字やトーンで表します。色は多すぎても使いきれないし、微妙に間違って指定した結果で異なるコンポーネントが出来上がってしまうため、多くて4つ程度を目安に作成しています。

不透明度がある場合、その不透明度を名前で表現するパターン（例: gray300_30)と、一意な色として定義するパターン（例: disabled）がありました。

またすでにある色でも、特定のコンポーネント（例：区切り線）で使うものであれば、エイリアス的に個別作成することもあります。

タイポグラフィ

こちらも基本的にはプラットフォームやライブラリのお約束に準じ、独自で実装する場合でも規則を拝借することが多いです。

同一カテゴリでサイズが細分化する場合、CSSの xx-large といった「absolute-size」を模したものや、HTMLの要素名を拝借する（見出しであれば h1 / h2...）などを使うパターンがありました。

バリエーションはユースケースによりますが、例えば太字であれば_boldといった接尾辞などをつけるほうが認識はしやすそうという話になりました。

共有会を実施してみて

それぞれがどのような思考で作業しているのかを垣間見ることができて面白かったです。これで「引き継ぎも安心！」というわけにはいきませんが、経緯や意図が汲み取れるようになったのはよかったと思います。

「自分のところはこんなことしてます」みたいなのがあれば、ぜひ教えてください。

参考

ガイドライン

• Apple Human Interface Guidelines
• Material Design 3

コンポーネントライブラリ

• MUI
• chakra UI

命名

• codic
• CSSのクラス名を決めるときに使うリストをつくりました

古い記事・サービスですが、内容自体は古くなるものではないので…