デザインガイドラインをチラ見!Nextstage Nite vol.2のまとめ

先日、デザイン系のイベントであるNextstage Nite vol.2に参加してきました。
イベントでは各社のデザインガイドラインの紹介や共有があり、自社にいるだけでは得ることのできない知見がありました。文字情報だけではありますが、せっかくなのでダイジェスト的に紹介して見たいと思います。

Nextstage Niteとは?

Nextstage Nite vol.2 実践されるデザインガイドライン
株式会社ベーシックが主催するデザイン系のイベントで、同社のオフィスにあるイベントエリアみたいなところで開催されました。
デザイナーがキャリアとして次のステージに進むために必要な勉強を自発的にやっていこうという趣旨のイベントです。

今回のイベントは、冒頭でも述べた通り登壇者の会社で利用されているデザインガイドラインの発表や共有などが行われました。ガイドラインのあり方は各社とも特徴がありましたが、自社の抱える”負”を解決するために定義されていたのが印象的でした。

簡単ではありますが、発表の内容をまとめておいたので以下からご確認ください!

各社のガイドライン

basic

1番手は主宰のベーシックさんから。Marketer’s STOREの事例を紹介していました。
コンポーネントを網羅的に確認できない状態だったという負を告げた後(Web系サービスあるあるですね…汗)に、解消するためのガイドラインを設定したようです。

ガイドラインは、Web上にデザインのコンポーネントが羅列される方式を採用していて、「継続して使える、わかりやすい、変化に強い」の3点を意識して作成したとのこと。かなり特殊なガイドラインの管理方法をしていて、本サイトで使用しているCSSをガイドラインでも読みに行くらしいです。個人的にはこれが結構衝撃的で、2重運用を避けられるしCSSが共通ならほぼ確実にデザインが一意になるのでおもしろいな〜と思いました。

GREE

2番手はGREE。オンラインゲーム…ではなくWebメディアであるLIMIAの事例を紹介してくれました。
「闇のデザインガイドライン」みたいな引きのあるタイトルでの発表で、どんな闇かというと同じ要素でも細かな差異のあるコンポーネントが乱立している状態だったと言っていました。その分コーディング上の資材が分散して、運用や改修コストが増大していたようです。これも、あるあるですね〜…

上記に至った原因としては、複数人での作業時に指針がなかったことや、相互チェックをする期間がなかったことが原因だったと伝えていました。プロジェクトのフローがしっかりしていないと、どんな会社でも起こりえる状況なので気をつけていきたいですね。

どんなデザインガイドラインを作ったかというと、Interface Inventoryという手法を使って、各コンポーネントを整理したようです。僕はInterface Inventoryと言う手法は知らなかったのですが、デザインをパーツごとに全てのパターン書き出して整理、分類するという手法のようです。うまく管理できれば効果絶大だけど、導入コストもそもそも絶大という結構大きな話でした。

デザインも時間をとってリファクタリングする必要があると言うことをおっしゃっていたのが、印象的でした。そうだよなぁ…。

WANTEDLY

3番手、WANTEDLYがブランドガイドラインの事例を紹介してくれました。今までは各サービスのUIやコンポーネントに的を絞った話ですが、少し風呂敷を広げた感じですね。

WANTEDLYブランドを冠するサービスが直近3年間の間に増えてきたので、統一感あるデザインを進めるための指針が必要になったと語ったと言ってました。名称はWONTEDLY BRAND STANDARD。GUIDELINEという名称はやらされ感が強いため、みんなが気持ち良く遵守するための名称が良いのではないか?と言っていたのが印象的でした。ガイドラインそのもののあり方もデザインする心構えがすごいです。

ブランドのガイドラインということで、代理店にも展開する資料になり得るようA4の紙ベースで作成したとのこと。代理店は紙の資料をかなり使うので(僕が付き合いのあるところもそうでした)そういった人たちにちゃんと見てもらえる形式にしたかったと言っていました。

内容としては基本的にブランドがデザイン上守るルールを記載しているだけなのですが、フォントのフォールバックなど、細かな点も規定を作ってあるのがGoodでした。
必要なものを作り、いいものを貯める。サービスを運営しながら、自動的にこれらが行われる仕組みを作るのが良いということで運用コストをいかに感じずに日々の作業に溶け込ませるか?みたいな視点でも考えているようでした。

CrowdWorks

4番手、CrowdWorksがフロントエンドの視点も絡めた事例を紹介してくれました。
現存するガイドラインが守られていないと運用上の負があったと語っていました。その内容も結構ひどくて、注意喚起用のスタイルがお知らせで使われたりとしっちゃかめっちゃかだったそうです。

作りたいのは、原則・指針から誰のためのデザインなのか?を明確にするガイドライン。ユーザビリティの観点から、目的がわかるガイドラインにする必要があって、ここをきちんと理解できると多くの人がガイドラインの規定を守りやすくなるのでは?と考えたそうです。

ガイドラインの作成にあたって、POやエンジニアの意見を取り入れることでチームとして意義のあるものにしていく意識付けも行ったそう。今はデザイナーだけではなくてフロントエンドのエンジニアもガイドラインはよく見る状態になったそうです。

サービスを運営している会社あるあるなんですが、短期的目標を追うあまり、中長期的な視点での施策やデザインがなされないと言う事実は、デザインを進める上での障害になると語っていたのがかなり共感できました。

BIZREACH

トリ。BIZREACHがHRMOSの事例を紹介してくれました。

微細な違いの色が乱立したり、インタラクションが不明なUIなどが散見されている状態だったそうで、これらを解消するためにガイドラインを設定したとのこと。

以前はsketchでデザインを作成、Google Driveへ反映を手作業で行っていたが、現在はsassで管理しているそう。そこにガイドラインを織り交ぜて運用していて、base-primaryで基本色を設定し、base-secondaryはbase-primaryから明度を何%、彩度を何%調整する、などのルールを決めているようです。コードベースでガイドラインを管理できるのはやはり強みだなぁと感じました。

コードにすることで得られるメリットとしてもう一つ、インタラクションまで含めたガイドラインにできる点があります。
インタラクションまで含めたガイドラインにすることで、動きが不明なUIを減らすことができますし、実装用のコードも併記することで各職域でしみ出すことができ、共通言語ができるのが大きなメリットになると言っていました。

現状のガイドラインは非常にうまく機能しているという話をしていました。ただ1点、新たな課題としてガイドラインの運用にフロントエンドが必要になるため、フロントエンドにタスクが集中しやすくなったと語っていました。これらは会社や事業の置かれた状況次第でどう言った運用方法が最適か?を考えるべきだなぁと思いました。
ガイドラインにコストをあまり支払えない事業であれば、こういった管理は難しいかもしれません。

その他

一旦、各社の発表内容のまとめは異常だったのですが、他にこんな感じの話もありました。

ガイドラインについては、各社とも制作中や道半ばといった状態であることを伝えていました。デザインやサービスが生き物である以上、作り終わるということはないのかもしれませんね。

で、運用をいかに軽くするか?はきちんと考えるべきだと感じました。 デザインガイドラインを作るのが目的ではなく、事業上でどう機能させるか?という点での手段でしかないというところは忘れずにおきたいですね。

ななうみ
デザイナーって社内で作業してあまり活発に社外で交流しない、そういう場が少ない、と思っていたのですが開催してみると多くの人が参加しますし、有意義だなーと感じました。デザイナーをやっている方々、デザイン系のイベントがあったらぜひ参加してみましょう!得るものが結構あると思いますよ〜