広く提案し、絞って届ける
課題
PariPassuでは、2人のデザイナーのうちの1人として2つの製品を担当しながら、RastreadorとCliCQを横断するエッジケースを先回りしようと、チームが実際に必要とするより広い新コンポーネント群を提案した。数週間のうちに、その一部のバリアントが一度も触れられていないことが明らかになった。実利のない認知負荷を増やし、肥大感によって採用が遅れた。
試したこと
私のアプローチは完全主義的だった。「すべてのユースケースを先回りして一気に作ろう」。デザインシンキングのワークショップ、過去のテンプレート、より大きな会社の成熟したDSパターンを基に、多数のボタン状態、カードのバリアント、入力タイプ、エッジケースをマッピングした。
なぜ失敗したか
前提が誤っていた。PariPassuはトレーサビリティと品質検査を提供する、動きの速いフードテックだった。実際の短期的なニーズは、私が設計した量のごく一部だった。「CardStandard、CardCompact、CardMinimalのどれを使うべき?」。実際の問題を解決する代わりに、現在の需要を検証せずに仮想的な未来のために設計していた。
学び
デザインシステムは製品とともに育つもので、製品に先行するものではない。より大きな会社で見てきた最良のDS（Bridge、Multidrop）は1日目に完成していなかった。小さく始まり、実利用からパターンが浮かび上がるにつれてスケールしていった。スリムに保つことは次を意味した: (1) エンジニアはすべてを使うので、すべてのコンポーネントを理解していた。(2) 反復が速くなり、決定が少なく、PRが速くなった。(3) 新しいパターンが現れたとき、意図的に追加した。
結果
もう1人のデザイナーと一緒に、チームが実際に使っていたコンポーネントに提案を絞り込み、それらに焦点を当てたドキュメントを維持し、デベロッパーとペアでトークンを調整した。協働での剪定により採用が容易になり、新コンポーネントは実利用が要求した場合にのみ追加されるようになった。
インパクト
デザインからエンジニアリングへのハンドオフが速くなり、意思決定の麻痺が減り、私が思うあるべき姿ではなく、製品が実際に構築されていく姿を反映するシステムになった。