ShopifyのデザインシステムがUX向上のために遂げた進化とは

Yesenia Perez-Cruz

YeseniaはShopifyのシニアUXマネージャーです。

この記事はMediumからの翻訳転載です。配信元または著者の許可を得て配信しています。

Design systems need experience foundations

Shopifyはオールインワンの取引プラットフォームで、ユーザーはこれを使って事業を始め、運営し、成長させることができます。支払い、マーケティング、輸送、顧客のエンゲージメントに関わるツールなどの一連のサービスをオンラインの小売業者に提供することで、Shopifyは世界中の100万以上の事業者の力になっています。2016年から2019年までの間に、Shopifyにおける事業は世界の経済に3,190億ドルの貢献を果たしました。

ShopifyのPolarisはオープンソースのデザインシステムで、業者が一貫性のあるユーザー体験を作り上げるのに役立ちます。このシステムはデザイナーがアプリやShopify上のチャンネルをつくる際に使えるガイドラインと原則から構成されています。Polarisは、業者にとって親しみやすい、アプリをつくるのに必要な「積み木」などのリソースと材料を提供しています。また、パートナーは彼らが使えるUIキット、スタイルガイド、コンポーネントとパターンのライブラリをダウンロードできます。

・・・

私たちがPolarisをつくることからShopifyで学んだことは、システムはつくるよりも維持する方が大変であるということです。なぜなら、デザインシステムはどうしても負債を作り出してしまうからです。コンポーネントは思いもよらない使われ方をしたり、派生したりします。依存関係があると、予想通りの変更を加えることは難しくなります。私たちはShopifyの管理のための新たなデザイン言語を作り出そうとしていた10月に、これらの問題に直面しました。細かいビジュアルの変更がプロダクト全体に与える影響をテストすることに時間がかかり、完成が遅くなりました。

Sparkboxのデザインシステム・サーベイの2020年版をみてみると、同じ悩みが表れています。

インハウスの回答者の42%は、当初の自社デザインシステムの作り方が、組織の技術部署、あるいはデザイン部署にとっての負債を作り出したと感じていた。

デザインシステムをつくったことでどのように負債が生まれたのかと尋ねると、上位2件の回答はいずれも企画の失敗に関することだった。

私は、舗装道路を維持するコストについてのこの話を思い出します。いくつかの町がお金を節約するために、舗装された道路を砂利道に戻しています。舗装道路の利点は、ドライバーがより早く目的地に行けることです。しかし道路を維持すること、舗装し直すことにはお金がかかります。また、道にできた穴にはまるよりは、よく整備された砂や砂利の道を走る方が車にとってもよいでしょう。

ここでのモラルとは、インフラを整備するコストに見合う利益が人々にもたらさせれるなら、そのインフラへの投資には価値がある、というものです。私たちがデザインシステムをつくるのも結局は、舗装された道路の場合と同様に、ユーザーがもっと簡単にタスクを達成できるようにしたいからです。このシステムを内部のチームがもっと早く動けるようにするためのツールとしてみて、狭すぎるフォーカスをもってしまうと、この視点を忘れてしまいます。わかりづらいユーザー体験を上手に届けるためのデザインシステムなどに価値はありません。

よりよいユーザー体験を実現したいのであれば、私たちの現状のデザインシステムの基盤は十分ではありません。私たちには、体験という基盤が必要なのです。

デザインシステムの基盤と言われると、あなたはおそらくデザイン、UI、コード、そしてチームがもっと効率的にシステムをつくるために使えるコンテンツの要素のことを考えるでしょう。こうした要素はすべて備わっており、今日のPolarisで数多く使われています。Polarisチームはこれらの要素をもっとよいものにすることに集中してきましたし、おそらく今日に至ってもそれを続けていたでしょう。ですが、2020年という年がプランを変えてしまいました。

Polarisチームは4月にすべての既存のプロジェクトを停止しました。プロダクトチームには2ヶ月の間、コロナのために優先すべきプロジェクトを進める手助けをしてもらいました。私たちはデザインシステムのことを良質なUXについての決断を進めるためのツールとして考えていましたが、プロダクトチームがシステムを使う中で、次のようなことが明らかになりました。

  • 決断には賞味期限がある:ある決定がシステムに追加されたときには意味があったとしても、もはや最善のソリューションではない、ということもあります。
  • 決断がわかりにくい:特に、その決定がなされたあとに入社した人にとってはそうです。
  • 明確な根拠のない決断は制約のようなものである:特に、それがUX上の問題を解決するための障害となっているのであれば。

また、プロダクトに関わる作業の中には速さと効率が重要なものがある一方で、振り返る時間もときには必要です。彼らはシステム内のソリューションが役に立っているかどうか、それに取り組むべきなのか、あるいはまったく新しいものをつくるべきなのかを理解する必要があるのです。

ですから、私たちは自分たち自身に次のように問いかけました。

  • ただ決断を推し進める代わりに、決定につながった根拠を支援することはできないか?
  • ただ仕事の速さを達成する代わりに、振り返りと理解の時間をシステムでつくれないか?

これらの疑問から、私たちはPolarisの体験の基盤(experience foundation)をつくることになったのです。

体験の基盤とは、ユーザーの課題に対する私たちの理解を、モジュール化された、相互に繋がった要素に分解するためのフレームワークです。私たちがUIをモジュール化された要素まで分解するのと同じやり方です。

これは、次の要素から構成されます。

  • ジャーニーによって表される、業者の仕事
  • コンテキストによって表される、彼らの仕事の仕方
  • ファクターとして表される、彼らが仕事の中で直面するプレッシャー

ジャーニーとは、仕事をするためにShopifyを扱う際にユーザーが進むステップです。たとえあなたのプロダクトチームが機能別のチームに分けられていたとしても、彼らはタスクを終わらせようとしているのですから、彼らからあなたの組織の継ぎ目がみえてはいけません。ユーザージャーニーをマッピングすることで、Shopifyチーム(たとえば支払を担当するチーム)は一体性の無さに繋がっているようなサイロ構造がどこにあるのかをみつけることができました。

コンテキストは、ユーザーを取り巻く環境を説明するものです。つまり、誰が、なにを、どこで、どうやって、というような情報です。コンテキストがあれば、システム内での決断の背後にある根拠がわかり、それによってShopifyチームは自信をもってシステムを使い、修正し、進化させることができます。

ファクターとは、デザインに影響を与えうる、さまざまな体験の中で共有された可変の条件のことです。私たちは、チームが別々の環境において別々のオーディエンスの問題を解決しようと試みても、似たようなソリューションに行き着くことに気づいたのでした。たとえばリテール、ウェアハウジング、運転の体験をそれぞれ扱っているチームが皆、大きめのタイポグラフィと少なめの画面上のUIというUIエレメントを作り上げました。複数のチームが同じようなソリューションを考えているのであれば、そのファクターは共有できそうです。

私たちは体験の基盤に関するドキュメントを、簡潔でモジュール化されたものにする必要がありました。特に2020年においては長ったらしいテキストを読みたくない人が多いので、簡潔でなければなりません。また、モジュール化されていることで、別々のローカルシステムのドキュメントの間で発見を関連づけることができました。

私たちは、モジュール化された発見のカードとファクターのタグによってそうした目的を達成しました。それぞれの体験について、3つから5つの発見があります。これらの発見は基本的に、チームのユーザーのコンテキストに対する理解、またそれをチームがどのようにUX上の決断に反映したかをまとめたものです。発見はファクターによってタグ付けされて、各ファクターにはローカルシステムの枠を超えて発見と決断を集めるための固有のランディングページがあります。

ファクターとは、デザインに影響を与えうる、さまざまな体験の中で共有された可変の条件のことです。この探求(Explore)の体験のおかげで、チームはローカルシステムの枠を超えて発見と決断をみつけることができます。(Polarisサイトの内部テスト版のスクリーンショット)

ファクターのページの最初のバージョンには発見と決断とがあるだけでしょうが、これはやがてチームがローカルシステムの枠を超えたシステムに関する知見を得るために役立つようなもう一段階上の検索ツールへと進化します。これはまた、Polarisチームにとってのリサーチツールとしても機能します。もっとも共通性のあるファクターについての情報を集めれば集めるほど、ファクターにより良く作用する基礎的な要素を当てはめることができるようになるのです。

「task repetition(反復タスク)」ファクターのページは、リテールとウェアハウスそれぞれのローカルシステムの枠を超えて発見と決断を集めています(Polarisサイトの内部テスト版のスクリーンショット)

これらのモジュール化された要素は、私たちのユーザーに対する理解が進むにつれて変化するでしょう。それはまた、業者の仕事の進め方について気をつけるべき条件が変わった場合には、私たちがその要素を置き換えることができるということでもあります。

このサイトは現時点では内部のユーザーのみのものですが、来年には外部向けにリリースする予定です。最終的には、内部のコンテンツと外部のコンテンツ、そして私たちのパートナーと外部のオーディエンス両方のためのリソースをもつPolarisの1つのサイトをつくろうと思っています。

Shopifyが成長するにつれて、Polarisチームの役割もまた変わってきました。Polarisチームはかつて、管理する側の体験における深い知見を頼りにしていました。スコープを広げることで、私たちはもはや、自分自身の深い知識にのみ頼らなくてもよくなったのです。横方向に展開して考え、誰もが利益を享受できるように、他のチームが彼ら自身の深い考えを共有できるようにする必要があります。プロダクトチームには彼らのオーディエンスを特徴づけるものについて、また彼らのデザインが対象としているファクターのタイプについてよく理解しています。プロダクトチーム自体はこのことをよく考えていますが、他のチームにも横展開して考える必要があるのです。

私たちがしている仕事の多くは、ローカルシステムを扱うヒントになるようなユーザーからの発見を見出せるようにチームを導き、相互の繋がりをみつけ出すためのものです。

このように言うと、あなたが使い慣れているデザインシステムとはかなり違っているように思えるかもしれません。間違えないでほしいのですが、私たちが取り組んでいる基礎的なコンポーネントはいまだに重要であり、一層の進化を必要としているのです。私たちは現在、ビジュアルの基盤を導入するための大きな一歩であった、テーマ別のカラーシステムをつくっています。しかしこの体験の基盤があれば、私たちが基盤となるものの進化のためにどのように時間を使えばいいのかがわかりやすくなります。

可視性が向上すれば、私たちはパターンをみつけやすくなります。そうすれば、思考をネットワークで繋ぐことができ、重複を減らすことができるので、確信をもって基盤を進化させることができるようになるのです。

道路を舗装し直すのにはお金がかかります。繰り返し舗装し、舗装し直すことは短期的には前に進んでいるように思われがちですが(その間システムチームは働き詰めです)、実際にはユーザー体験をしっかりと向上させることの方が時間がかかるということを忘れないようにしています。ユーザーが抱えている問題をしっかり理解すれば、私たちは正しい道を舗装して進むことができるでしょう。

イラストレーション:Sara Hill


Welcome to UX MILK

UX MILKはより良いサービスやプロダクトを作りたい人のためのメディアです。

このサイトについて