「Atomic Design & Design Systems」をお話させて頂きました
DMM.com ラボさまの社内勉強会にお声がけ頂き、「Atomic Design & Design Systems」というテーマでお話させて頂きました。
当日の構成
勉強会のテーマがAtomic Designについてだったので、前半はGUILDさん勉強会でお話させて頂いた内容を少し持ってきました。
後半ではAtomic Designの視点をもう少し広げて、Design System（毎回デザインシステム表記とどっちにしようか悩む）全般について、僕が調べたり考えたことをまとめました。
と言っても自分は何かしらのデザインシステムを取り入れたり実践したりと言った経験はありません。そのため、内容のほとんどは海外の事例や記事の引用・意訳になります。Design Systemについてまとまった情報が知りたい！という方には有益かと思いますが、基本的なことは知ってるよーという方にはあまりお役に立てないと思います。
というわけで、本記事では後半部分の「Design Systemとは何か」「Design Systemのはじめかた」「Design Systemへの疑問、そして未来」について、当日お話した内容を再現しつつご紹介したいと思います。
ちなみに本記事中で引用している記事・サイト等は下記でまとめておりますので、ぜひ参考にしてみてください。
読まれる前に
- 本記事で取り上げる「Design System」の範疇ですが、いわゆるWeb・アプリケーションにまつわるものに限定しています。
- 海外記事からの引用についてはGoogle翻訳→それっぽい意訳、と信用度の低い翻訳となっていますので、意味を取り違えている箇所があればご指摘頂けますと幸いです。
- 特に明確な答えが出る内容ではありません。あしからず。まとまりはない。
- 全部書き終えたら1万3000字になってました。
Design Systemとは何か
「Design System」とは何か、その問に答えるのはなかなか難しいのではないかと思います。いくつか引用してみましょう。
「デザインシステムとは、標準的なUIパターン、フレームワーク、アセット、ドキュメンテーション、そして関係するプロセスや人々です。それはあなたのプロダクトの統合された進化を推進し、支援するエコシステムです」
Dummy’s Guide to Building a Design System「デザインシステムはビジュアルスタイル、コンポーネント、その他に関することをドキュメント化したライブラリとして提供し、個人、チーム、あるいはコミュニティがコードやデザインツールとして取り入れることで、プロダクトをより効率的で一貫性のあるものにできます」
Defining Design Systems「デザインシステムは最初の色を選ぶことからは始まらない。代わりに、顧客のニーズを識別し、目標を設定し、デザインの方向性を探求し、収束し、戦略を策定し、組織のコミットメントを得る戦略のシステムを構築します」
Starting a Design System「デザイン言語やデザインシステムは、単にスタイルガイドだけではない、チームの働き方や価値観、原則です」
Setup a design system
共通点としては「単なるスタイルガイドではない」「人やプロセスなどを含む」あたりでしょうか。スタイルガイドとデザインシステムの違いについて下記の図を用いて説明している人もいます。
これはどういう意味かと言うと、おそらく「プロダクトのインターフェイスの管理とスタイルガイドには何も結びつきがないため、プロダクト上で増え続けるインターフェイスをスタイルガイド側で感知することはできない（だから上図では線が水平のまま、成長しない）。一方、デザインシステムはインターフェイスと結びつきがあるため、システムが成長するごとにインターフェイスは整理・管理され、無駄に増えるということはない。そしてデザインシステムは適切に成長し、そして終わりはない」…という図解だと思われます。
デザインシステムとはプロダクトである
また、Nathan Curtis氏の「デザインシステムはプロジェクトではない。サービスを提供するプロダクトである」という言葉は、抽象度の高い定義ではあるものの、個人的にはとても腑に落ちました。なるほど、プロダクトとして捉えれば、上図でデザインシステムに終わりがないことや、チームや組織、戦略といった言葉が出てくるのも納得です。
具体的な言及例
なんとなくデザインシステムについてぼんやりと輪郭が見えてきたような気もします。もう少し具体的な言及についても触れてみましょう。
UX PinのCEOであるMarcin Treder氏は Design Systems Sprint 0: The Silver Bullet of Product Development. で39個のデザインシステムを分析し、それぞれのシステムが含んでいる項目の割合を下記のようにまとめています（※ %は目視計算）。
- 高精度のUIパターン：約90%
- 低精度のUIパターン：約15%
- 導入のためのガイドライン：約85%
- コードスニペット / コードリファレンス：約75%
- カラーパレット：約72.5%
- アイコン集：約70%
- タイポグラフィ：約80%
- グリッド / レイアウト定義：約82.5%
- ブランドガイドライン：約17.5%
- デザイン原則：約37.5%
Nathan Curtis氏はTwitterで下記の図を用いてデザインシステムを定義しています。
“A design system is…”, still a bit complex yet slightly revised since last time… pic.twitter.com/d61ABO2H76
— Nathan Curtis (@nathanacurtis) 2017年6月1日
あるいは、Jan Toman氏は Design systems, style guides, pattern libraries. What the hell is the difference? でスタイルガイド・デザインシステム・プロダクトの関係性を以下のように示しています。
Atomic Designの提唱者であるBrad Frost氏も、5章でデザインシステムは「成果物とパターンライブラリを支えるもの」であると書いています。
ここまでの情報をまとめると、どうやらデザインシステムというのはスタイルガイドやパターンライブラリ、それ以外の原則や言語、動きなどをとりまとめてプロダクトへ反映する中枢の仕組み、と捉えられる気がします。
Design Systemは何を解決するのか
デザインシステムが何であるか、それとなく感じを掴めたところで「そもそもデザインシステムを導入することで何が解決するのか」についても軽く触れてみます。
Marcin Treder氏は先述のDesign Systems Sprint 0: The Silver Bullet of Product Developmentで「デザインに一貫性がないと起こりうること」として
- ユーザーの混乱
- 同じアクションをさまざまなパターンが担当するとユーザーは混乱する
- 遅いデザインプロセス
- 再利用可能なデザインアセットの欠如はデザイナーの作業スピードを遅くする
- 遅い開発
- 十分に再利用可能なコンポーネントが少ないと開発が遅れてしまう
- オンボーディングの難しさ
- 新しいデザイナーやエンジニアをドキュメント化されていない「システム」に入ってもらうのは難しい
を挙げています。また、Brad Frost氏もAtomic Designの4章でデザインシステムを導入するために、同僚やステークホルダーに次のような説明をするとよいと書いています（そして、言葉の説明だけでは難しいのであればInterface Inventoryを作るとよいとも）。
「デザインシステムは一貫した経験をもたらす。これは、ユーザーがUIをより早く習得することを意味し、ステークホルダーが気にかけている指標に基づいてより多くのコンバージョンとより多くの収益をもたらす」
「デザインシステムはチームの仕事をスピードアップする。新しいリクエストが来るたびに車輪を再開発するのではなく、チームは既に確立されたUIパズルを再利用して、新しいページや機能をこれまで以上に早く公開することができる」
「パターンライブラリ内のUIコンポーネントを集中化することで、組織内のすべての人に共通の語彙が確立され、すべての職種に渡って、よりコラボレーティブな作業フローが作られる。同じ言語を使用するすべての人が作業を完了するのに費やす時間は長くなり、前後のコミュニケーションや会議に費やす時間は減る」
まとめると、UIおよび語彙の一貫性の担保、それによる内外のユーザーの理解補助、プロダクト開発のプロセス効率化、と言ったところでしょうか。
個人的には、もう少しチームや個人について言及されていると、より納得感があったかなと思います（規模や状況によって異なるとは思いつつ）。
Single source of truthとDesign Tokens
さて、デザインシステムについて調べていると「Single source of truth（信頼できる唯一の情報源）」という言葉がキーワードとしてよく登場します。どうやらソフトウェア業界で使われている用語らしく、Atlassianのブログでは
「“Single Source of Truth” (信頼できる唯一の情報源) は、関連したデータが彼方此方に保管されたり重複されることを防ぐための、正確な管理方法を意味します。ツールやシステムを導入・構築し、多岐にわたる組織の情報が一つの場所に集約される環境を作ることで、現状把握を隅々まで行えるだけでなく、チームに負担をかけずに最小限の時間で決断に必要な情報収集ができるようになります」
迅速な戦略的決断ができる環境とは
と解説されています。これをデザインシステムに適用すると「コードとデザインが一元管理されており、最終成果物とシームレスに繋がっている状態」といったところでしょうか。デザインシステムはこのSingle source of truthが実現されている状態が理想像とされており、ここまで図示されてきたデザインシステムもそれに倣っています。
一方、後述しますがSingle source of truthを実現するにはいくつかのハードルがあるのも確かで、特にアプリケーションについてはWebよりも難易度が高いのではないかと思います。
また、SalesforceはSingle source of truthへの回答として「Design token（デザイントークン）」と呼ばれる仕組みを挙げています。最近だとInVision DSMに統合されたBrand.aiも採用していますね。
Lightning Design Systemではデザイントークンを「ビジュアルデザイン属性を格納する名前付きエンティティ」と説明しています。トークンデータを適切に管理・運用することによって、WebやiOS、Androidなどプラットフォームを横断したステータスの引き渡しができる仕組みのようです。ようです、と書いたのは私自身まだデザイントークンについては十分な理解をしていないためです。デザイントークンについて知るには、下記の記事が参考になります。
一旦、ここまでの話をまとめてみます。デザインシステムとは何か。
- プロジェクトではなくサービスを提供するプロダクトである
- スタイルガイドやパターンライブラリも含むが、それだけで完結はしない
- Single source of truthを実現することが理想である
- チームの働き方や価値観、プロセスそのものも含む
と言えるのではないかと思います。では、実際にどのようなデザインシステムがあるのか。デザインシステムをどのように導入するとよいのか触れてみます。
Design Systemの実例
今回は列記するに留めますが、いわゆる世に「デザインシステム」として出ている代表的な事例をまとめてみました。
- Salesforce Lightning Design System
- BBC GEL
- Shopify Polaris
- U.S. Web Design Standards
- IBM Carbon Design System
- GE Predix Design System
- VMWare Clarity Design System
- Airbnb Design Language System
- Atlassian Design Language
- Francfranc Design System
他にも知りたいという方は下記のまとめが参考になります。
Design Systemのはじめかた
デザインシステムを導入しようと思った時、どのように始めるとよいのか。まずは目的や方向性を定めることが大切です。「なぜ必要なのか？現状はどうなっているのか？」「誰のためのデザインシステムなのか？」「導入することで何が期待できるのか？」「やらないことは何か」などでしょうか。「Dummy’s Guide to Building a Design System」では
- 現在どんなツールを使用していますか？
- 他にどんなツールを使うべきですか？
- 新しいツールは私たちの解決策に影響を与えますか？
- 私たちの戦略は、自社の技術ロードマップと一致していますか？
- これらのソリューションはどれくらいの期間でリリースしますか？
- 最初のデザインシステムのリソースや範囲を調整する必要がありますか？
が、「A Design System isn’t a Project. It’s a Product, Serving Products.」では
- 誰が意思決定者ですか？
- 誰が仕事をしますか？
- 誰が予算を支払いますか？
- タスクの作成と優先度付けをどのようにやりますか？
- （デザインシステムの）対象のプロダクトは今後半年〜1年に何が期待できますか？
が問いとして挙げられています。これらの問いはみなさんがデザインシステムを導入しようと考えた時の助けになるでしょう。
もう少し簡潔にまとめたいという方にはNathan Curtis氏が「Defining Design Systems」で紹介している穴埋めステートメントが役立つかもしれません。
また、デザインシステムそのものをどう作っていくか、という点においてはMarcin Treder氏の「The Minimum Viable Design System」が考え方の参考になるのではないかと思います。
「スタイルガイドとは異なり、デザインシステムの価値はすぐに経験できます。デザインシステムは、たとえ最初の成果が5つのPrimary Colorと命名規則のセットであったとしても、ほぼ即時に価値を発揮し始めます」
「組織によって1つの色が定義され、正しく命名され、実装され、受け入れられるデザインシステムは、パーフェクトな静的スタイルガイドよりも優れています」
この「必要最低限な機能を持ったデザインシステム」は、組織あるいはチーム内でデザインシステムが適切に機能するか、運用できるかを検証するにはよいボリューム感だと思います。まずはMVDSを作ることで、どのようにデザインシステムを導入できるか、いかにチーム内でデザインシステムが”生きた”状態で成長できそうか、を検証してみるとよいのではないでしょうか。
デザインシステムのためのチーム
デザインシステムのためにはどのようなチーム体制を考えられるとよいでしょうか。Nathan Curtis氏は「Designing a Systems Team」で「システムチームには成長段階がある」とし、以下の4段階を紹介しています。
最初のステージ1は「隙間時間を利用した個人（Spear Timer）」です。この段階で作られるのはシステムというよりはテンプレートに近く、個人のモチベーションによって維持されています。デザインシステムの価値が組織内で認識されることにより、次のステージへと移行します。
ステージ2は「割り当てられた個人（Allocated Individual(s)）」です。この段階ではビジュアルデザインを担当できるデザイナーかUXデザインを担当できるデザイナー、あるいはフロントエンドエンジニア2名による小規模な体制（フルタイムではなく、業務時間の10〜25%）によって、標準化されたデザインアセットやコード化されたキットなどの目に見えるアウトプットを定期的にリリースします。次のステージへ行くには、品質の高いアウトプットを（組織内で）公開し、信頼性の高いサービスを提供する必要があります。
アウトプットが定期的にリリースされ、顧客（システムを使うプロダクトチーム）が採用し始めると、いよいよ専属チームを作る検討がはじまります。
ステージ3は「プロダクトチームとしてのシステムチーム（System Team–as–Product Team）」。いよいよ正式なチームとなります。チームの規模は最小で3人、大きくなると10人近くになると言われています。この時大切なのは、デザイン・エンジニアリング・プロダクトマネジメントのうち、どれか2つのスキルを合わせ持つメンバーをリードとして置くことだと書かれています。
最後のステージ4は「チームのシステムチーム（System Team of Teams）」となり、システムチームを構成するためのチームという、大規模な構成となっています。記事内ではGoogleやIBM、Microsoftなどが例として出されており、「通常、デザインシステムで提供されるプロダクトの数はこれらの企業よりもはるかに少ないため、この規模は非現実的だし不必要だ」とも書かれています。
またNathan氏は「Team Models for Scaling a Design System」ではデザインシステムのチームモデルとして「孤独モデル（The solitary model）」「一元化されたチームモデル（The centralized team model）」「連合モデル（The federated model）」の3つを紹介しています。
それぞれのモデルのメリットとデメリットについて、Nathan氏は以下のように書いています。
「各モデルには長所と短所があります。孤独モデルは高速かつ断片的ですが、1人の担当者が多くのことをしているので「君主」は多くのタスクのボトルネックになります。
一方、チームモデルはシステムを適切に維持しますが、ユーザーのニーズとの関係性が低くなる可能性があります。
最後に、連合モデルは、すべてのプロダクトの機能とユーザーのニーズに必要なものについて十分な洞察力を持っていますが、このモデルはシステム構築以外の分野での作業が忙しくなることがあります」
Team Models for Scaling a Design System
以上がデザインシステムにおける成長段階とモデルについてでした。
デザインシステムが失敗する理由
ここまで、デザインシステムの導入する時のファーストステップや、どのようなチームがあるとよいかなど「どうすれば始められるか」について紹介してきました。今度は反対に、デザインシステムが失敗する理由についても触れておきましょう。Una Kravets氏は「Why Design Systems Fail」で考慮するべき7項目を挙げています。
- 組織的支援
- 組織のトップレベルとボトムレベルからのサポートが必要です。プロジェクト管理者からVPまで、デザインシステムの価値を見極め、実装のためのリソースを提供し、全社的な使用を提唱する / してもらう必要があります。
- 投資
- デザインシステムはプラットフォーム全体に大きな影響を与えることができるため、初期段階からアクセシビリティや堅実な設計構造に投資することが非常に重要です。
- 責任
- デザインシステムのチームは「コンポーネントの設計と構築」「全体的なUIの一貫性とアドヒアランスの支援」「ロールアウトプランの作成とアップデートシステム」など、いくつかの責任を負います。
- コミュニケーション
- デザインシステムに投資するためのリソースと計画があれば、その人やチームはデザインとエンジニアリングの橋渡しをすることが非常に重要です。継続的なコミュニケーションが非常に重要です。
- 同意
- プロダクトを使ってもらえる良い方法は、使うことへの抵抗を最小限に抑え、価値を示すことです。実例と使用法を集めてましょう。なぜなら、目に見えることは伝えるよりはるかに強力だからです。
- 構造
- 成長とスケーラビリティを念頭に置いてデザインシステムを構築しましょう。
- 摩擦
- デザインシステムが複雑で過度に設計されているとシステムのユーザーは使うことにストレスを感じ、以前の使い慣れているシステムに戻す可能性があるため、最適な解決策とは言えません。
半分近くが組織内での理解やコミュニケーションに関わる内容ですね。それだけ、デザインシステムの導入は組織への影響度が高いのでしょう。もちろん失敗する理由はこれだけに収まらないと思います。デザインシステムやチームの育成・運用に関わること、技術的にどこまでやるか、そもそも失敗と成功の判断基準をどう設定するか、なども考えられるでしょう。
Design Systemへの疑問、そして未来
さて、ここまでざっくりと「デザインシステムとは何か」「デザインシステムのはじめかた」について、調べてきたことをまとめてみました。ここまでを読んでみて、どのような感想を持たれたでしょうか。僕はこう思いました。「なんかいい話すぎる…！」と。
というわけで、最後は僕自身が疑問に思ったこと、そしてデザインシステムの未来についてご紹介します。
疑問その1 アプリケーションと相性悪い説
世の中にあるデザインシステムのほとんどはWeb主体であり、Single source of truthのことを考えると、仕組みとしてはそうなるんだろうなと思わされます。一方で、真にプラットフォームを横断できるデザインシステムが一般化してきた時には、今度はOSとのカニバリゼーションが発生してしまうのではないかと思います。どういうことかと言うと、
- デザインシステムで一貫性を持たせることでプラットフォームを意識せず、サービスの体験を届ける
- プラットフォームのガイドラインに合わせることで、プラットフォームを通した一貫性、体験を届ける
のどちらを選ぶべきかの判断をする必要があるのではないか？と思うわけです。
前者では自分たちのプロダクトのデザインシステムを優先することで、Webやアプリ間での一貫性を提供できます。それこそMaterial Designなどは良い例の1つですね。反対に後者では、いわゆるHIGやMaterial Designを採用することで、ユーザーが触れている世界、OSの中で統一感を提供できます。
これに関してはそれぞれ良い面悪い面もあるので一概にどうと言うものでもないのですが、今後デザインシステムを考えるうえで、検討課題として上がってくるのではないでしょうか。
ちなみにEtsy社は当初複数プラットフォームをサポートする予定だったのが、最終的にはWebに焦点を当ててシステムを拡張することを最優先事項としたそうです。
疑問その2 運用例、見ない説
デザインシステムとは何か、デザインシステムを作った、という「目に見えやすい」記事はたくさん見かけますが、実際に「どう運用した（している）か」という「目に見えにくい」事例に関しては、今のところ十分なボリュームのあるものは見つかっていません（自分が単にうまく探せていないだけかも）。それこそLightning Design SystemやBCC GELは数年は運用されていると思うのですが、なかなか肝心の部分が見えてこないのですよね。デザインシステムは導入はもちろんですが、運用フェーズの話も重要だと思っているので、なかなかここの知見が得られないのはもどかしく感じます。
疑問その3 失敗例、見ない説
上記と似ていますが、「デザインシステム構築してみたけど、ダメだったよ！」という声もなかなか見つからないんですよね。みんなうまいことリリースできて運用できているのでしょうか。それともまだ、完全に失敗したとは言えないほど、長い期間システムが動いてないだけなのでしょうか。
疑問その4 サービス横断はできるのか？
最後の疑問は「デザインシステムを組織内のサービスで横断させることは可能なのだろうか？」という疑問です。 例えば以下はDMMさんのサービスの一部ですが、これらをデザインシステム（Single source of truth）でまとめることは可能なのでしょうか？
これについては自分で疑問を出しておきながらある程度答えは見えていて、「おそらく難しい」。ターゲットや方向性が違うサービスに無理に横断させても、本来の目的を達成することは逆に難しくなってしまうでしょう。IBMとか、エンタープライズ向けのプロダクトを複数持っているような状況だと、また話は別だと思うんですけどね。会場でも実際に経験のある方から「絶対にやめたほうがよい」との声が出ていました。
ただ一方で「じゃあ、もしも横断が可能なデザインシステムがあったとしたら、それはどんなものなのだろうか？」というのは考え続けてみてもいいと思うのです。デザインシステムというワードを餌にして、社内のデザイナーが集まってみるのも面白いんじゃないかと思います。Yahoo! JAPANさんとか、サイバーエージェントさんとか……
疑問その5 Single source of truthは制作プロセスにどう影響するか
Single source of truth、たしかに素晴らしい概念だと思います。これが容易にできれば開発プロセスは大きく変化すると思います。ですが、だからこそ、既存のメンバーに求められるスキルも大きく変化するんじゃないかと思うのです。具体的には、デザインツールベースからコードベース（あるいは両方のスムーズな相互互換性）への変化ですとか、チーム体制、運用スキル、などなど。事前に認識合わせをしていたとしても、急に環境を変えるのは結構リスキーだなと感じました。
未来につながるいくつかのこと
最後の最後は、いい感じの話で終わりたいと思います。お話するのは「Design Systems Handbook」の6章で語られていたことの抜粋になります。ここでもやはりSingle source of truthに触れており、いわく、達成するにはハードルがあると書かれています。
「信頼できる唯一の情報源」を達成するには2つのハードルがあります。
第一に、現在のデザインツールは不十分です。たいていの場合、UIのイメージを作成してもデザイナーは製品レベルの忠実度を達成できないようになっています。
第二に、デザインシステムの実装が複数のリポジトリ（Android、iOS、React Native、Reactなど）に分散されたり、Sketchファイルに集められていたり、Webサイトでドキュメント化されている場合、実際にはシステムの正直さを表す単一のコードベースは存在しません。
「信頼できる唯一の情報源」が欠如していると、複数のコードベースに広がるデザインシステムは、簡単に同期の外れたソースが混在したものになります。
Design Systems Handbook 6章
このハードルに挑んでいるのが、Airbnbです。
Design Systems Handbook 6章より、AirbnbのDesign Toolsチームが提案したSingle source of truth。
AirbnbはDesign Language Systemというデザインシステムを用いたプロダクト開発をしていたり、R&D的にSketchのプラグインを開発していますが、それらは全てSingle source of truth実現のためだったんですね。React Sketch.appやLonaなどが成果物の一部と言えるでしょう。特にLonaは…自分自身まだよく理解できていませんが、デザインシステムの定義とプラットフォームへの橋渡しを容易にしてくれるツールなのではないかと思います（おそらくデザイントークンに近い？）。
これからのデザインシステム
Design Systems Handbookの最後の章は、デザインシステムのさらなる可能性に触れながら締めくくっています。
まず1つ目は「フィードバックループによる好循環」。
「Airbnbでは、デザインシステムのコンポーネントを使用しているネイティブアプリの大部分のデータが表示されます。これらの統計情報をユーザーの指標に結び付けることで、どのコンポーネントが成果を上げていないかを知ることができます。
（略）
プロダクトで基準コンポーネントが使用されている場所を追跡し、そのコンポーネントにフラグを適用します。フラグが付いたコンポーネントをポーリングすると、使用状況がデザインシステムチームに返され、得られたインサイトは内部ツールとシステム自体を改善するために使用されます」
2つ目は「レイアウトの認識」。
「デザインシステムのコンポーネントは、一般的にどこで使用されるべきかを伝達できるようになり、どのような種類のデータを含んでいるかという情報も共有できるようになります。この機能は、簡単な実装であっても、ドイツ語のような長い言語やアラビア語のような右から左の言語などがコンポーネントのレイアウトにどのように影響を及ぼすのかを確認するのに役立ちます」
最後は「予測的なアセンブリ、パターンツール」。
「デザイナーが特に有用なコンポーネントのグループ化 (またはパターン) を可能にすることによって、予測アセンブリを備えたレイアウト認識ツール (“デザインシステムパターンツール”と命名される可能性が高い) は、プロダクトのデザイナーがシステム内で繰り返し可能なパターンをすばやく発見できるようになります。1回のクリックだけで、デザイナーは多くのコンポーネントで作られた効果的なソリューションを作成し、あらゆるプロジェクトの基本的なデザインを出力することができます」
これらは現状のデザインシステムを補完するというよりは、今後、よりデザインシステムが拡充された時に起こることを想定しているのではないかと思います。共通点としては「自動化」「状況に応じた変化」でしょうか。そういえばAdobe MAXでは、Adobe senseiを用いてデザインのパターンを複数作成するデモが発表されていました。Airbnbも、手書きのラフスケッチからコードを内包したコンポーネント・レイアウトを作成する技術を開発中です。
このように、デザインシステムを考えるうえでAirbnbの動きは見逃せないものになっています。2018年はどんなことを始めるのか、今から楽しみです。
最後に
以上、DMMさんの勉強会でお話をするために、自分が調べたり話したりしたことをまとめてみました。引用文が多いからだけど、まさかの1万3000字超え…
この記事内でも参考リンクをたくさん貼り付けていますが、まだまだ出せていないものもあるので、それはまた別の記事でまとめていきたいと思います。
デザインシステムは万人が取り入れるべき概念ではないかもしれませんが、プロダクト開発に関わる人なら頭の隅で考え続けてもいいトピックなんじゃないかと思います。
日本国内でのデザインシステムの事例はまだまだ少ない、というかほぼないのが現状だと思いますが、もし取り組まれている企業や個人の方がいれば、ぜひ実際の体験談を聞いてみたい…というのは個人的な我儘であり希望です。なかなかクライアントワーク側だとデザインシステムの提案とか導入って難しいなと思ってまして、ここはやはり事業会社で熱量を持っている方の動きにとても期待しているのです。それこそ、DMMさんとか。
今回の記事が誰かの熱源になって、日本国内でもデザインシステムについての議論が少しでも活発になってくれたら嬉しいです。
あ、あと最初に書いたように翻訳の精度は信用ならないので「ここは本当はこういう意味だよ」などのツッコミがありましたら、ぜひぜひお知らせくださいませ。
