この記事は、新しいデザイン言語システムに関する連載の一部です。Karriは最近、Designer News "Ask Me Anything "のインタビューで、このトピックに関する質問に答えました。その記録はこちらでご覧いただけます。
ソフトウェア開発・設計の仕事では、単発のソリューションの出荷を求められることがよくあります。時間的な制約がある場合もあれば、進むべき道筋にまだ合意していない場合もあります。このような単発のソリューションは本質的に悪いものではありませんが、しっかりとした基礎の上に構築されていなければ、最終的には技術やデザインの負債を返さなければならないことになります。
ビジュアル言語は、他の言語と同じです。その言語を使用するすべての人が共有し、理解しなければ、誤解が生じます。製品やチームが成長すればするほど、これらのモダリティにおける問題は大きくなっていきます。
デザインは常に、システム、そして拡張性と再現性のある方法で製品を作成する方法についての大部分を占めてきました。PantoneカラーからPhilipsのネジに至るまで、これらのシステムによって、私たちは混沌を管理し、より良い製品を生み出すことができるのです。デジタル製品は、このようなシステムを導入するための最も肥沃な土地であると言えますが、優先事項とは見なされないことが多いようです。
統一されたデザインシステムは、より良いものをより速く作るために不可欠です。統一されたエクスペリエンスは、ユーザーにより容易に理解され、共通の言語を使用できるため、より速く作ることができます。
デザインシステムが必要な理由
Airbnbはここ数年で大きな成長を遂げました。現在、私たちのデザイン部門は、10近い機能と成果チームから構成されています。そのため、私たちの努力を導き、活用するための、より体系的な方法が必要であることが明らかになりました。私たちは社内でこのような課題を認識していましたが、これはソフトウェア業界のより大きな問題の表れであると私は考えています。
制約の不足
ソフトウェア設計は、他の多くの設計分野と比較して物理的な制約がほとんどありません。そのため、与えられた課題に対してさまざまな解決策を講じることができますが、同時に、バラバラなユーザー体験をもたらす可能性もあります。プロダクトオーナーやデザイナーとして、私たちは自分たちで制約を作り、それに従わなければならないのです。
複数のデザイナーとステークホルダー
ソフトウェアは、多くの場合、チームで、時にはとてつもなく大きなチームで作られます。一貫性のあるエクスペリエンスを生み出すという課題は、そこに加わる人数が増えれば増えるほど、指数関数的に増大していきます。また、どんなに一貫性のある小規模なチームであっても、時間が経つにつれて、さまざまな人が新しいソリューションやスタイルを提供し、体験が乖離することになります。
多種多様なプラットフォーム
私たちは、数多くのプラットフォームやデバイスに製品を出荷する必要があります。機能やデザインを同期させるためには多大な労力が必要であり、多くの場合、これらのプラットフォームすべてで同じ作業を繰り返す必要があります。
連続体としてのソフトウェア
もうひとつ、ソフトウェアのユニークな点は、製品でありながら、従来の消費者向け製品のように消耗したり買い換えたりすることがないことです。何年も前に作られたコードやデザインは、企業やその製品の状況が大きく変化した後でも、多くの場所に残っています。そのため、常にメンテナンスとアップグレードが必要です。
仕事の進め方
こうした課題を克服し、意思決定を迅速に行うため、私たちはデザイナーとエンジニアからなる少人数のグループを結成しました[2]。私たちはカレンダーを整理し、Airbnb本社のすぐ近くにある外部スタジオを予約し、Design Language System (DLS) の設計と構築に専念しました。
DLSで設定した目標は、より美しく、よりアクセスしやすいデザイン言語を作ることでした。また、再利用可能なコンポーネントで構成され、より効率的なプラットフォームであること。そのために、まずはネイティブプラットフォーム（iOSとAndroid）でシステムを構築することに、最初のスコープを絞りました。
まず、新旧のデザインをプリントアウトし、監査することから始めました。フローをボードに並べてみると、どこでどのように体験が壊れているのか、どこから手を加えればいいのかが見えてきました。私たちは、まず問題に正面から取り組むことが最良の方法だと考えました。各自が画面やプロダクトの領域にフォーカスして再設計を行い、その際に指針となるいくつかの原則を設定しました。
統一的であること
各パーツはより大きな全体の一部であり、規模に応じてシステムに積極的に貢献する必要があります。孤立した特徴や異常値はあってはならない。
普遍的であること
Airbnbは世界中で幅広いグローバルコミュニティによって利用されています。私たちのプロダクトとビジュアルランゲージは、歓迎され、アクセスしやすいものでなければなりません。
象徴的であること
私たちはデザインと機能性の両方に重点を置いています。私たちの作品は、このフォーカスを大胆かつ明確に語るものであるべきです。
対話的であること
私たちの製品に生命を吹き込み、ユーザーとわかりやすくコミュニケーションするためのモーションが必要です。
基礎づくり
このデザインスプリントを始める前に、私たちはすでにファンデーションと呼ばれる基本的なスタイルガイドを作成していました。このファンデーションは、タイポグラフィー、カラー、アイコン、スペーシング、インフォメーションアーキテクチャなどを大まかに定義したものです。このファンデーションは、私たちの仕事を統一した方向に導くと同時に、それぞれがクリエイティブなデザインソリューションを探求する余地を残すために不可欠なものでした。こうすることで、私たちは同じアイデアに向かって一緒に仕事をしているのだと実感することができました。一日の終わりに作品を見直すと、パターンが浮かび上がってきます。必要に応じて軌道修正し、標準化されたコンポーネントを定義し始めました。
コンポーネントを作成する
従来、多くのスタイルガイドでは、コンポーネントを原子部品として定義し、それを使ってより複雑な分子を構築していた。理論的には、これは首尾一貫した柔軟なシステムを作るのに有効な方法です。しかし、実際には、再利用可能な原子がさまざまな方法で使用され、あらゆる種類の分子が作成されることがよくあります。この場合も、バラバラな体験ができるようになり、システムの維持が難しくなります。
私たちは、個々の原子に頼るのではなく、構成要素を生命体の要素として考えるようになりました。部品には機能や個性があり、一連の特性によって定義され、他の部品と共存し、独立して進化することができます。統一されたデザイン言語は、静的なルールと個々のアトムの集合ではなく、進化するエコシステムであるべきなのです。
統一されたデザイン言語は、静的なルールや個々の原子の集合ではなく、進化するエコシステムであるべきなのです。
例えば、ユーザーのアバター要素は、最初はスタイルガイドで定義されているかもしれませんが、プラットフォームでの最終的な使用方法は何百通りもあり、将来的にアバター要素をうまくアップデートすることは困難です。" これらのいずれかを変更したい場合、他の画面を壊さないようにすることができます。
各コンポーネントは、必須要素（タイトル、テキスト、アイコン、画像など）で定義され、オプション要素を含むこともあります。これらの要素は、Sketchのドキュメントとコードで定義されています。仕切り線そのものを許可するのではなく、各コンポーネントに仕切り線を要求し、ビューロジックに基づいて表示/非表示を設定します。
ライブラリのコンパイル
これらの部品を作りながら、ライブラリというマスターファイルに集め、設計の過程で参照するようにしました。1〜2週間もすると、デザインを繰り返す際にライブラリーを使うことで、生産性が大きく向上することが分かってきました。ある日、急遽プロトタイプを作成することになったのですが、ライブラリのフレームワークを使うことで、わずか数時間で50画面近くを作成することができたのです。
ライブラリーが充実してくると、個々のコンポーネントを、似たようなものを集めたアートボードに整理していくようになりました。これらのアートボードは、一般的なカテゴリーごとに整理されました。ナビゲーション、マーキー、コンテンツ、イメージ、スペシャリティです。
これらのコンポーネントをスマホ（iOS、Android）用に1セット作成し、そこからタブレットサイズに対応させました。タブレット用のコンポーネントは、モバイル用のものとほぼ同じで、技術的なレベルでは、コードは2つの異なるスタイルで一度だけ存在すればよいのです。このシステムでは、Webのレスポンシブデザインと同じように、コンポーネントの見た目や配置を変えることができます。デザイナーは、共通のコンポーネントを使って一度だけ画面をデザインすれば、異なるスクリーンサイズやiOS、Androidに簡単に対応することができるのです。
タブレット端末向けには、ページ上のコンテンツにフォーカスするフォーカスビュー、モーダル、2カラムやグリッドレイアウトなど、いくつかのシンプルなレイアウトコンセプトを作成しました。
すべてのコンポーネントとビューは、これらのスタイル、状態、適応性を処理する、独自の技術的なビューフレームワークで構築されています。[2]
得た教訓
このプロジェクトが困難なものであることは分かっていました。それは、私たちのアプリのビューの大部分を再設計し、再構築することを意味します。4月17日にシステムを構築し、新しいアプリをリリースするという目標は、なんとか達成することができました。どのようなプロジェクトでもそうですが、こうすればよかったと思うことはあります。
すべてのコンポーネントが同じように作られているわけではない
ほとんどのアプリでは、頻繁に繰り返される一連のコンポーネントがあります。私たちの場合は、行（またはテーブルセル）です。今思えば、行についてもっと時間をかけて考え、より強力なパターンとコンポーネントを考え出すことができればよかったと思います。結局、いろいろな種類のものができてしまい、矛盾も生じてしまいました。
Sketch
当初、これらの部品をSketchのシンボルとして作成しようとしたのですが、結果的にめちゃくちゃになってしまいました。今でも、Sketchのファイルのメンテナンスが大変なことがあります。今後は、より良い方法でコンポーネントのメンテナンスと新規作成を行いたいと考えています。[3]
ドキュメンテーション
今回のプロジェクトでは、タイトなスケジュールで動く必要があったため、ドキュメンテーションのプロセスを一部見落としていました。ドキュメントが不十分だったことで、本来なら避けられたはずの混乱が起きてしまったのです。コーディングと同じように、システムを作りながらドキュメントを作成することは、プロセス上、最も重要なことです。遅かれ早かれ行わなければならないことですが、作成プロセスを通じてドキュメントを作成することで、よりスムーズな意思決定が可能になります。
まとめ
これは、多くの製品チームの努力を必要とする記念碑的な作業でしたが、私たちは、デザイン言語システムの構築が投資に値するものであり、大きな飛躍であることを発見しました。
設計言語とコードを共有することで、すべてのネイティブ・プラットフォームでほぼ同時に機能を構築し、リリースすることができるようになりました。製品エンジニアは、ビューコードよりも機能ロジックの記述に集中できるため、一般的に開発はより迅速になります。さらに、エンジニアとデザイナーが共通の言語を使用できるようになりました。
デザイナーもこのシステムには満足しています。このシステムにより、製品レビューでは、パディングや色、タイプの選択ではなく、デザインの実際のコンセプトや体験に焦点を当てることができるようになりました。DLSは、私たちのビジュアル・スタイルに対する共通の理解を提供し、単一のシステムへの貢献を合理化するものです。また、このシステムによって、私たち全員がより早く、より低コストで、忠実度の高いプロトタイプを作成し、アイデアを試すことができるようになりました。
これらのシステムを活用することで、今後、実際のユーザー体験や作りたいコンセプトに、より注力できるようになると考えています。
DLSをめぐるトーク（2018年6月更新）。
SFデザインウィーク - 2018年6月 カーリ・サーリネン システム化されたクロスプラットフォームデザイン
デザインシステムカンファレンス - 2018年3月 カリー・サーリネン 私たちがシステムを使うとき
Nordic.design - 2017年9月 カーリ・サーリネン システムでデザインを拡張する
脚注
［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］私たちの場合、シンボルのサイズを変更できるようにしたいのです（例えば、ヘッダーにもっとコンテンツを入れる必要がある場合など）。このような場合、Sketch（<3.5>）は自動的にシンボルのすべてのインスタンスをリサイズしてしまいます。そのため、スケッチがしばらくの間停止し、おそらく永久にファイルを混乱させるでしょう（時々、元に戻すことが機能しないことがありました）。私たちは結局、コンポーネントをレイヤーグループに置き、人々がそれらをコピー＆ペーストできるようにしました。また、ファイルの更新を容易にするために、git/githubを使用しています。マスターライブラリのSketchファイルに新しいコンポーネントを手動で作成・追加し、変更ログと生成されたpngエクスポートを添付してプルリクエストを提出し、変更を記録しています。その後、SketchファイルはBoxという共有フォルダに保存され、Sketchテンプレートとリンクしているので、誰でもすぐに新しいコンポーネントにアクセスすることができます。
