リクルートグループNIJIBOXのアートディレクターが語る デザインガイドラインのメリットと導入のポイント

スマホやパソコンが普及し、気になることをインターネットやSNSで調べることが当たり前の時代になりましたが、コロナで外出自粛ムードになったことにより、ユーザーとデジタルとの接点が急増しました。

これをチャンスと捉え、デジタル施策に注力されている企業が多いのではないでしょうか?
デジタル施策を数多く打つ上で、ランディングページや広告・SNS用バナーのデザイン作成が必要不可欠だと思いますが、回数を重ねる毎に都度デザインのテイストが代わりブランディングのための統一感が出しにくい、デザイナーによってクオリティの差があるなど、制作面で課題を抱えているという声もお聞きします。

本セミナーでは、ニジボックスでアートディレクターをなさっている大宮夏織氏をお招きし、大規模サービスにおける基本的方針の整備の取り組みについてお話しいただきます。

ニジボックスはリクルートの新規事業創出プログラムから誕生したWebサイト制作会社で、デザイン思考に基づいたユーザー目線でのデザインプロセスから、Webサイトの制作、運用、改善まで、一貫してサポートしてくださるチーム間の高い制作スタイルが特徴です。
リクルートグループを始めとする大手クライアントとの実績も多数お持ちで、過去の経験やノウハウを交えつつご教示いただきます。


登壇者紹介

大宮 夏織 氏

大宮 夏織 氏
株式会社ニジボックス
クリエイティブ室 マネジャー

2012年に株式会社ニジボックスにデザイナー志望として入社。2017年から、リクルートの大規模サービスの運営組織にジョイン。現在はサービスサイトの運営に携わり、メンバーのマネジメントをしながらアートディレクターとしてサービスの軸を支えています。


 

はじめに

まずは簡単に自己紹介から始めさせていただきます。名前は大宮夏織と申します。

リクルートの子会社である株式会社ニジボックスというところで「クリエイティブ室」というデザイナー組織があるのですが、その中で一部の部署のマネージャーを担当しております。

2012年に当時ソーシャルゲームを開発していたニジボックスにWebデザイナーとして入社しておりまして、その後は自身でゲームを作りたいという思いから、約5年ほどプランニングやディレクションを行っていました。

ニジボックスがソーシャルゲーム事業からWeb制作会社へと事業を切り替えていくタイミングでデザイナーに復帰し、2018年からリクルートに常駐してエンハンス対応を行いながらサービスのガイドラインをゼロから作成・運用し、自社にも展開しております。

今回はこの時に経験したナレッジなどを学んだガイドラインに会する知見を皆さんにお話しさせて頂ければと思います。

 

「デザインガイドライン」とは?

本日いらっしゃる方の中にはデザインガイドラインについて初めて聞いたという方もいらっしゃると思いますので、まずは「デザインガイドラインとは何か?」というところからご説明させていただきます。

デザインガイドラインとは色・文字・レイアウトなど、様々なデザイン要素についてルールを綿密に定義したドキュメントのことを指します。

昨今では様々な世界的大企業のサービスがデザインガイドラインを公開しております。

有名なところで言えば、
・Appleのヒューマンインターフェイスガイドライン
・Googleのマテリアルデザイン

などは皆さんも耳にしたことがあるかと思います。その他にもフランフランやアトラシアンなどもガイドラインを公開しています。

ニジボックスのブログにもデザインガイドラインについてまとめている記事がありますので、今回ちょっと詳細は割愛させていただくのですが、気になった方は「デザインガイドライン」で調べていただけると一番上に記事が出てきますので、ぜひご一読いただければと思います。

 

デザインガイドラインの「3つの役割」とは?

ブログにも記載がある通り、ガイドラインには様々な種類がありまして、使う人や目的によってそれぞれ役割が異なります。

今回はおおまかに3つの種類に分けました。


1つ目は設計に関するガイドラインです。

企業のコーポレートアイデンティティを確立させた上でそのブランドにまつわる思想や設計方針などを記載しているものがメインとなっています。主にブランドガイドラインやデザインコンセプトなどもこちらに該当します。


2つ目は表層に関するガイドラインです。

表層とは簡単にいうと、見た目に関するルールなどが記載されており、スタイルガイドラインやクリエイティブガイドラインなどが該当します。


3つ目は機能についてのガイドラインです。

ユーザーにどのような体験価値を与えるか、操作に対してどのように学習させていくかなどだけではなく、サービスによってはデザインデータのまとめ方や運用ルールなども記載しているところもあり、機能の中にはスタイルガイドラインも含まれます。


今回はこの表層と機能をカバーできるスタイルガイドラインについてのお話をさせていただきます。

 

なぜ「ガイドラインが必要」なのか?

どの役割のガイドラインであっても解決できる課題が大きく分けて3つあります。


1つ目はデザインの品質担保です。

デザインに統一性を持たせることで、プランディングの品質を保つことができます。またルールを定義することにより、コンセプトに忠実なデザインの再現ができます。


2つ目はユーザビリティの担保です。

表現を統一したり、印象を操作することによって、操作に対して学習させることができます。アクションへの心理的ハードルを下げて体験価値を高めるなど、KPIの影響も見られます。


3つ目は制作コストの削減です。

レビューコストの削減や開発との円滑なコミュニケーション、データ不整合による修正工数の削減、デザイン検討の効率化など、ちょっとした手間をこのガイドライン一つで省くことができるようになります。


 

視聴されている方の中にはデザイナーの方もいらっしゃると思いますが、例えばこのような経験に覚えはありませんでしたか?

企画側から「ここを目立たせたいから、文字を大きくして色を赤にして欲しい」という依頼があったとします。こういったデザインの知識があまりない方からの注文に結構多くのデザイナーが悩んでいるかと思います。

・色々言いたいことはあるけど、どう返せば良いか分からない
・そのまま言われた通り作ってしまう

このようなことを防止するためには、ガイドラインがあれば良いと思います。

赤を使用してしまうとユーザーがエラーメッセージと混同して誤った解釈をしてしまうため、ガイドライン上を大きく目立たせる表現はこのようなルールにしています。ですので「この表現でも良いですか?」というやりとりができます。

更にそこから「ガイドラインにも反映させるかどうか判断するために、今後の使用頻度・役割設定などを明確にしておきたいので、どの表現が適切か相談させてください」という感じで相手を否定せずに提案ベースで進められる点があります。

これはガイドラインを基準にやりとりができるということですね。

ただここに書いてあるような言い方をしてしまうとトラブルの種になりますので、言い方はこのようなチクチクした感じではありませんが、企画側もガイドラインを知っていればそれで納得してくれてお互いの及第点を探すことができるようになります。

今デザイナーの方の体験談をお話しさせていただいたんですけれども、この場には企画側や上流工程に関わっている方もいらっしゃると思います。

例えばその方たちがプランニングやディレクターなどを担当していた時に

「デザインを作ってもらったけど、何か違うんだよな」
「どう伝えたら良くなるのか分からないから感覚でフィードバックしてしまう」

という経験はないでしょうか?

これもガイドラインがあることによって、デザイナーが作るものすべてに意味と目的があるということを把握していただければ、それが本当に適切かどうかを感覚ではなくルールを基に議論することができ、それを明確にデザイナーに伝えられれば、認識の齟齬も減り、デザインのレビュー工数も削減することもできます。

その後の流れもスムーズとなり、修正の工数も減らすことができるなど、ガイドラインについては利点が多いかなと思っております。

 

ガイドラインの作成フロー

実際に「ガイドラインを作りたい」となった場合にどういう手順を踏めばいいのかご説明させていただきます。

まずは実際にガイドラインそのものを作り出すというよりかは、ある程度事前準備が必要ですので、ステップを分けて説明します。

まずデザインにおける課題点の抽出をしないと「ガイドラインで何を解決したいのか」が曖昧なまま作ってしまい、結局作って終わりになってしまうことがあるのですね。

ですので、これから作るガイドラインというのは、どんな役割のものなのか、そのためには「現状のデザインにおける課題」を抽出する必要があります。

世の中のデザインについて様々な課題があると思いますが、全てがガイドラインだけで解決するほど、ガイドラインが万能なものではないというところは御承知いただければと思います。

ガイドラインを作る前に「今ある課題がガイドラインを作ることで解決するかどうか」と

いう視点を見失わないようにしましょう。「ガイドラインを作る」というのが目的にならないように、まずは課題点の抽出を行いましょう。

現場でありがちなデザインの課題を羅列してみました。もちろんこれ以外の課題も沢山あると思いますが、代表的なものを並べております。


デザイン工数が膨らむというのは

・タスクの分量が多い
・コミュニケーション齟齬が大量発生して、なかなか先に進まない


品質担保ができないというのは

・デザインに一貫性がない
・目的がブレている
・担保できる人がそもそもいない


効果が出ないというのは

・適切な表現ができてないかもしれない
・ユーザーが学習できていないのかもしれない
・視認性・可読性が悪いのかもしれない


など結構さまざまな課題があると思います。

大抵は今ご説明した3つのガイドラインで課題解決できます。


まずブランドガイドラインで解決できるのは、

・コンセプトがない
・ルールがない
・目的がぶれる


今回お話するスタイルガイドラインで解決できるものも結構数多くあります。

・工数の削減
・品質担保
・効果改善

 

「現場ヒアリング」から課題抽出を行う

ある程度課題の抽出ができたら現場のヒアリングもしていただきたいです。

デザイナー間だけで課題を抽出するのではなく、1つのプロジェクトには色々な職種の方が関わっており、デザインはその中の一部分でしかありません。

逆に言えばデザインに課題がある場合というのは、その前段や後段にも影響しているということです。課題を抽出する際はデザイナーだけではなく企画担当や開発側にもヒアリングしておき共通認識化しておきましょう。そうすると今まで見えていなかった課題や思わぬ解決策が思い浮かぶこともあります。

また、現場のヒアリングは色々な角度から課題抽出を行うというものですが、このデザインの課題をチーム全体の課題として捉えることで、ガイドラインを作ることも費用対効果について説得力が増すんですね。

例えば「ガイドラインを作ったら、フロントエンドのこの部分の工数が削減できますし、プランナーもこういう手間が省けます」とか「デザイナーだけではなくチーム全体の工数が削減できます」となると、結構プロジェクトリーダーなどは「なるほど、長い目で見るとガイドラインを作るのは費用対効果があるかもね」と納得してくれやすくなります。

具体例で言いますと、例えばデザイナー目線とデザイナーが定着しておらず、デザインキメラと呼ばれる色々なデザインが織り交ざった秩序のないページになってしまっている。

統一感がなく適切な表現になっていない。一覧がないので、同じ目的のためにどのデザインが適切なのか調査に時間がかかる、表現方法に悩んで時間がかかる、といった課題があったとします。

一方プランナー目線で言うと、デザイナーにどうフィードバックを伝えればいいか悩んだり認識齟齬が発生してしまい、そのことでプランナーのデザインできる工数がすごくかさんでしまう。結果、スケジュールが押したりプランナーが仕事に注力出来ないといった事態に陥っています。

さらにはフロントエンドに課題を聞いてみたところ、同じようなデザインでも微妙に違うものが多くて、そのソースというのが新しくデザインするごとに作ったりしますので、無駄なコードが増えていくし、管理コストも膨らんで仕様変更や修正が発生した場合にかなり時間がかかってしまうという課題があります。

その場合、先ほどの課題一覧に当てはめてみると、


デザイナー視点だと

・悩む時間が多い
・デザインに一貫性がない
・デザインキメラがいっぱい


プランナー視点は

・コミュニケーション齟齬がある
・仕様変更、修正が多い


フロントエンド視点は

・タスクが多くなってしまう
・コミュニケーションの齟齬がある
・仕様変更や修正が多い


こういったという形で見てみると、ピンクが多いので「これはスタイルガイドラインを作ることで解決できるのではないか」といった課題の抽出の仕方ができるかなと思います。

 

ガイドライン作成の目的を設定する

では課題の抽出ができたらガイドラインを作る目的を設定しましょう。

ヒアリングした課題を基に、世間では物事のタイミングを示す言葉として5W1Hという言葉を使いますが(1Hは省くとして)5Wに当てはめて目的を設定しておくと良いかなと思っております。

「WHO(誰が)」というのは、デザイナーなのか、プランナーなのか、マーケターなのか、それとも開発者なのか。


「WHEN(いつ)」というのは、要件定義のタイミングなのか、IA設計時なのか、デザイン着手前なのか、制作時なのか、納品時なのか。


「WHERE(どこで)」これはツールに関するお話ですね。デザインツールでガイドラインを作るのか、パワーポイントで作るのか、Keynoteで作るのか。最近の先進的なサービスですと、独自サイトでガイドラインを作ってしまうというところもあったりします。


「WHY(何のために)」これはガイドラインで何を解決するのかというところです。パーツリストとしてデザインの一覧を作って悩む時間を減らす、ルールブックとして一貫性を保つための物にするなどです。


「WHAT(どうやって)」は「最終的にはそのためにガイドラインを作る」というところになると思いますが、例えば設定の仕方の例を3つほどを持ってきました。


 

こういったところが王道になってくるかなと思いますが、現場によってはデザインシステムを取り入れているところですと、デザイナーとフロントエンドが誰になって。それをストーリーブック上でデザインシステムを共通認識化して可視化するためにガイドラインを作るというところもあります。

また開発側だけではなく、マーケターがメルマガを作成するときにパワーポイントでデザインを統一・確認するために、デザインガイドラインを作ることもあったりもします。

 

デザインのアーカイブを行う

目的の設定ができたら、例えば大きなサービスですとかなり膨大な量になってしまうので、すごく工数がかかる作業ではあるのですが、デザインのアーカイブというものをやり始めます。

まずはすでに使われているWebサイト上のデザインのパーツをカテゴリーごとに整理してまとめて、もし同じ役割でも異なる表現がある場合は特徴や仕様箇所、使用回数などをそれぞれまとめておきます。

大きいサービスになると派生ページがたくさんあって、全部見るのは非常に大変です。そういった場合は、例えば訪問回数が一番多いページ、コンバージョンに関係するもの、メディアの場合は一覧など、人が一番見ている数ページだけをピックアップしてまとめる場合でも大丈夫です。

まとめていると、デザインの全体像が見えてくるわけですね。そのデザイン自体を把握するということにもつながってきます。

ある程度デザインのパーツがアーカイブできたら「このパーツには何種類デザインがある」とか「こういうときはこういうデザインを作る」という風に分かってくると思います。

それぞれのパーツというのは役割を与えないといけません。

また同じ役割でも複数の表現がある場合、例えば同じコンバージョンボタンでも表現がパラパラ、アイコンの有無、浮いている・浮いていない、角丸・角丸ではないとか、そういう表現のブレがあったりする場合もあると思います。

その時に、どの表現が一番適切かどうかというのを検討し、必要最低限のものだけ残すように判断基準を設定します。

 

ルールの定義

少数のプロジェクトチームであれば、判断基準はデザイナーだけではなくて、可能であれば企画担当や開発とも相談してそれぞれ共通のルールにしておけるといいかなと思います。

デザインに決まった正解はありませんので、それぞれの現場の方針に合わせて自分たちがやりやすいようなの作り方ができればいいかなと思います。

あまりにも多いものはそれに統一してしまうとか、そういった判断基準を設けることで、その後も同じような問題が発生した時にこれに沿って判断できるようになると思います。

 

ドキュメントへの落とし込み

ドキュメントへの落とし込みをここから行っていきますが、落とし込む形というのは、先ほど設定した目的によって違いますが、基本的には誰でも見られる形にするのが望ましいです。

それぞれにデメリットとメリットがあるので現場に合わせていいと思いますが、基本的にガイドラインはアップデートしていくものなんですね。ですので、管理・運用コストを低く抑えられるものが理想かなと思っております。

具体例としては、パワーポイントのようなPDFに落とし込むもののメリットは、誰でも見られますし、共有フォルダやメールなどで気軽に共有できることです。最近のデザインツールはほとんど何でもPDFに書き出せますので、そういうやりやすさもあります。

デメリットは、更新ルールをしっかりしないといけないことです。色々なところに共有しやすいがために、最新版でないものを参照する人が出てくる可能性があります。ですので全員が最新版を常に手元に置いておくためのしっかりとしたルール作りが必要となります。

私がお勧めするのはSketch、XD、Figmaですが、その中でもSketchfigmaが一番お勧めかなと思っております。

ライブラリのデザインデータをガイドラインと兼務で使うことによって、ガイドラインとして作ったそれぞれのコンポーネントを実際のデザインデータ持ってこれたりしますので、効率がすごく良いですね。

アップデートや共有もデザインデータを中で少し変えればすぐ反映されますので、共有しやすいというところがあります。

ただデメリットとしては、そのデザイナー以外が確認するためにツールを使えるようにならないといけないですとか、特にAbstractとかバージョン管理ツールを使ってしまうと他のデザイナー以外の方が見るのが困難になってしまうというデメリットもあります。

ここには書いてありませんが、複数の人が触ることで簡単に書き換えられてしまう場合もありますので、ルールをしっかりしないといけないなと思っています。

 

最後はWebサイトですね。

メリットは見た目がすごくかっこ良いですし、自分たちのサービスのサイトを作っているというのは、ブランド的にも品質が高いイメージがあったりしますね。

サイト上にあるものなので、CSSをそのまま見られたり、コピペできたりすると、デザインにも反映する時がすごく楽だったりましますね。

ただデメリットとしてはデザイナー1人だけでは更新できないということです。コーディングできる人がデザイナーの場合は例外的に問題ありませんが、基本的には気軽に更新が出来ないので、運用・管理コストが高く、属人化・風化しやすい傾向にあります。

形式が決まったら、アーカイブしたカテゴリごとにパーツを並べていきます。それぞれのパーツごとに役割や制約なども記載しておけると良いでしょう。

 

運用について

次にガイドラインの運用についてです。ここが結構大事なポイントかなと思っております。ガイドラインというのは形に落とし込みができてからが本番です。

ルールを定義して、それをデザインに落とし込む際に議論した結果、既存のルールだと不整合が起きてルールを更新しなければいけないということがしばしばあります。

基本的には「ガイドラインを変えない」というのが前提ですが、時代の変化やサービスの方針変更などの理由でデザインが変わることがあります。

・リニューアルしなければいけない
・新しいルールができた
・開発都合によってデザインを改変しなければいけない

ということが結構ありますので、ガイドラインは都度更新していくことが前提となります。

落とし込む形というのも、

・運用しやすい
・コストがかからない
・気軽にできる

といった要素があるものが理想だと思っております。

ですので「作って終わり」とならないように、運用ルールをあらかじめイメージしておけると良いでしょう。


■ ルール改定のフローは?

ルールを簡単に変えてしまっては意味がないので、

例えば

「このガイドラインから外れたデザインを作ります」
「それをガイドラインに反映させます」
「それは誰が判断しますか?」
「承認フローはどうしますか?」

というところですとか、

またはアートディレクターの方がいれば、その方に「ここを変えようと思います、どうでしょうか?」という提案をしてアートディレクターの方がOKを出した場合は改変を認めるですとか、そういった方がいない場合はみんなで話し合って多数決で決めるなど改定のフローを決める必要があります。


■ 範囲はどこからどこまで?

ガイドラインに載せるパーツ・ルール・定義は、どこからどこまでを載せるのか決めておきます。大きいサービスの場合、パーツやパターンがたくさんあったりするわけですね。

例えば

・ABテストを行った結果はどう反映させるのか
・今回新しく作ったもの(ガイドライン未掲載)についてどう判断するか

といったように何を載せて何を載せないかを決めておく必要があるわけです。


■ どうやって共有する?

ガイドラインはみんなに見えないといけないものですので、DropboxやGoogleドライブなどに入れてみんなが見られる状態にするのが良いでしょう。

「バージョン管理はどうするのか」という話ですが、基本的にはガイドラインを更新する前提が良いと思うので、バージョン管理は必ず行ったほうが良いと思っています。

例えばSketchで作った場合はAbstractというバージョン管理ツールがあります。Dropboxも確かバージョン管理ができたような気がしますが、そういったところを視野に入れて、どこに共有するのか考えておくと良いかなと思います。


■ 更新のタイミングはいつ?

例えば、そのルールが変わったらその都度更新する。もしくは3ヶ月・半年に1回ガイドラインを見直して、決まった頻度で更新するか決めるなどですね。


■ 誰が更新するの?

更新担当者がバラバラだと色々な部分でブレが生じてきますので、できれば担当者を一人設定しておきたいところです。

ガイドライン専任でなくても良いですが、ガイドライン・ルールに詳しい人や、なるべくUI経験が豊富な方にお願いできると理想的です。

もしくはサービスの全体を把握することができるため、新人に任せても良いかなと思いますが、この方が一貫して作ることになるため、かなり工数自体はかかってくるとは思います。

このように全体の運用ルールとガイドラインの責任者は誰かという部分を決めていけると良いかなと思っております。

 

今日覚えて欲しいこと

今日覚えて欲しいこととしてはガイドラインは法律ではないということです。

「作ったガイドラインは絶対に守れ! 守れないものは許さん!」ということではなく、必要に応じてガイドラインについて議論できる環境が大切です。

例えばプランナーの方から「ちょっとガイドラインとは違う表現になるけど、こういう風にやりたいです」と言われた時に「ガイドラインにないからダメです」とキッパリ断ってしまう。これではデザイナーとして価値を見出せなくなります。

こういったケースを避けるために、なるべくガイドラインというのはフレキシブルに柔軟に対応できるようにしておくのが望ましいです。あくまで内容について議論するためのルールを作っておくことを念頭に入れておいて欲しいです。

先ほども説明しましたが、ガイドラインというのは運用が前提になってくるものですので、「作って終わり」とならないような作り方をしていただきたいです。その後の運用をいかにしていくかが本質になってきます

どこのサービスでもガイドラインを作ったまま全然更新されず、そのまま風化してしまうケースが散見されますので、ぜひ定期的に更新していく仕組みを作っていただければと思っております。

ガイドラインというのはデザイナーだけのものではなくて、このデザインルールをチーム全体に提示しておくだけで「デザイナーさんってこういうことを考えながらデザインしてるんだ」ということが周知できるようになるので、デザイナーがその後動きやすくなります。

またフロントエンドとの接続もしやすくなります。例えばデザイナーが作ったものをフロントエンドが全然違う形で実装してしまった時やデザイナーが作っていないパターンをフロントエンドが作らないといけない時に、デザインのルール・概念・方針をフロントエンドに共有できていると物事がスムーズに進みますし、最終的なクオリティの向上にも繋がります。

最後は「見た目優先ではなく数字にちゃんとコミットできるルール」を作っていただければなと思っております。

もちろんデザイナーですので見た目も大事ですけれども、その数字を見て見ぬふりしてしまうデザインというのは結果、デザインの価値を下げてしまうことになります。

「結果的にABテストで負けてしまったものの、見た目はこっちの方が良いから、こっちのデザインを残したい」というようなことはなるべく避けて行ったり、デザイン的にも数字を最優先というわけには行かないとは思いますけれども、ある程度のこだわりを持っておくべきです。そのために妥協点を探るためのルールがあれば良いと思います。

本日は以上となります。

 

Q&A

Q1.ABテストを行っていくうちに「トンマナ」から外れた方が悪目立ちする結果になることが多くありますが、その時数値以外の全体の統一性、学習しやすさの必要性をどう説得するか、何か工夫されていることやアドバイスがあればお願いいたします。

大宮

そうですね、これについては本当にデザインは数値だけでは測れないし、数値が「正」とも言いづらいというところで、かなり難しい問題ではあったりしますが、実際にどんなに見た目がよく作っても、ABテストではデザインを変えないほうが勝ってしまったというケースもありました。

ただ私たちがやっている方針や私が思っているところとしましては、

デザイン変更については工数をかけて行っているので、それが負けたからといってすぐに「元に戻そう」という風にはならず「なぜ負けたのか」という原因を突き詰めるようにしていました。

例えば

「ファーストビューからはみ出てしまったからではないか」
「もっとここを良くしたら逆に数値が上がるのではないか」

というリベンジの方針に向きを変えていくというところが多いかなと思いますね。

もちろん数字を無視することはできませんが、デザインを変えたことにもちゃんと理由があります。ですのでその理由を帳消しにするのではなく、逆にしっかりと向き合って、違ったアプローチからデザインを改変していく方向性について考えていくのが良いかなと思っております。

工夫していることといえば、基本的にデータの取得などはデザイナーではないプランナーの方がやってくださっているので、私はそのプランナーの方の提案や実際の数字を基にした提案というのは私からはできませんので、あるとすればやはりデザイン観点から「どこの軸で数字が上がったのか」を判断する。また、どこの軸でデザインが上がったか下がったかというのを判断してそれを仮説として羅列していき、それを提案していくところかなと思います。

Q2.デザインガイドラインが浸透していない社内において、浸透させるためのポイント・テクニックとなることはありますでしょうか?

大宮

私が過去にデザイナーとして常駐したところでは全然浸透しておらず「ガイドラインなんて作る意味あるの?」といったスタンスの現場でした。

そういった場合にチーム全体から観た課題として取り上げることで「ガイドラインを作ることで私たちの工数も削減できるなら…」という風に納得してもらい、作成をしていく方向に持っていきました。

そうして最終的にガイドラインを作ったときに、デザイナー側が考えているルールや思考などについてフロントエンドさんやプランナーさんにも理解してもらい、うまく浸透させることができました。

ですので、周りの意識を変えるためにも

「なぜこれが必要なのか」
「なぜこうしているのか」

という風にデザイナーが自分の作ったデザインの意図や目的についてしっかりと発信していくことというのが大事かなと思います。

世の中にはあまり「見た目」に重きをおいてない方もいらっしゃいます。

そういった人に対して「見た目の良し悪し」がどうこうと説明をしても理解してもらうことは難しいですので「見た目を良くすることで何が良くなるのか」ということを中心に伝えます。

その人の視点に立って「デザインを良くすることは、あなた自身が抱えている問題だけではなく、全体としての困りごとも一緒に解決できますよ」という風に伝えます。

このように相手の目線に立つことが一番かなと思っております。

Q3.一度定めたガイドラインがあるのですが、徐々に社内の要求が変わってきて、過去の考え方が古くなっている場合があります。その場合はページの要素を見直したりするのですが、そのせいで新旧のページで違いが出てしまう弊害があります。その場合は過去に作ったページを含めて改めて見直したりするのでしょうか?

大宮

そうですね、私も既存サイトのリニューアルを行ったことがありました。そうするとガイドラインも新しくする必要があるわけですが、その際に「古いものと新しいものを混ぜると大変なことになる」ということが分かりました。

というのもやはり管理コストがすごくかかるわけです。

「これって古いんだっけ?新しいんだっけ?」
「そもそも何で新しいものを作ろうとしたんだっけ?」

というように色々とごちゃ混ぜになってしまい、それが溜まりに溜まっていき、気が付くともう訳が分からない状態になっていたりするわけです。

なのでできれば、新しいものは新しいものとして全部作った方がいいかなと思っています。一方で過去のものは過去のものでそのまま取っておいた方がいいかなと思います。

デザインは部分的ではなく全体を見てルールなどを決めていくものですので、新しいものを過去に適応させても、理屈が通じないことがあるんですね。

そうなると不整合なルールのものが過去のものに混ざってしまうので、過去のものは過去のもの。新しいものは新しいものとして、別々で切り離して、古いものはどんどん新しい方にリファクターしていく、広げていく方が良いと思っております。

要するに「そのデザインに合ったルール」が作れればいいかなと思っています。工数もかかるので簡単にできるものではないですが、ルールを古い方に適用していくよりも古い方も全部新しくしてしまう方針で、進めていった方が良いかなと思います。

Q4.管理ツールのお話をされていたと思うのですが、新旧のガイドラインが混ざったまま運用されてしまっているような場合、どのようにして統一を進めれば良いですか?

大宮

ガイドラインは別に1つじゃなくても良いなと思っています。例えばPDFはその目的を設定して、同じサービスを複数のデザイン会社が担当しているとき、他の会社にガイドラインを提供するときに使えるなという感じで、その目的に合った内容にだけしておく。

Sketchは実際に作業者が使うので、作業者にだけ特化して、説明などは省いてそのままコンテンツだけ置いておく。

またストーリーブックはフロントエンドとデザイナーが主に認識を共通化するものとしておき、例えば週1ペースで定期的にメンテナンスをして使っていく。

このように見る人や使う人を分けて作っておくと良いと思っております。

Q5.社内でのガイドラインの共有場所・方法でおすすめはありますか。

大宮

そうですね、社内のガイドラインの共有方法は最近ではFigmaです。それだけでバージョン管理もできますし、コンポネートとしても使えますし、PDFにもページをデザインで作っておけば書き出せます。

ですので「Figma1本で全部できちゃうんではないか説」はあります。

私はFigmaの料金形態を把握していませんが、課金していなくてアカウントさえ持っていれば閲覧だけはできたと思いますので、もしくは私がやっているのはSketchでライブラリーデータにそのままデザインデータとして使えるようなもの、ガイドラインのページデザインを作って、PDFにも書き出せますし、デザインデータとしても使えますし、あとはAbstractというツールでバージョン管理も出来るといったやり方ですね。

基本的にデザインツールでガイドラインを作るのがオススメです。

Q6.オープンになっているもので、オススメのデザインガイドがあれば参考までに教えてください。

大宮

私もガイドラインをたくさん見て漁っているというわけではないので、結構知見の幅が狭かったりするのですけど、やはりGoogleのマテリアルデザインは見ていて楽しいですし、その理屈が通っているんですね。

アップルのヒューマンインターフェイスガイドラインというのは、これはこう作るべきであるといった感じですけど、マテリアルデザインは「概念」なんですね。

「実際のものに合わせたらこういう表現になりますよね、それに合わせていきましょうね」という風に「必ずしもこういうことではないけど、こういう考え方で作ってね」といったところの本筋がすごい通っていてよく作られてるなというのが見ていて楽しいですし、勉強にもなります。

ご質問等がございましたら、お手数ですが下記運営事務局までご連絡のほどよろしくお願いいたします。
メールアドレス:m_mc_pgtbs_mkg@members.co.jp