webやアプリのデザインとか、ディレクトリマップ作ってるときに画面名とかIDの付け方って迷いますよね。

画面名とかIDをつけるメリットは、個人的には
・共通言語になる
・デザインを書き出したときにファイル名に秩序が生まれる(連番になる)
・検索しやすい
・同一画面だと認識できる(PCとSP)
とかだと思ってますけど、皆さんどのように命名してますか？

コーポレートサイトとかのデザインだと対して問題にならないんですが、アプリやサービスだと量が多くなったり変更が入ったりしたときに大変なんですよね。

例えば、

・連番で番号つけてたら、あとから画面が追加された。
(画面のフロー的に間に差し込みたいけど連番なので、ケツの番号つけるしかない)
・似てる見た目(実は状態違いの画面)だけど、エンジニアに完全に別画面として実装されてしまった

なんてことも過去にありました。

ググっても最適解が出てこないので、SIerの友人に「画面名ってどうやって付けてんの」と聞いてみたら、番号とか飛び飛びになっちゃっててあんまり秩序はない、という回答も貰いました。(もちろん企業やプロジェクトによって違うと思いますけど)

そういえば、前職(大企業のポータルサイトの保守運用がメイン)のときも画面リストみたいのを見ると、部署ごととかで命名規則はあるっぽいものの、画面フローとか順番まで考慮したIDにはなっていなかったような...。

いろいろ試行錯誤はしてたんですが、最近自分の中でこれならわりとイケるんじゃね？というアートボードの命名規則(というかルール)が出来たのでちょっと紹介してみます。

こんな感じですね。
構成は以下のようになっています。

①セクションID(アルファベット)
②セクション内番号
③画面名(日本語OK)
④状態

ひとつずつ見ていきます。

①セクションID

アプリやサービスの機能ごとにIDをつけています。例えば、

例)
A.ログイン周り
B.サービストップ
C.コンテンツ一覧
D.検索
E.マイページ
F.プロフィール編集
G.利用規約・プラポリ
...

みたいな感じです。そこまで大規模でなかったらアルファベット26文字で足りると思いますが、不安だったら「数字+アルファベット」とかにすればよいですかね。

②セクション内番号

先の例でいうと、A.ログイン周りの中で番号をつけていきます。この時にただ連番にすると、追加されたときにやっぱり困るので、番号でさらにセクション分けを行います。

例) 
A.10-新規登録
A.11-仮登録メール送信完了
A.12-登録完了
A.20-ログイントップ
A.30-パスワードリマインダー
A.31-パスワードリマインダー_メール送信完了
A.32-パスワード再設定
A.90-仮登録メール有効期限切れ

上記の例で言うと
・10番台 => 新規登録
・20番台 => ログイン
・30番台 => パスワードリマインダー
・90番台 => エラー系画面
という風にさらにセクション分けをしているので、新しい画面が来てもそのセクションの番号をつければそこまで崩れない。(例えば、「ログイン時認証画面」みたいなのが追加されたらA.21-ログイン時認証画面とすればよい)

③画面名

ここは普通です。IDだけだとファイルや文字になったときに画面の内容がわかりづらいので、画面名をつけます。先の例でいう「新規登録」「仮登録メール送信完了」とかの部分です。

余談ですが、この画面名の中で「 _ 」(アンダースコア)とかは使ってもよいかなと思います。(使わないときつい気がする)

④状態

これはUIstackの概念をとりいれています。

例えば先の例で言うと、ログイン画面の
・Blank State(未入力状態)
・Error State(エラー状態)
・Ideal State(入力後の状態)
はデザイン上だと違うアートボードになってしまいます。

で、違うデザインだからって違うIDをつけるのは、おかしい気もするし、コミュニケーションも取りにくそうだし、気持ち悪い。精神的にも画面が多く見えて辛くないです？

なので、同じID(①〜③)までは同じものを使って、stateを接尾辞でルールを決めてつける。自分は「#+[state]」ってやってみてます。(アンダースコアは画面名で使うことがあるので避ける)

つまり

例)
A.20-ログイントップ#blank
A.20-ログイントップ#error
A.20-ログイントップ#ideal

とかになります。必ずしも5つのstateに分類できるとは限らないと思うので、日本語の分かりやすいstateでもいいとは思いますが。

ちなみに先ほどの「90番台画面(エラー系画面)」はこの考えを取り入れると、全て該当画面のエラーstateで表現できるかもしれないですね。

まとめ

結論、名前空間を節約しながら階層分けをすればよいということになるんでしょうか。とりあえずこれでページ数や状態の多いサービスとか、アプリの案件が来てもアートボード名に困らなくていいのでは？と思ってます。

もしこれでダメだったらまた考えましょう。きっとアップデートされるのでしょう(遠い目)。