ライティングガイドラインの作り方

SmartHRでUXライターをしている私は、非デザイナーでありながらも、立ちあげ初期からデザインシステムに関わっています。

エージェンシー時代のコンセプトワーク、コピーライティングの経験を生かして、立ち上げ未明のブランドパーソナリティの定義、プロダクトのデザイン原則、今年1月のリニューアル時の運営理念のライティングのアンカーを務めたりもしました。

2022年6月で、SmartHR  Design Systemとしての公開からちょうど2年を迎えます。当時はまさに「有志」が集った雰囲気でしたが、今ではドキュメントを追加する顔ぶれも増え、緩やかに成長を続けています。

今回は、「ガイドラインってどうやって作っていくんだろう？」という人に少しはヒントになるかな…というお話です。

社員にとってのSmartHR Design System

今年の3月に、GMOペパボさんとDMMさん、GMOメディアさんの3社が中心となって活動しているクローズド勉強会「Design Study Morning」の第7回に参加しました。「デザインシステム、現状どうですか？」というテーマで、私は、SmartHR のデザインシステムの成り立ちと有り様を話しました。（スライドで紹介しているSmartHR Design Systemの内容は3月当時のもので、現在と異なる場合があります）

冒頭、私は以下のようなことから話し始めました。

SmartHR Design Systemは、私たちが実践の繰り返しで得たものを指針として言語化した蓄積です。

「デザインシステムの書籍と言えばアレ」の"赤本"でも「パターンとして再利用できるインターフェイス」が、デザインシステムの構成要素として書かれているように、デザインシステムそのものの成り立ちは、すでに業務でやったことを何回も繰り返さないようにする仕組みでした。

私たちは、プロダクト開発に携わるメンバーが増え、開発チームの数も増えていくことを見据えて、自分たちで使うためにSmartHR Design Systemを作りました。

どうやって、誰もが再利用できる状態にするか

ここからが「ガイドラインの作り方」の部分です。（お待たせしました）

鍵となるのは、「”具体”と"抽象"のバランス」。

再現性の高いガイドライン＝具体的なもの

ガイドラインは、自分以外の誰か（もしくは数日後の自分）が、後日似たような状況でアウトプットを作るときに、品質やユーザー体験を損なわない判断ができるように記しておくドキュメントです。誰が読んでも、それを参考に意思決定できるようにする必要があります。「読んでみたけど、よくわからないから、使えない…」と思われてしまったら、ガイドラインは形骸化します。

考え方はどうしても抽象的な表現になりがちです。しかし、この後の説明にもつながるのですが、「抽象」は決して悪いものではありません。

ただ、抽象度が高いガイドラインほど、それを理解し自分の課題に適用するのは難易度も高くなります。そこで、ガイドラインを用意する側は「こういう条件のときには、こうする」といった具体的な決まりを作ります。

ガイドラインの情報設計

ただ、具体的なガイドラインを用意すればするほど、ガイドラインの数も増えていきます。そして、見つけにくくなります。

先日、ライティング部分はセクションを整理し直しました。目的は、開発者がUIテキストの判断に迷ったときに、すぐに探しているものが見つかる（もしくは、まだガイドラインがないことを把握できる）状態にするためでした。

ここでの分類基準は「適用範囲（＝どの業務をするときに使うか）」にしました。理由は、デザインシステムを使う人の目的に合わせた分類が便利だからです。

分類基準には、種類別以外に大きさ別もあります。それが先ほど説明していた「抽象←→具体」の軸です。

実例を挙げると、（コンテンツボリュームが少ないので1ページに収まっていますが）リリースノートの「リリースノートの書き方」と「具体的な書き方のヒント」が抽象と具体です。

情報の粒度を揃えるというとピンと来ない人もいると思いますが、エンジニアだったら、ネストできるかという観点で判断しても良いかもしれません。

•  情報の粒度って？という方はよかったら、こちらの過去のnote をどうぞ

どうしたら、ガイドラインを作れるようになるか？

「ガイドラインを参照して作ることはできるけれど、ガイドラインを作るの難しい…」

これは、抽象化ができないということなのですが、抽象化するには、多くの具体が必要です。

ガイドラインを作る時の抽象化とは、複数の実践から、構造上だったり、コンテキストだったり、さまざまな要素を抽出し、軸になる共通点を見つけだすことです。

この時、実践がどれくらい自分の血肉になっているか、具体的な経験を積んでいるかによって、抽象化のコツを掴めるかが変わってくると思います。（もちろん、個人差はあります）

ネガティブフィードバックの1つとして「話が抽象的」というのがありますが、おそらく、その場合、話が具体的な経験から導き出されたものではなく、借りてきた言葉だったための指摘ではないでしょうか。先ほど、「抽象」は決して悪いものではありませんと書いたのはこのことです。

なので、ガイドラインを作れるようになりたいのなら、まずは頭でっかちにならずに、実践を重ねるのが案外近道だと思います。

SmartHR Design Systemの好きなところ

最後は完全なるデレですが、私がSmartHR Design Systemで一番好きなところは、今説明したような「実践と理論の往復からできている」ことです。

私たち自身が、作る人であり使う人であるという状況によって、今の成り立ちを保てています。

あくまでも、私たちの一番の関心事はユーザーに価値を届けること。その過程で生まれたものの再利用が目的なので、具体と抽象のバランスが取れているんだよなぁと実感しています。

もちろん、この先組織がスケールしていけば、この作り方も変化していくかもしれません。しかし、ものづくりをする一個人としては、常に理論ばかりではなく実践も大切にしていきたいなと思っています。