デザインシステムとガイドライン作りで、心がけた事5つ【既存のガイドラインに足りないものを補完】

こんにちは、シンヤです！

前回デザインガイドラインを作った記事を作りましたが、今回はガイドラインを作るにあたり、心がけたことを5つご紹介したいと思います😊
実際のガイドラインはこちらから見ることができます。

デザインガイドラインを見る

既存のガイドラインに足りないもの

タイトルにもありますが、心がけたことは、
→ 既存のガイドラインに足りないものを補完する
になります。

参考にしたガイドラインは、CodealのデザインガイドラインとSketchの使い方です。
足りないものは、主に以下の5つだと思いました。

1. 表現が抽象的すぎる
2. 運用・更新ルールが言語化されていない
3. ツールの使い方の言語化が、経験者目線で分かりにくい
4. メールや通知のガイドラインがない
5. 外部ベンダーにも分かるように言語化できていない

です。
以下に詳しく解説いたします。

1. 表現が抽象的すぎる

例えばCodealのガイドラインの場合、冒頭にまず以下のように書いています。

Clean
→ 対等な取引ができる副業プラットフォームづくりを目指すサービスとして、誠実さや信頼性をデザインを通じて担保する。

Personal
→ 多様な情報をパーソナライズする。

Efficiency
→ 効率的なワークフローを実現するために、快適なアクセシビリティを提供する。

僕はこれを見た時、一見良さそうに見えましたが、

なんでタイトルが英語なの？
日本人向けなんだから漢字の方がわかりやすい

定義がフワフワしていて、具体的に何をしたらいいかがわからない

横文字が多すぎ
「多様な情報をパーソナライズする」って何？

と思いました。
つまり、一見定義づけができていそうですが、具体性が分からず「結局このガイドラインは何を言いたいのか」がわからなかったのです。
デザインガイドラインとは、

→ プロダクトを全く知らない人が、見ただけで全体感を把握できるようにする

上記が必須だと思っております。
表現が抽象的で具体性がない言語化では、意味がないのです。
そこで私は、下記のような言語化を行いました。

一貫性
画面毎にデザインが異なることがないよう、一貫性が保たれるガイドラインを担保する😀

柔軟性
⚙️デザインシステムは現時点（2020/7末）のものであり~~~柔軟性の高い使い方ができるガイドラインを担保する😀

俯瞰性
新しいデザイナーが入社したり、外部のベンダーと協力する事もありえる~~~を徹底して行う😀

具体的に言うと、

- 抽象的な横文字を使わない
- 「なぜやるのか？」を言語化する
- 具体的に何をするべきなのかを、徹底的に言語化する

を心がけました😊

2. 運用・更新ルールが言語化されていない

プロダクトというのは「生き物」のようなもので、要件ややるべき仕事が流動的に変わり続けます。
つまり、「変化し続ける」のです。
なので、ガイドラインを作ったとしても、必ず「更新作業」が発生します。

既存のガイドラインは、「変更を前提に運用し続ける」構成にはなっていない気がしました。
なぜなら、運用ルールが言語化されていないからです。
運用ルールが言語化されていないなら、それはガイドラインではなく、

→ 現在の画面のパーツを寄せ集めただけの、ただの画面一覧集

だと僕は思います。
ガイドラインはプロダクトの状況に合わせて、柔軟性を高くして変化し続けることが求められます。
今のプロダクトのパーツだけかき集めても意味がなく、運用ルールを言語化しないとそもそも「ガイドラインではない」と僕は思います😅

3. ツールの使い方の言語化が、経験者目線で分かりにくい

CodealのSketchの使い方のガイドラインを見てみると、経験者目線で言語化されており、初学者の方々にはわかりにくいと感じました。
例えば、

Symbolを共有する
Zeplin上で確認
Libraries連携

私はSketchを使ったことがなく、ずっとFigmaで作業しているので、これを見た時、

- 「Symbol」って何？
- 「Zeplin」って何ができるの？
- 「Libraries連携」って何？

と思いました。
経験者は「みんな知っているだろう」と言語化を省くのですが、未経験者には機能の名前や使い方自体が、そもそもわからないのです。

新しく入社するデザイナーや、外部ベンダーの方々が、必ずしもSketchやFigmaが使えるとは限りません。
職種やバックグランドも違うし、経験や知識も違うことがほとんどです。
そうであるなら、未経験者にもわかるような使い方に言語化できていないと、そもそもツールの使い方として完璧に昇華された言語化ができていないのです。

なので私は、Figmaに慣れていない、もしくは全く使ったことがないデザイナーがいることも考えて、

- 最低限覚えて欲しいFigmaの使い方を言語化
- デザインシステムの有効化方法を言語化
- 各機能のFigmaの説明文には、必ず公式のガイドラインのリンクを追加
- Figmaの命名規則を行った結果の画面のスクショを貼る

を徹底して行いました😊

4. メールや通知のガイドラインがない

意外と多いのがこれ。
大抵のデザインガイドラインは、メールはPush通知のガイドラインが言語化できていないように思います。

本来なら「体験設計」という意味で、上記2つは非常に重要な要素です。
なぜなら、「ユーザーの直接の接点となることが多いから」です。

私が担当したサービスは、
→ LINEのFlexメッセージをPush通知の代わりに使う
という少し変わったサービスだったので、

- LINEのFlexメッセージとは
- Flexメッセージのデザインルール
- システムの実現要件

を徹底して行いました😀

5. 外部ベンダーにも分かるように言語化できていない

外部ベンダーの方々と協力する際に、「これ見たら全部わかるよ！」というガイドラインにするのが理想です。
なぜなら、

- マネジメントコストの大幅削減
- 学習コストの大幅削減
- ガイドラインだけで業務引き継ぎが完結すれば、自分の時間が増える

などのような、大きなメリットがあります。
ですが、Codealのデザインガイドラインを見たときに、
→ 誰かがガイドラインの内容を補完しないと、完全には理解できなかも
と思いました。
なぜなら、前述の4つ、

1. 表現が抽象的すぎる
2. 運用・更新ルールが言語化されていない
3. ツールの使い方の言語化が、経験者目線で分かりにくい
4. メールや通知のガイドラインがない

の課題感がまだ残っているガイドラインだからです。
裏を返せば上記4つの課題さえクリアできたら、このガイドラインは外部ベンダーの方々に向けても、使えるガイドラインになるということです。

私は上記4つを徹底して行い、外部のベンダーの方々にもわかりやすいガイドラインを作るよう、心がけました😊
結構詳しく言語化できているはずです。

最後に

私は例え「ジョナサン・アイブ」の様な超有名デザイナーが作ったものでも、盲信して「これをそのまま参考にしよう」ということは絶対にしません。
それはただの「思考停止」なので😅

今回取り組んだデザインガイドラインの言語化プロジェクトも、Codealのガイドラインを作ったのが例えBasecampの坪田さんでも、足りないものを補完しより良いものを作るよう心がけました😊

ではでは、またね〜🤗