SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

DeveloperZine(デベロッパージン)- エンジニアの意思決定を支える技術情報メディア ProductZine

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

はてなのプロダクト開発の舞台裏

プロダクトのデザインを長く健康に保つには?――デザインの優先順位・チームでのコミュニケーションのコツ

はてなのプロダクト開発の舞台裏 第4回

デザインを体系化して持続性を高める

 プロダクトを運用して規模が大きくなっていけばいくほど、その全容を把握するのがむずかしくなっていきます。その結果、既存のデザインと一貫性のないデザインをしてしまうことがよく起こります。何人かのデザイナーで1つのデザインをつくりあげる必要が出てくると、この問題はより複雑になっていくでしょう。そんなときに役立つツールが「デザインのガイドライン」です。

 カクヨムでは2人目のデザイナーがチームに配属されたとき、ガイドラインの整備をはじめました。カクヨムのデザインに取り組むときの考えかたをひと息で伝えるには限界があると考えたからです。誰でもいつでも参照できる状態にしておくことで、デザイナー以外の職種の方にも見ていただけるようになりました。おかげでアートディレクションに費やす時間を減らせています。

カクヨムのデザインガイド。開発リポジトリ内に作成
カクヨムのデザインガイド。開発リポジトリ内に作成

 もし1人のデザイナーで、デザインのすべてをまかなえているのであれば、貴重な工数を割いてまでして、ガイドラインの作成に取り組まなくても良いと思います。カクヨムもベータリリースから丸3年間はガイドラインと呼べるものはありませんでした。デザイナーが一貫性のあるデザインを安定的に供給することが目的であって、ガイドラインをつくることは目的ではないからです。

 ただ、それでもガイドラインをつくる理由があるとすれば、コミュニケーションのため、という場合が多いでしょう。例えば、使用可能な色を伝えたいとか、コンポーネントの一覧をまとめたいとか、最終的なアウトプットイメージを揃えたいといったものです。必要性がうまれてから準備をはじめても遅くはありません。

デザインのガイドラインはプロダクトに合わせたサイズで

 それでは、ガイドラインをつくりたくなったとき、どこから手をつけたらよいのでしょうか。数年前からフレームワークとして人気を博しているデザインシステムが参考になります。なにをどのようにまとめると、効果的なガイドラインになるのか。ガイドライン作成の勘どころを押さえておくのに役立ちます。

 インターネットで紹介されるデザインシステムの事例は網羅的で厳格なものが多いですが、魔法のiらんどでつくったガイドラインは、それとは違って、かっちり体系化をしていませんし、具体的なルールもすくないです。それでも十分に機能していました。まさに取り組み始めたばかりのガイドラインの例としてちょうど良いです。

 具体的には2つのものをつくっています。1つはAdobe XDを利用したスタイルガイドで、もう一つはStorybookを利用したパターンライブラリです。スタイルガイドはグラフィックデザインのプリミティブな要素である、色、形、文字のパターンをまとめたもの。パターンライブラリは具体的なコンポーネントが一覧できるものです。これらは、デザインシステムでいうところの認知パターンと機能パターンにそれぞれ対応します。

左:スタイルガイド(スウォッチ)、右:パターンライブラリ(Storybook)
左:スタイルガイド(スウォッチ)、右:パターンライブラリ(Storybook)

 このガイドラインのポイントは、デザインに柔軟性を持たせようと堅苦しいルールを決めすぎないようにしたところです。新しくなったばかりのプロダクトでは、大きめの基礎的な機能開発がつづくので安定するにはまだはやいですし、コミュニケーションのツールとして機能すれば十分だったからです。それに、デザインには意味のコンテキストが重要だと考えているのも、柔軟性を歓迎する理由でした。スタイルガイドをスウォッチ(見本)と呼んでいるのが象徴的ですが、守らなければならないルールではなく、あくまでもデザインのサンプリング対象として存在しているのです。

 プロダクトのフェーズやニーズから考えた小さなガイドライン。これも立派なデザインのガイドラインと呼べるのではないでしょうか。

小さくはじめてバランスをみつける

 このようにデザインを体系化していくと、一貫性や効率を改善して、おなじものをデザインすることが容易になります。しかし、場合によってはデザインのコンテキストがおろそかになった結果、画面や状態に応じた効果的なデザインをほどこす機会を奪ってしまうかもしれません。

 そういう意味では、プロダクト開発と同じようにまずは小さくはじめるのがよいでしょう。必要性にあわせて拡張していけばよいので、メンテナンスコストを天秤にかけながら、まずは小さなところから取り組んでみてください。たったひとことのコンセプトだけでもガイドラインに記す価値があります。ルールをかっちり定めることが絶対の善ではないので、それぞれのプロダクトの規模に応じた最適なバランスを探ってみてください。

次のページ
デザインの破綻に対処して持続性を高める

この記事は参考になりましたか?

はてなのプロダクト開発の舞台裏連載記事一覧

もっと読む

この記事の著者

村田 智(株式会社はてな)(ムラタ サトシ)

@murata_s。アートディレクター/デザイナー。武蔵野美術大学視覚伝達デザイン学科を卒業後、2013年はてなに入社。ウェブやアプリの企画、情報設計、ビジュアルデザインをおこない、新サービスの立ち上げやグロースに貢献している。主な仕事に、サーバー監視サービス「Mackerel」、小説投稿サイト「カ...

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

この記事は参考になりましたか?

この記事をシェア

CodeZine(コードジン)
https://codezine.jp/article/detail/12791 2020/09/30 11:00

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー