HN 日本語サマリー

← 一覧へ戻る
Web開発

Capra、Criblのデザインシステム

Capra, Cribl's Design System (cribl.io)

5 pointsby ilreb1 コメント

要約

スタートアップ企業Criblは、サードパーティのUIコンポーネントライブラリに依存していたが、デザインの不一致、アクセシビリティの問題、保守性の低下といった課題に直面した。これらの問題を解決するため、同社は自社でデザインシステム「Capra」を構築した。Capraは、デザイン標準、デザイントークン、そしてスタイルを持たないヘッドレスUIコンポーネントライブラリを基盤とし、アクセシビリティと一貫性を重視している。このシステムは、人間だけでなくAIエージェントも利用できるよう、Markdown形式でのドキュメント提供も行っている。

全文翻訳

Capra、Criblのデザインシステム もしかしたら、あなたもこの状況に遭遇したことがあるかもしれません。あなたはプロダクトマーケットフィットを見つけ、顧客を獲得するために迅速に動く必要がある若いスタートアップ企業です。あなたはフロントエンドを素早く構築するのに役立つサードパーティのUIコンポーネントライブラリを採用します。顧客は満足し、上司も満足し、エンジニアも満足します。すべてがうまくいきます…それがうまくいかなくなるまで。 ある日、コンポーネントライブラリがデザイン仕様に合うようにカスタムスタイルオーバーライドを追加するのに、時間の半分を費やしていることに気づきます。会社のデザイン言語は、ずっと前にコンポーネントライブラリが意図されていたものから離れてしまっています。あるいは、ライブラリが進化する顧客層が必要とするほどアクセシブルではなく、機能を追加するためにハックを実装しなければならないかもしれません。あるいは、ライブラリのトレードオフやAPIデザインが、もはやあなたの会社が必要とするものと一致しない、またはパターンやコンポーネントを再利用する必要性がライブラリの能力を超えているかもしれません。 これがまさに、私たちがCriblで見つけた状況です。 「なぜ」 前述したように、私たちはフロントエンドコードベースでかなりの困難に直面していました。私たちの製品の一部と他の部分との間に、顕著な視覚的および行動的な乖離が見られました。デザイナーがFigmaで使用し、エンジニアがコードで使用するための、連携のとれた再利用可能なビルディングブロックがないため、多くの新機能は独自のビジュアルトリートメントで構築され、開発は遅く非効率的になりました。コンポーネントは、どのチームやエンジニアが構築したかによって、プラットフォーム全体で異なる動作をしました。長年頼ってきたサードパーティのUIコンポーネントライブラリは、アクセラレーターというよりも負債になりつつありました。私たちの絶え間ないオーバーライドとハックは、コードベース、特にスタイリングをますます脆くしていました。 さらに大きな問題は、私たちのアプリケーションがアクセシビリティの観点からも顧客を失望させていたことでした。多くのインタラクションは、キーボードで部分的に、または完全に利用できませんでした。色のコントラスト、フォントサイズとウェイト、クリックターゲットのサイズは、許容範囲外でした。イベントハンドラーが非インタラクティブな要素にアタッチされていました。ブラウザのアクセシビリティツリー内の項目には、ラベルや説明テキストが欠けていました。私たちは顧客により良いサービスを提供する必要があることを知っていました。 私たちのアプリケーションの表面積も、過去数年間で劇的に変化しました。現在、同期が必要な複数のフロントエンドコードベースとデザイン標準があります。歴史的には、これは一致を保証するために、あるコードベースから別のコードベースへオーバーライドスタイルをコピー&ペーストすることを意味していました。Cribl Appsの登場により、私たちは内部製品と顧客のアプリの両方を、一貫したデザインとアクセシビリティを推進する単一の北極星に合わせる必要がありました。自社のデザインシステムを構築する時が来たのです。 「何」 デザインシステムは、UIコンポーネントのスイート以上のものです。それは、顧客とコミュニケーションするために使用するUXレパートリー全体です。通常、デザイントークンとしてエンコードされるデザイン標準は、製品がどのように見え、どのように感じられるかを定義します。フロントエンドコンポーネントライブラリは、製品を構築する方法について健全なガードレールを提供することで、それを強制します。これら両方の基盤にあるのは、すべての顧客層にサービスを提供するというコミットメントです。これは、カラーパレットからアニメーション速度、キーボードインタラクションまで、すべての決定にアクセシビリティを組み込むことを意味します。このエージェントプログラミングの現在の時代において、よく作られたデザインシステムは、人間とエージェントの両方にドキュメントとイネーブルメントを提供します。 デザインシステムは、UIコンポーネントのスイート以上のものです。それは、顧客とコミュニケーションするために使用するUXレパートリー全体です。通常、デザイントークンとしてエンコードされるデザイン標準は、アプリケーションがどのように見え、どのように感じられるかを定義します。フロントエンドコンポーネントライブラリは、製品を構築する方法について健全なガードレールを提供することで、それを強制します。これら両方の基盤にあるのは、すべての顧客層にサービスを提供するというコミットメントです。これは、カラーパレットやアニメーション速度からキーボードインタラクションまで、すべての決定にアクセシビリティを組み込むことを意味します。これは、エージェントプログラミングの時代には特に重要です。よく作られたデザインシステムは、人間とエージェントの両方にドキュメントとイネーブルメントを提供します。 「どのように」 CriblのPlatform UIチームは、私たちのデザイン標準から始め、デザインチームと協力してUXの最終状態を定義しました。これには、ユーザーエクスペリエンスのすべての側面を再評価する必要がありました。この作業から生まれたいくつかの変更には、新しいカラーパレット、色のセマンティックな使用の再調整、そして本質的にアクセシブルではなかった既存のパターンやインタラクションの削除が含まれます。これらの新しく刷新されたデザイン標準は、Figmaとドキュメントサイトで文書化され、最新のデザイントークンコミュニティグループ仕様を使用して、標準の(色、スペーシング、タイポグラフィなど)ナッツとボルトをエンコードしました。私たちのデザイントークンは、現在Figmaとコンポーネントの両方の真実の源として機能し、優れたStyle Dictionaryライブラリを使用して再配布されています。次のステップは、コードでこれらのデザイントークンを利用することでした。問題空間でいくつかのオプションを評価した後、私たちは、バトルテスト済みの、アクセシビリティファーストのヘッドレスUIコンポーネントライブラリであるReact Aria Componentsを基盤として選択しました。オフザシェルフのライブラリを使用することは、前述のペインポイントを考慮すると直感に反するように思えるかもしれませんが、いくつかの重要な違いがあります。React Aria Componentsはスタイルなしで出荷されるため、デフォルトスタイルを調整したりオーバーライドしたりすることなく、必要に応じてルックアンドフィールをカスタマイズできます。また、ライブラリを実装の詳細として扱い、公開APIに直接公開しません。その後、カスタムスタイルと追加の動作をReact Aria Componentsの上にレイヤー化しました。これにより、リッチでインタラクティブなエクスペリエンスをすべての顧客に提供しながら、特定のニーズに合わせたコンポーネントが実現しました。 最後のステップは、デザインシステムを効果的に使用できるように文書化することでした。私たちはStorybookを使用しており、コンポーネントのドキュメントと「ストーリー」(コンポーネントの動作のライブ例)を共配置しています。これは人間にはうまくいきましたが、Storybookのほとんどの機能はブラウザでのJavaScriptを必要とするため、エージェントがStorybookを効果的に消費できないことがわかりました。これを解決するために、StorybookのすべてのコンテンツをプレーンMarkdownに変換するカスタムレンダリングパイプラインを作成し、ドキュメントサイトの/llms.txtルート経由で公開しました。さらに、公開パッケージにもプレーンテキストドキュメントを埋め込みました。これにより、人間であれLLMであれ、デザインシステムのドキュメントは必要な場所にすぐに利用できるようになります。 Capraの構築の「どのように」には、さらに多くの詳細があり、将来のブログ投稿でそれらを掘り下げていきます。乞うご期待。 うまくいっていますか? 私たちはまだ製品全体にCapraを完全に展開している最中です。ご想像のとおり、長年のサードパーティライブラリの技術的負債を置き換えるには時間がかかります。しかし、すでに顕著な進歩が見られています。移行を追跡する社内ダッシュボードでは、すでに25%を超えています。この執筆中に、より多くの作業が計画されています。 私たちは多くの教訓を学びましたし、これからも学び続けるでしょう。特に注目すべき教訓の1つは、コンポーネントを最終状態にするのと、実用的な中間点を見つけるとの間の適切なバランスを見つけることでした。以前のサードパーティライブラリと比較して、初期段階で視覚的にもAPI契約においても、あまりにも多くの変更を導入しました。例えば、新しいテキスト入力は当初、異なる境界線/背景色のスキームを使用していましたが、まだ移行されていない古いテキスト入力の隣に画面に表示されたときに奇妙に見えました。これは意図されたものでしたが、エンジニアがCapraに迅速かつ安全に移行できるようにするという目標を達成できませんでした。私たちは一歩後退し、コンポーネントの構築方法を調整し、採用へのより段階的なステップを提供しました。 CapraがCribl Appsで使用されているのを見るのもエキサイティングです。当初、パッケージはプライベートで公開していましたが、その後CapraをNPMに移行したため、顧客はCriblのデザイン美学と動作に一致するアプリを構築できるようになりました。ダウンロード数は増加し続けており、お客様がどのようなアプリを構築するかを見るのが待ちきれません! 次は何? 私たちは引き続き構築していきます