Razorpay: デザインシステムでFigmaの採用を増やして、デザインと開発チームのコラボレーションを促進

Razorpayは、 インドで急速に拡大している大手の金融サービス会社で、1,000万社にサービスを提供しています。このQ&Aでは、同社のデザインシステムチームに、以下について尋ねました。

• 同社のデザインシステムでの採用と測定の方法
• デザインと開発のコラボレーションにどのような課題があったか
• チームのワークフローを改善するために、開発モードとプライベートプラグインをどのように使用したか
• 生産性とデザインシステム採用に与えたFigmaの影響

チームとプラットフォームの構成は?

Soniさん: 当社には約70人のデザイナーと100人のフロントエンド開発者がおり、そのうちデザイナー3人とエンジニア5人がデザインシステムに専念しています。

Kamleshさん: 当社の製品提供は、ウェブ(デスクトップとモバイルウェブ)や、iOSとAndroidのアプリなどからです。同じAPIと同じプロパティセットを使用し、クロスプラットフォームで機能する単独のデザインシステムがあります。開発者がウェブからモバイルアプリに開発を切り替えた場合でも、ウェブコードの知識をモバイルアプリに活かす持ことができます。プラットフォームごとの再構築に時間を費やしたくないため、このアプローチを採用しました。

御社のデザインシステムについて、それが重要な理由もお聞かせください。

Soniさん: BladeがRazorpayのデザインシステムです。これを導入する前、チームはさまざまボタン状態や、テキストフィールド内のエラーの処理方法など、多くのと小さなニュアンスを簡単に見落としていました。ハードコード化してすべてをカスタムにしようとしていました。そうすることで、何かを誤って見逃していたかもしれません。

その結果、その場しのぎの繰り返しの多い開発作業が多くなり、カスタマーエクスペリエンスも良くありませんでした。これは、弊社の製品のように、企業が自社の資金を託す製品には重要なことです。スムーズな製品エクスペリエンスは、信用を築くのに役立ちます。

また、Razorpayのブランドは、さまざまなドメインで複数の製品により作られています。自社の製品全体でユーザーインターフェースを統一することが必要です。デザインシステムと共通言語があることで、それが最初から迅速にできます。また、すべてのユーザーがBladeのすべてのコンポーネントにアクセスできます。

Kamleshさん: 私たちはデザインシステムの仕事をしているので、エンドユーザーだけでなく、開発者とデザイナーも私たちの顧客になります。Bladeでは、だれもが同じ言語で意思疎通するため、チーム間の摩擦が減り、市場投入までの時間が短縮されます。私たちはデザインで表されたものをコードで得られるように構築してきました。

あなたのチームはBladeをどのような方法で採用したのですか?

Kamleshさん: これは、どんなプラットフォームツールでもやっかいな点です。採用を奨励し、摩擦を減らすため、いくつもの措置を講じました。

• 経営陣の賛同を得ること: 立ち上げからチームの予算獲得、チームでBlade採用を促進するまで、経営陣に影響を与えて意向を揃えることは、デザインシステムの発展にとって不可欠です。
• 主要メトリクスの特定: Bladeにオンボードされたプロジェクトの数や、デザインシステムで構築されたアプリの割合など、社内のツールやスクリプトを使用して、質的メトリクスと量的メトリクスを追跡します。これにより、経営陣も私たちのチームも、進捗状況がわかりやすくなります。
• アクティブな消費者サポート: オフィスアワーを設けてあり、顧客が質問や問題を投稿できるSlackチャンネルが用意してあります。それが妥当な問題である場合は、コンシューマーチームがGHに問題を上げて、それを私たちのチームが判断します。顧客チームのデザイナーも含むアドボケートのグループも作られました。彼らはコンポーネントに関する意思決定を助け、各自のチーム内それを支持してくれます。
• 社内での説得: 新しいコンポーネントについて、デモビデオで知らせたり、コンポーネントステータスのページを更新しtたりします。これはどちらも、すでにデザインシステムにあるコンポーネントをコンシューマーチームに作成させないために役立ちます。

あなたのチームによる効果はどのように測っていますか?

Kamleshさん: 私たちが進むべき方向は、チームがFigmaとコードを使用して最小労力で、優れた最新のUIを出荷できることです。チームは出荷する製品の機能に注力し、他のことはデザインシステムに任せられます。ざっくり言うと、新しい機能はそのデザインの70%と既存の製品提供の50%にBladeを使用するというターゲットを設定しています。このKPIはデザインと開発で共有され、どちらのチームも一緒にそれを追求することに意欲的です。

しかし、実際のカバレッジはデザインフェーズで開始することがわかりました。デザインがデザインシステムのコンポーネントで構築されていなければ、開発者はそれをBladeで構築する必要があることがわかりません。これに対処するために、デザイナーにデザインシステムからどのくらい逸脱しているかを示すBlade Coverageプラグインを作成しました。デザイナーはこのプラグインを使用すると、ローンチのタイムラインをより正確に予想することができ、使用しているコンポーネントに関するフィードバックを早く得られるため、ハンドオフ時の摩擦が軽減します。

量的なメトリクスだけではデザインシステムの導入と効果を測れないため、社内アンケートやフォーカスグループも使用しています。これは、迅速な製品出荷や、ツール、ドキュメント、トレーニングセッションのチームによる利用体験にBladeが役立っているかどうか、デザイナーと開発者間の摩擦が本当に減っているかどうかといったことを理解しやすくしています。これはすべて、毎年確認しているネットプロモータースコアにつながっています。

Figmaのプライベートプラグインでデザインと開発の摩擦を解消

あなたのチームが開発モードを使い始める前のハンドオフとビルド中のコラボレーションはどうでしたか?

Kamleshさん: ハンドオフでは、開発者が各要素を調べて、そのプロパティを適切にコピーする必要がありました。でもそのやり方はあまり良くないし、面倒でした。開発者は適切なコンポーネントに当たるまで何度もクリックを続け、そのコンポーネントを特定して、プロパティを確認した後、同じものをコードに実装していました。

このような調査の非効率性に対処するため、開発者の1人がRazorSharpというプライベートプラグインを作成しました。このサイドプロジェクトは2～3ヵ月かかりました。これでデザインに対応するコードの生成を自動化でき、それ以降、開発者はコピーアンドペーストするだけでよくなりました。

このRazorSharpプラグインで開発者の摩擦の一部が解消しましたが、すべてではありませんでした。開発モードを使う前、Figmaのプラグインは、そのファイルの編集アクセス権がある場合にしか実行できませんでしたが、ほとんどの開発者には、その権限がありませんでした。つまり、デザイナーがFigmaファイルを渡すと、開発者がRazorSharpプラグインを実行するには、それを新しいファイルに複製するという追加の手順が必要だったのです。

開発モードでデザインシステムの導入を促進

バリアブルを含む開発モードは、この問題に対処するのにどのように役立ちましたか?

Kamleshさん: 検査の問題の大部分は解消されています。開発モードがリリースされたときに、開発モードプラグインとして実行するようにRazorSharpをアップデートしたので、開発者はコードの実装確認にファイルを編集するという作業に悩まされることなく、RazorSharpプラグインを使用できます。その機能がすでにあったので、わずか2日で開発モードに対応させることができました。

また、開発モードを使って各コンポーネントにStorybookリンクを埋め込んでいます。そうすることで、デザインシステムのユーザーはStorybookのコンポーネントのコードプレイグラウンドに簡単にアクセスできます。

現在、トークンをバリアブルに移行中です。まだ初期の段階ですが、開発者の働き方にいくつかの利点が見え始めています。

デザインからコードへのトークンのコピーをシームレスにできるようになりました。トークン名(surface/text/subtle)からスラッシュを削除する代わりに、開発者が使いやすい構造(surface.text.subtle)を割り当てることができます。また、スペーシングトークンをバリアブルにマッピングできるようになりました。これは、コンシューマーチームからいつも要望されていたことです。

ライトモードとダークモードは、両モードのデザインをゼロから作り直すことなくすぐに実装できます。以前にFigma上のBladeで直面していたもう1つの問題は、膨大なメモリ消費でした。原因は、各コンポーネントの複数のテーマ(決済/バンキング)ごとに複数のモード(ライト/ダーク)があることにありました。これにより、デザイン作業中のシステム動作が遅くなり、デザイナーの生産性が著しく低下しました。しかし、バリアブルの導入によってBladeを1つのテーマに合理化でき、デザイナーの生産性が大幅に向上しました。

Sauravさん: そのほかにもワークフロー改善に役立った機能がいくつかあります。VS Codeプラグインを使用することで、開発者はFigmaとコード間を切り替えながらもコンテキストを失うことなくコードを書くことができます。このボックスモデルは、開発者がFigma内部のコードに近いデザインを視覚化するのに役立ちます。変更の比較とバージョン履歴は、開発者がファイル変更の行われたタイミングをより明確に知る助けとなります。これらを使ってファイルの凍結やスコープの設定を行うことで、直前の変更によりタイムラインに間に合わなくなることを防止できます。

生産性の向上とデザインシステムの採用

このような変更はあなたのチームにどのような影響がありましたか?

Sauravさん: デザイナーと開発者にアンケートを実施した結果、80%の回答者がBladeデザインシステムを使用した場合、使用しない場合よりも生産性が上がったと感じると回答しました。開発モードは、デザインシステムに対する理解と採用を容易にするうえで大きな役割を果たしています。

Kamleshさん: まだ初期の段階で、すべての開発者が開発モードを試しているわけではありません。開発モードを使い始めた開発者は、デザインと開発の間の摩擦が減る、あるいは全体的な生産性が向上するといった点で、ワークフローの改善を実感しています。

Razorpayがデザインシステムをどのように構築し維持しているかについて詳しくは、GitHubのBladeデザインシステムを参照してください。Razorpay DesignとRazorpay Engineeringのブログでも、ベストプラクティスが紹介されています。Designブログや、GitHubのBladeデザインシステムもご覧ください。

コード生成用プライベートプラグインについて詳しくは、Figmaの開発者向けドキュメントをご覧ください。または、GitHub上のコード生成プラグインのサンプルを使用してください。