Razorpay社のデザインシステムチームは、ユーザーエクスペリエンスの一貫性と直感的な使いやすさを維持しながら、複数のプラットフォームで複数の製品をサポートすることを狙いとして、Bladeを開発しました。
Razorpay社の開発者ワークフロー改善の事例を共有
インド最大かつ最も急成長している金融サービス企業の1つであるRazorpay社は、1000万の企業にサービスを提供しています。同社のデザインシステムであるBladeは、デザインチームと開発チームの協力の下で会社の規模拡大に合わせたスムーズな構築を可能にしています。ここでは、採用と評価のアプローチ、共同作業の課題への対処、開発者の作業を効率化するプライベートプラグインについて、Razorpay社のデザインシステムチームにお話を聞きました。
チームとプラットフォームはどのように構成されていますか?
当社には約70人のデザイナーと100人のフロントエンド開発者がおり、そのうちデザイナー3人とエンジニア5人がデザインシステムに専念しています。
私たちは、デスクトップ用とモバイル用のウェブ、iOSおよびAndroidアプリなどを使用しています。当社のデザインシステムBladeは、この1つのシステムが同じAPIと同じプロパティセットを使用してクロスプラットフォームで動作します。開発者がウェブ担当からモバイルアプリ担当に変わった場合でも、ウェブコードの知識をモバイルアプリに活かすことができます。プラットフォームごとの再構築に時間を費やしたくないことから、このアプローチを採用しました。
このデザインシステムでどのような問題を解決できましたか?
Bladeを導入する前は、さまざまなボタンの状態やテキストフィールド内のエラーの処理方法など、多くの細かな違いを見逃しがちでした。全てをハードコーディングしてカスタム仕様で構築しようとしたため、誤って何かを見落としてしまう可能性がありました。その場しのぎの反復的な開発作業が多く、カスタマーエクスペリエンスが低下しました。これは、企業にお金を預けていただく当社にとって見逃せないことです。製品のスムーズな利用体験はその信頼を確立するのに役立ちます。
また、Razorpay社は複数の商品を異なるドメインにまたがって提供しているため、商品とドメイン間でユーザーエクスペリエンスを確実に統一させる必要があります。1つのデザインシステムと共有言語を使用することで、このゼロからの構築を迅速に行うことができます。また、全ユーザーがBladeの全てのコンポーネントにフルアクセスできるようにもなります。
私たちはデザインシステムに携わっているため、Razorpay社の開発者やデザイナー、さらにはエンドユーザーが顧客ということになります。Bladeを使用することで全員が同じ言語で話せるようになるため、チーム間の摩擦が減り、市場投入までの時間が短縮されます。また、デザインとして見えるものをコードにすることができます。
あなたのチームはデザインシステムの採用にどのようにアプローチしましたか?
どのようなプラットフォームツールでもこれが最も難しい部分です。採用を奨励し、摩擦を減らすため、いくつもの措置を講じました。
- 経営陣の賛同を得ること: 経営陣に影響を与え、意向を揃えることは、立ち上げからチームの予算獲得、アドボケートが各自のチームでBlade採用を推進するまで、どの段階でも重要です。
- 主要メトリクスの特定: Bladeにオンボードされたプロジェクトの数やデザインシステムのコンポーネントで構築されたアプリの割合など、定性的および定量的なメトリクスを社内のツールとスクリプトを使用して追跡します。これにより、経営陣と作業グループが進捗状況を追跡しやすくなります。
- 消費者のサポート: 業務の一環として、顧客が質問や問題を投稿できるSlackチャネルを監視する時間を設けています。また、Bladeを使用するチームのデザイナーを含むアドボケートのグループを結成しました。彼らはコンポーネントに関する決定の助けとなるだけでなく、各自のチームでの導入を後押ししてくれます。
- 組織内の伝達: 新しいコンポーネントは、デモ動画とコンポーネントステータスの更新ページで発表しています。
チームの影響をどのように計測していますか?
私たちのNorth Star Metric (北極星指標) は、チームがモダンかつエレガントなUIをリリースし、それ以外についてはデザインシステムが処理できるようにすることです。新機能を構築するチームのデザイン作業の70％でBladeを使用することを目標としていますが、既存の商品に対してはこの目標を50％に変えています。このKPIはデザインチームと開発チームで共有されており、双方が協力してこれを目指しています。
私たちのNorth Star Metricは、チームがモダンかつエレガントなUIをリリースし、それ以外についてはデザインシステムが処理できるようにすることです。
しかし、私たちが学んだことは、実際のカバレッジはデザインフェーズから始まるということです。デザインがBladeのコンポーネントで構築されていなければ、開発者にもそれを使用する必要があることがわかりません。これに対処するため、デザインシステムからどれだけ逸脱しているかを示すBlade Coverageプラグインを作成しました。このプラグインを使用することで、デザイナーは自分のローンチスケジュールをより正確に予測することができ、使用しているコンポーネントに関するフィードバックを早期に受け取ることでハンドオフ時の摩擦を減らすことができます。
定量的なメトリクスだけではデザインシステムの採用状況と影響を完全に捉えることができないため、内部調査やフォーカスグループも行っています。これらのより定性的な指標は、Bladeを使用するとより早くリリースできるとチームが感じているかどうかや、ユーザーエクスペリエンス、ドキュメンテーション、トレーニングセッション、デザイナーと開発者の間のコラボレーションに関するフィードバックなど、感情面を理解するのに役立ちます。これら全てが毎年確認しているネットプロモータースコアにつながっています。
チームが開発モードを使い始める前のハンドオフやビルド中のコラボレーションはどのようなものでしたか?
ハンドオフでは、開発者が各要素を検査してプロパティを適切にコピーすることが期待されます。従来のやり方は理想的ではありませんでした。開発者は正しいコンポーネントに偶然たどり着くまでひたすらクリックし、コンポーネントを特定してそのプロパティを確認し、それと同じものをコードに実装していました。
そのような検査の非効率性に対処するために、私たちの開発者の1人がRazorSharpというプライベートプラグインを作成しました。作成はサイドプロジェクトとして行い、2〜3か月かかりました。プラグインによってデザインと同等のコードを自動生成できるようになり、それ以降、開発者は単純にコピー & ペーストするだけになりました。
RazorSharpプラグインによっていくつかの課題が解消されましたが、全てではありませんでした。開発モードを使用する前は、Figmaのプラグインを実行できるのはファイルの編集アクセス権がある場合のみでしたが、ほとんどの開発者にはその権限がありませんでした。つまり、デザイナーが開発者にFigmaファイルを渡しても、開発者がそれを新規ファイルに複製する追加作業を行わないとRazorSharpプラグインを実行できなかったのです。
そのような課題にどのように対処したのですか?
現在は、検査の問題の大部分は解消されています。Figmaが開発モードをリリースしたとき、RazorSharpを開発モードプラグインとして実行するように変更しました。これにより、開発者は実行コードを確認するためにファイルを編集するという作業に悩まされることなくRazorSharpプラグインを使用できます。機能は既に存在していたため、わずか2日で開発モードに対応させることができました。
また、開発モードを使って各コンポーネントにStorybookリンクを埋め込んでいます。そうすることで、デザインシステムのユーザーはStorybookのコンポーネントのコードプレイグラウンドに簡単にアクセスできます。
現在、トークンをバリアブルに移行するプロセスを進めています。まだ初期段階ですが、開発者の作業方法にいくつかの利点が見え始めています。
デザインからコードへのトークンのコピーをシームレスに行えるようになりました。トークン名(surface/text/subtle)からスラッシュを削除する代わりに、開発者が使いやすい構造(surface.text.subtle)を割り当てることができます。また、スペーシングトークンをバリアブルにマッピングできるようになりました。これはユーザーチームから再三要望されていたことです。
ライトモードとダークモードは、両モードのデザインをゼロから作り直すことなくすぐに実装できます。以前にFigma上のBladeで直面していたもう1つの問題は、膨大なメモリ消費でした。原因は、各コンポーネントの複数のテーマ(決済/バンキング)ごとに複数のモード(ライト/ダーク)が必要になることにありました。デザイン作業中のシステム動作が遅くなり、デザイナーの生産性が著しく低下しました。しかし、バリアブルの導入によってBladeを1つのテーマに合理化でき、デザイナーの生産性が大幅に向上しました。
そのほかにもワークフロー改善に役立った機能がいくつかあります。VS Codeプラグインを使用することで、開発者はFigmaとコード間を切り替えながらもコンテキストを失うことなくコードを書くことができます。ボックスモデルは、開発者がFigma内部のコードに近いデザインを視覚化するのに役立ちます。変更の比較とバージョン履歴は、開発者がファイルが変更されたタイミングをより明確に知る助けとなります。これらを使ってファイルの凍結やスコープの設定を行うことで、直前の変更によるタイムラインの見落としを防ぐことができます。
これらの変更は、生産性とデザインシステムの採用にどのような影響を与えましたか?
デザイナーと開発者にアンケートを実施した結果、80%がBladeデザインシステムを使用した方が生産性が上がったと感じると回答しました。開発モードは、デザインシステムに対する理解と採用を容易にするうえで大きな役割を果たしています。
開発モードを使い始めた開発者は、デザインと開発の間の摩擦が減る、あるいは全体的な生産性が向上するといった点で、ワークフローの改善を実感しています。
コード生成用プライベートプラグインについて詳しく知りたい場合は、Figmaの開発者向けドキュメントをご覧いただくか、GitHub上のコード生成プラグインのサンプルを使用してください。