Atlassianがデザインに注力し始めた2012年、新しいデザインチーフとしてJürgen Spangl氏が雇われました。彼が始めた最初のプロジェクトの1つは、新しい会社内のデザインシステムであるAtlassianデザインガイドライン(ADG)の作成でした。
当時Atlassianは、デザイン手法を拡大する際に共通する、いくつかの困難に直面していました。
- デザインのばらつき:当時は45種類の異なるドロップダウンがありました。
- ツールの不足:複数の製品にまたがって仕事を拡大するために、チームはより強力なデザインツールを必要としていました。
- 余計な質問:Atlassianのデザイナーは、「どのボタンを使うべきか」などのよくある質問に答える時間を減らして、コアな問題により多くの時間を費やしたいと望んでいました。
かつてNathan Curtis氏は、「デザインシステムとは、製品を提供するための製品である。」と言いました。確かにAtlassianのデザインシステムは、複雑な課題を解決する必要性から生まれた、もっとも野心的な製品の1つです。
Atlassianが不統一から調和を実現した経緯を解き明かすため、私たちはデザインチーフのJürgen Spangl氏と、リードデザイナーのJames Bryant氏に、デザインシステムの設計と管理、発展について伺いました。
第1版の作成と適用
Appleのヒューマンインターフェイスガイドラインに影響を受けて、Atlassianは、使いやすさが維持されていながら、コードを基盤としたデザインシステムを構築する必要があると判断しました。
この作業のために、複数のチームの人々が貢献しました。デザインシステムを単独で作らないように、最初に専門のチームを組むことはしなかったのです。この判断が功を奏したのは、デザインシステムに関するスペシャリストが会社全体に配属されてからでした。
Jürgen氏は次のように述べます。
「私たちは、一貫性だけに固執していたのではなく、デザインシステムによって、より調和したユーザー体験を作りたかったのです。デザイナーだけでなく、全員がより良い意思決定をできるようにしたいと考えていました。」
このプロセスには、当然課題が山積していました。Jürgen氏はさらに続けます。
「当初私たちは、大規模なデザインシステムをどのようにドキュメント化するべきなのか良くわかっていませんでした。Confluenceを使ったり、Confluenceに付属しているiFramesや、Bitbucketのレポジトリを使ったりしました。ShipItのハッカソンのときに初めて、あるデザイナーの手によって社内のUIツールキットがコードに統合されたLiving Style Guideに変換されました。」
技術的な枠組みを整理すると同時に、デザインシステムチームは、すべてのブランドと製品のデザイン言語を統一する必要がありました。Jürgen氏は次のように語ります。
「複数のチームに1つのデザイン言語を使用してもらうことは、決して簡単ではありません。あなたのチームでは、統一したデザインの方針を作っていますか? それとも製品毎にそれぞれ方針を作っていますか?」
デザイン言語を決定してすべてのパターンや項目を作成するために、チームは次のような2段階のプロセスに従いました。
- チームは毎月、ADG作業のために集合していました。迅速な意思決定とチームの勢いによって、チームは完成度70~80%の新たなパターンをたくさん作ることができました。
- その翌週に、チームは時間を細かく区切りながら、作ったパターンを洗練していき、それらをADGにコーディングしました。
ADGの初期バージョンは2012年6月にリリースされ、チームは段階的にADGの運用を開始しました。最初にBitbucketでロールアウトし、そのあとConfluenceとJIRAでもロールアウトしました。
デザインシステムのサポートと管理
開始から5年がたった今、Atlassianのデザインチームは200人近くの社員を抱えるまで成長しました。さまざまなデバイスやプラットフォーム、マーケティングプロパティをまたいで、デザインシステムはブランド全体と12個の製品を管理しています。
以来Atlassianは、18人の正社員からなるADGの特別チームを設けています。内訳は5人のデザイナーと11人のエンジニア、そしてライターとプロジェクトマネージャーが1人ずつです。高度な技術力を保つために、エンジニアチームはデザイン組織全体に配属されました。
James氏は次のように言います。
「私たちのチームに加わりたいと思うデザイナーたちにとって、コーディングに関する知識は大きな利点になっています。またデザイナーたちは、プロトタイピングツールへの深い理解が必要です。そしてエンジニアと組んで仕事をすることで、仕事をその場で渡すことができます。最終的に彼らは、デザインの仕事がどのように異なるコンテキストや製品、チームの中に作用していくのかを理解しなくてはなりません。」
デザインシステムへの貢献という点に関して、作業のフローは2つのオープンソースモデルを採用しています。
- ADGのチームは、デザインシステムの変更や統合を定期的に模索しています。最初のリサーチを行うと、チームは集まってスペックや要件を議論します。そのあとプログラムマネージャーは、プロダクトチームと一緒にデザインシステムの変更を調整して公開し、フィードバックを観察します。
- プロダクトチームも、デザインシステムの変更を提案することができます。デザインシステムチームのメンバーと協力できるように、製品それぞれに対してADGチームの代表者が配置されるようになってからは、より簡単に提案できるようになりました。
変更リクエストはJIRAとConfluenceで管理され、更新はReactをベースとするAtlasKitにオンタイムで通知されます。これは、デザインパターンやコードの要素の信頼性を示すためです。ADGチームもSketch上で、すべてのデザイナー向けのUIのアセットライブラリを保管しています。また、ADGのWebサイトでは、全部のパターンや項目の使い方に関するロジックやガイドラインが解説されています。
デザインシステムを発展させる
Jürgen氏は次のように主張します。
「新しい流行や技術によって、5~7年ごとにデザイン言語を完全に刷新する必要があるでしょう。世界は常に変わり続けています。」
チームは2週間のスプリントで作業を行い、数日~数週間で顧客に新しく反復したものを届けます。カラースキームやUIパターンの変更など、より大きな変更の場合はもう少し時間が必要です。
James氏が指摘するように、プロダクトチームにデザイナーを配属させること、逆にデザインチームにエンジニアを配属させることは、デザインシステムの変更に対するコンセンサスを素早く得るのに役立っています。
「組織の規模が大きい場合、すべてのデザイナーにすべての変更を伝えるという対応はとても難しいです。私たちのアイデアや変更の提案が、現在のプロジェクトに影響を与えるかどうかを判断するために、大規模なデザインの評価にはチーフ全員を動員します。彼らは私たちの考え方から何かを学び、そして学んだことを自分の作業に活用できるかもしれません。」
デザインシステムの更新が成功したかどうか判断するのに、チームは複数のソースからデータを測量します。
- デザインシステム変更のための、製品上でのオプトイン、オプトアウト
- デザインシステム更新後の製品に対するNPSスコアの変化
- 反復したADGを、UserTestingと対面セッションによってテストすることで得られる、質的、量的なフィードバック
現在は第3版が使われており、しっかりと適用、運用されています。ADGの次なる目標の1つは、バックエンドのサービスにより一貫性を持たせることです。
James氏は言います。
「バックエンドに一貫性を持たせる大変優れた事例として、ユーザー向けに製品内の『メンション』を改良していることが挙げられます。ガイドラインとフロントエンドの要素をデザインすることで、一貫性のある体験を感じられます。しかし同様に、バックエンドの工程にも、パフォーマンスを改善できるように一貫性を持たせることができるのです。私たちは今、このレベルのプラットフォームサービスを改善する方法を模索しています。」
結論
Atlassianの製品の質を考慮すれば、デザインシステムを保有しないことのリスクはきわめて高いと言えます。
James氏は言います。
「ユーザーがより作業しやすくなるように、私たちはツールを変え続けています。私が思うに、変化によって作業しにくくなることほどイライラすることはありません。なぜなら、効率性や収益が脅かされるからです。」
デザインシステムとは、単なるスタイルガイドやパターンライブラリではありません。製品開発の青写真です。デザインパターンやコードの要素を共通言語に統一することで、ADGはユーザーが快適に使える範囲から逸脱することなく進化することができます。
Jürgen氏は次のように語ります。
「プロダクトチームとADGチームにある程度緊張感があるのが、とても健全な関係です。プロダクトチームが合理的な理由なく、ADGチームに屈することはありません。一方で、ADGチームはすべての変更リクエスト応じるわけでもありません。この絶妙なバランス関係が、市場で私たちが進歩し続ける秘訣です。」
Atlassianのデザイナーに興味はありますか? Atlassianのデザインキャリアページをチェックして、応募可能な職種を見てください。