Design Systems

デジタルプロダクトのためのデザインシステム実践ガイド

私のキャリアのはじめはWebデザイナーだった。Webデザイナーと言っても簡単なHTML/CSSコーディングもするデザイナーだった。というわけで、自分が作ったUIカンプを自分でコーディングするのだが、どうしてもデザインしているときに後々のコーディング工程を意識してしまうので、できるかぎり角丸は避けたり(当時はCSSのborder-radiusなどなかった)していた。でも世の中的にはWeb 2.0の丸っこいアクアボタンが流行ってたときだ。こうゆうのはよくないなと思いつつも、納期との兼ね合いだったり、いろいろ妥協せざるを得なかった。

時が経ちフロントエンドエンジニアになった私は、ここで初めてUIデザイナーと分業に入るわけだが、デザイナーからあがってくる無限に増殖するボタンであったり、無限に増殖するカラバリに苦悩する。当時はコーディング都合でUIのクリエイティビティも阻害してはいけないと思っていたが、それでプロダクトのパフォーマンスが低下したら元も子もない。現状の環境においての妥協・最適解を見つけなければならない。

そうゆうわけで、個人的にCSSフレームワークを探求する日々が続いた。デザイナーの要望をできる限り受け止めつつも、スパゲッティなコードにならない・破綻しない、そんなフレームワークを探していたが、そんなものはなかった。

また時は経ち、今度はデザイナー側からデザインシステムという単語を聞くようになった。結局それなんてBootstrapよ?と思ってたけど、本書を読み、いくぶんか理解した。デザインシステムの構成要素は以下の通り。

  • デザイン原則 / Design Principles
  • 機能パターン / Functional Patterns
  • 認知パターン / Perceptual Patterns
  • 共有言語 / Shared Language

デザイン原則はそのシステムまたはカルチャーを表す短い文章や単語のことで、Pinterestの場合、『明快・活気・壊れない』だそうだ。こうした原則をもとに次のデザインパターンを作成していく。

(MDとiOSではSteppersという同じ名前のコンポーネントでも機能は違う)

機能パターンは、カードやボタン・スライドショーといった、いわゆるUIコンポーネントのことを指す。認知パターンはカラーやタイポグラフィなどスタイルのこと。そして最後にチーム内での共有言語。例えば、アプリ内で特に目立つボタンをなんと呼ぶのか、『プライマリーボタン』『ビッグボタン』呼び方自体はなんでもいいが、それをデザイナー・エンジニア全員が共有しておく必要がある。

結局、フロントエンドエンジニアである私が頑張っていた領域というのは機能・認知パターンだけだったのだ。それもUIカンプからエンジニアが抽出したパターンにエンジニアが命名してできたUIフレームワークなどデザイナーには関心がなかったことだろう。

そうゆうわけで、システムは一人で作れない。プロダクトに関わる全員が関心をもって取り組まなければならない。そうでないとすぐさまメンテもされず廃れていくことだろう。そうならないためにも、みんなでレビューするシステムだったり、いつでもUIコンポーネントを試せるプレイグラウンドであったり、デザインシステムをメンテナンスするシステムが必要になってくるだろう。

最近では、DevOpsにちなんでDesignOpsという言葉も聞く。Airbnbにはデザインオペレーションチームが存在し、各スペシャリストをつなぐ仕事をしている。これはAirbnbみたいなでっかい会社だからできることであるだろう。数人で開発してるようなスタートアップでのデザイン・システム導入は現実的ではない。

最初から大層なデザイン・システムを作ろうとしなくてもよい。上記事のようにデザイン原則だけでも最初に決めておくのは良いことだろう。それがアンカーとなりデザイナー・エンジニアの共通理解となる。要は全員の目先を合わせることが必要なんだろうと思った。デザイン・システムを作ること自体が目的になってはいけない。

See also