この記事は、David Leeのbrunchを参考、Airbnb Designから翻訳しました。
この記事はAirbnbの「新しいデザインシステム(New Design Language System)」シリーズの一部です。
ソフトウェア開発とデザインをする時、私たちはよく、一回生(one-off)ソルーションを作ることが多いです。時には時間制約野中で働くことが多く、どのように進めていけばよいかがまとめられていない状態で働いているからです。一回生ソルーションが悪いものではありませんが、堅実な基礎に基づいて立てられなかったら、私たちは結局、後から技術的負債とデザイン的負債を返済しなければなりません。
ビジュアル言語は、他の一般的な言語と違わないです。言語がうまく伝えられなく、理解できない場合、誤解が生じます。プロダクトやチームの成長につれ、このような現象はもっと複雑になります。
デザインはいつもシステムに関するものでした。どのように拡張ができて、反復可能なシステムを作れるかに対する悩みでした。PantoneカラーからPhilipsのねじまで、このようなシステムは混雑な状況を管理し、より良いプロダクトを作り出すことができます。このシステムにもっとも相応しい領域はデジタルプロダクトであるかもしれませんが、時には優先順位から外されます。
まとめられたデザインシステムは、より速く、より良いプロダクトを作り出すに必須的であります。一貫性のある経験は、ユーザーがより簡単に理解することができますし、共通の言語で作業するためより速くなります。
デザインシステムが必要な理由
Airbnbは数年間にわたって多くの成長をしてきました。現在、Airbnbのデザイン部署は約12個の機能とアウトカムチームで構成されています。私たちの集団的努力と作業を活用するためのより体系的な方法が必要であることは明らかになってきました。この問題を社内では認識していましたが、ここだけじゃなく、この業界の大きな問題であると私は確信しました。
少なすぎる制約事項。ソフトウェアデザインは他の分野と比べて物理的な制約がほとんどありません。これはおそらく、任意のチャレンジに対する様々なソルーションがでいますが、それによりユーザー経験がばらばらになります。プロダクトのオーナーやデザイナーとして、私たちは独自の制約事項を作成し、それに従わなければなりません。
多様なデザイナーと関連したメンバーたち。ソフトウェアはよくチームによって構築されます。非常に大きなチームの場合もあります。より多くの人が追加されるにつれて、一貫した経験を生み出すという課題は難しくなります。また、チームの大きさと関係なく、時間の経過とともに様々な人々が新しいソルーションとスタイルを出し、ユーザー経験が乖離されてしまいます。
多様なフラットフォーム。私たちはプロダクトを多様のフラットフォームやデバイスを通して提供します。機能とデザインを同期させるためには相当な努力が必要となります。多くの場合、全てのフラットフォームで同じ作業が繰り返されることもあります。
連続性(Continuum)。ソフトウェアのもう一つの独特なことは、従来の消費者製品のように摩耗されたり、交換されないということです。数年前に作成されたコードやデザインは、企業やそのプロダクトが大きく変わった後も、まだ多くの場所に存在しています。なので一定のメンテナンスとアップグレードが必要となります。
始める(Getting to work)
このような課題を解決し、迅速な意思決定プロセスを処理するために、私たちは少数のデザイナーとエンジニアで構成されたチームを作りました。[1]私たちはやっていた作業を止めて、Airbnb本社の近くのスタジオを確保し、Design Laguage System(DLS)のデザインと構築に専念しました。
DLSの目標は、より美しく使いやすいデザイン言語を作ることでした。私たちのデザインは明確で再利用可能なコンポーネントを通じて効率を向上させる統一されたプラットフォームでなければなりません。これらを具体化するために、最初のネイティブフラットフォーム(iOS&Android)に集中することになりました。
私たちはこれまで作ってきたデザインを全て印刷しました。ボード上にフローを並べて配置することで、ユーザー経験がどこでどのように壊れていたのか、どの段階で変更を開始する必要があるのかを把握しました。私たちは問題を解決する最もよい方法は、始める最前で立ち向かうことであると考えました。私たちのそれぞれは、画面やプロダクト領域に終点を当て、再度デザインをしました。そして私たちはこれらのデザインを導くためのいくつかの原則を確立しました。
統一性：各作品はより大きな全体の一部であり、全体的なシステムにポジティブに寄与しないといけません。浮き上がったり、関連のない要素があったらいけません。
総合性：Airbnbは全世界の人々が使っているサービスです。私たちのプロダクトとビジュアル言語は親しくてアクセシビリティの良いサービスであるべきです。
象徴性：私たちはデザインと機能すべてに重点を置いています。私たちの作業はこの焦点を大胆かつ、明確に話すべきです。
疎通性：
基礎を築く(Laying the foundation)
このデザインスプリントを始める前に、私たちは基本となるスタイルガイドを作成しました。私たちはここに、タイポグラフィ、色、アイコン、間隔、情報アーキテクチャ(IA)を大まかに定義しました。このスタイルガイドは、私たちがそれぞれの部屋で各自創造的なデザインソルーションを探索する時も、作業が統一した方向に導く重要な要素として判明されました。このように私たちは、同じ言語で考えて一緒に仕事していると感じました。毎日の終わりに私たちはお互いのデザインをレビューし、そこでパターンが現れ始めることがわかりました。私たちは必要に応じて方向を修正し、標準化コンポーネントを定義することにしました。
コンポーネント作成する(Creating the components)
伝統的に多くのスタイルガイドはコンポーネントを「アトミックデザイン」形式として作成しました。これは原子コンポーネントを作り、それらが集まってより複雑な分子を構築することに使われます。この形式は理論的に一貫性のある柔軟なシステムを作る上で効果的です。しかし、実際には再利用可能な原子コンポーネントが様々な方法で使用され、結果的にあらゆる種類の分子コンポーネントを生成させます。つまり、これはあらゆる種類の不自然なユーザー経験の扉を開き、システムの維持をより困難にします。
原子コンポーネントに頼るのではなく、私たちは生きている要素として考えました。彼らは一組のプロパティによって定義され、機能と個性を持ち、他のコンポーネントと共存できますが、独立して進化することもできます。統一されたデザイン言語は、静的なルールと個別の原子だけでなく、進化する生態系であるべきです。
統一されたデザイン言語は、静的なルールと個別の原子だけでなく、進化する生態系でなければなりません。
例えば、ユーザーアバターは最初にスタイルガイドによって定義されることが可能ですが、結局プラットフォームでのアバター使用は数百のパフォーマンスを取ることができ、後からアバターを正常にアップデートすることは難しいです。”これらのうち、修正する場合は他の画面を壊さないようにできます。”
各コンポーネントは必須要素(タイトル、テキスト、アイコン、画像など)によって定義され、追加的な要素(Option)も含むこともできます。これらの要素はSketchでもコードでも定義されています。区切り(divider)を個別コンポーネントにする代わりに、各コンポーネントが区切りを含むようにしました。ビューロジックに基づいて表示または非表示にしました。
ライブラリのコンパイル(Compiling the library)
このようなコンポーネントを作成する際に、ライブラリと呼ばれるマスターファイルでこれらのコンポーネントを集めました。このファイルはデザインプロセス全体で参照することができました。1–2周後に、デザインを反復する時にライブラリを使うことで、生産性が飛躍的に向上するようになりました。ある日、最後のプロトタイプを組み立てながら、私たちはライブラリが提供するフレームワークを使い、ほんの数時間で約50個の画面を作成することができました。ライブラリが成長している間、私たちは各コンポーネントを似たアイテムのあるアートボードに編成することを始めました。これらのアートボードは、ナビゲーション、マーキー(Marquees)、コンテンツ、イメージ、その他ケース(Speciality)に分類しました。
私たちは、モバイルのコンポーネント(iOS・Android)を作成し、そこからタブレットサイズに合わせました。タブレットコンポーネントはモバイルとほぼ同じで、一つのコードで二つの異なるスタイルを管理することができました。コンポーネントの外観と配置が異なる、レスポンシブデザインがWebで同作するのと同じです。その後、デザイナーは一般的なコンポーネントを使用して画面をデザインし、iOSやAndroidを含めた様々なサイズにも簡単に合わせることができました。
私たちはいくつかの簡単なタブレットレイアウトコンセプトを作成しました。例えば、下のフォーカスビューのようなもので、ページ上のコンテンツ、モーダル、２コラム、そしてレイアウトに合わせるフォーカスビューです。
全てのコンポーネントとビューは、独自のテクニカルビューフレームワークで構築され、スタイル、状態、適応性(adaptivity)を処理します。[2]
学んだこと(Lessons learned)
このプロジェクトは私たちに相当挑戦的でした。それは私たちのアプリのほとんどのビューをリデザインし、リビルドすることを意味しました。私たちは4月17日にシステムの作成・新しいアプリのリリースという目標を達成しました。が、どんなプロジェクトでもそうですが、いくつか惜しい部分があります。
全てのコンポーネントが同じとは限りません。ほとんどのアプリはコンポーネントを繰り返して使います。私たちの場合、これらのコンポーネントが列(row)またはテーブルセル(table-cell)でした。振り返ってみると、もっと時間をかけて列について考えて、より強いパターンとコンポーネントを作成できたと思います。結局のところ、色々な種類の矛盾がありました。
Sketch。私たちは最初、コンポーネントをSketchのシンボルとして作成しようとしましたが、結果的に混乱が生じました。今でも、Sketchファイルは管理するのが難しいです。今後は、新しいコンポーネントの管理や作成のより良い方法を見つけることを願っています。[3]
文書化(Documentation)。このプロジェクトは厳しいスケジュールの中で作業する必要があったため、文書作成プロセスの一部が禊ぐされました。その結果、詳細な文書がなくて、混乱は避けられなかったかもしれません。コーディングと同じく、デザインプロセスの中の記録はプロセスに取って最も重要です。いずれ行う必要があり、デザインプロセス全体を通して文書化することで、よりスムーズな意思決定が可能になります。
結論(Conclusion)
この作業は多くのプロダクトチームからの努力が必要となった、非常に重要な作業でした。デザインシステム(Design Language System)を作成することは、投資する価値のあり、大きな飛躍を遂げる価値があることで必ず必要なプロセスでした。
デザイン言語とコードが共有されるため、ほぼ同時に機能を構築し、リリースできるようになりました。プロダクトエンジニアはビューコードよりも機能ロジックを書くことに集中できるため、開発プロセスも高速になりました。さらに、エンジニアとデザイナーは共通の言語でコミュニケーションするようになりました。
エンジニアだけでなく、デザイナーもこのシステムに多くの興味を持ちました。パディング、色、タイポグラフィ選択などに時間をかけるのではなく、実際のデザインのコンセプトや経験に焦点を当ててプロダクトレビューすることができました。DLSはビジュアルスタイルに対する共感を生成し、全ての作業(contributions)を一つのシステムに集まるようとしました。また私たち全員がより低いコストでより早く、より忠実に新しいアイデアをプロトタイピング・テストができるようになりました。
DLSを通して、私たちが将来的に作りたいと思うコンセプトと、実際のユーザー経験にもっと焦点を当てることができると私は信じています。
Karri SaarinenはAirbnbのPrincipal Designerで、手作りコーヒー、写真撮影、料理することが好きです。Twitter: @Karri Saarinenに連絡することができます。
脚注：
[1] 多数の成功的なプロジェクトはチームから出ており、常に感謝する人たちが大勢います。ここではこのプロジェクトが無事に終わるように貢献した数名だけ言わせてください。：Bek Stone, Adam Michela, Amber Cartwright, Alex Schleifer, Michael Bachand, Paul Kompfner, Sean Abraham, Salih Abdul-Karim, Michael Sui そして多くのデザイナーとエンジニアに感謝します。またこの記事の下書きを検討してくれたJosh Leong, Sola Biu, Catherine Waiteに感謝します。
[2] DLSの技術的な部分はエンジニアが書くよう、残しときます。
[3] 私たちはシンボルサイズを変更できるようにしたいと思いました(例えば、ヘッダーにもっと多くのコンテンツを入れる必要があるなど)。3.5バージョン以上のSketchでは、もしシンボルのサイズを変更すると、自動的にそのシンボルの全てのインスタントサイズも変更してしまいます。それはあなたのSketchファイルをほんの瞬間で、永久に無駄にするかもしれません(時には元に戻すこともできなくなります)。私たちは結局レイヤーグループにコンポーネントを配置し、他の人々がそれらをコピペできるようにしました。また、git/githubを使用し、ファイルをアップデートしました。私たちは手動で新しいコンポーネントを作成、マスターライブラリSketchファイルに追加し、変更事項を記録してPull requestを生成し、pngファイルをエクスポートしました。その後、Sketchファイルは共有されたクラウドフォルダーに保存され、新しいコンポーネントにすぐアクセスできるようにSketchテンプレートにリンクされました。
