検索結果0件」

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

    2020/07/30
    デザインシステムとガイドライン作りで、心がけた事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つ、

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

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

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


    最後に

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

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

    ではでは、またね〜🤗

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

    広告