プロダクトとUI/UXデザイン · リード（6年以上）

デザインシステムリードの履歴書

このサンプルでは、デザインシステムリードがトークン、コンポーネント、ガバナンスをプロダクトチームの日々の業務につなげる方法を紹介します。この職種の履歴書では、システムの導入状況、アクセシビリティに関する判断、デザインやエンジニアリングの業務フローにおける測定可能な改善を明確に示すことが大切です。

履歴書チェック

採用担当者や応募者追跡システムが確認する項目をチェックできます。目安であり、結果を予測するものではありません。

95 / 100十分です

95%
  • 連絡先15 / 20 点
  • 職務要約20 / 20 点
  • 職歴30 / 30 点
  • スキル20 / 20 点
  • 学歴10 / 10 点

改善できる項目が1件あります

連絡先

採用担当者や応募者追跡システムが最初に確認するため、これらの情報を上部に記載してください。

任意です。米国、英国、カナダでは通常、履歴書に写真を載せません。

79語

職歴は1段落に1件ずつ記載し、実績ごとに新しい行を使って「-」で始めてください。

10件のスキル

スキルをカンマで区切って入力してください（例：Excel、SQL、プロジェクト計画）。

その他のセクション

応募に役立つプロジェクト、資格、語学、その他の情報を追加できます。

ツール
システムガバナンス

アレックス・モーガン

デザインシステムリード

  • アレックス・モーガン＠イグザンプル・ドットコム
  • +1 555 0100
  • Denver, CO

職務要約

B2B SaaSのプロダクトチームで7年間の経験を持つ、デザインシステムリードです。アクセシブルなトークンとコンポーネントの基盤を構築し、貢献の進め方を整え、デザイナーやエンジニアが一貫性のあるインターフェースをリリースできるよう改善してきました。Figma、Storybook、Reactを使った連携に精通し、複数の製品領域で実用的な導入を進めてきました。

職歴

Redstone Product Studio、デザインシステムリード、Denver, CO（2022 – 現在） - デザインとエンジニアリングのチームと共通トークンおよびコンポーネントの貢献ルールを定義し、4つのプロダクトチームで共通のリリースプロセスを導入しました。 - Reactエンジニアと38個の再利用可能なStorybookコンポーネントを構築、文書化し、3つのWeb製品で重複していたインターフェースパターンを減らしました。 - 主要コンポーネントをWCAG 2.2 AAの基準に照らして監査し、プロダクトチームと修正状況を追跡しました。2回のリリースで優先度の高いアクセシビリティ上の問題を21件解決しました。 Juniper Ridge Digital、シニアプロダクトデザイナー、Boulder, CO（2019 – 2022） - 2つのプロダクトチームのFigmaライブラリと命名規則を標準化し、プロジェクトごとに発生していたコンポーネントの重複設定を約3時間分削減しました。 - エンジニアと連携してインタラクションの状態と引き継ぎ要件を文書化し、スプリントごとに約6件あった繰り返しのデザイン確認依頼を3件に減らしました。

学歴

コミュニケーションデザイン美術学士 — Mesa Creek College、Fort Collins, CO（2018）

スキル

  • デザインシステム
  • デザイントークン
  • Figma Variables
  • コンポーネントライブラリ
  • Storybook
  • Reactを使った連携
  • WCAG 2.2 AA
  • アクセシビリティ監査
  • デザイン文書
  • システムガバナンス

ツール

• Figma、Figma Variables • Storybook、React • zeroheight、Jira

システムガバナンス

• コンポーネントの貢献・レビューのプロセス • リリースノートと導入状況の追跡

デザインシステムリードの履歴書の書き方

システムの対象範囲を最初に示します

現在のデザインシステム関連の職務を最初に記載し、対象範囲をわかりやすく示します。対応した製品領域、支援したチーム、対象プラットフォーム、戦略と実行のどちらを担当したかを記載します。協力したデザインやエンジニアリングの担当者も明記します。組織全体のチームが実際に利用し、保守していない限り、ライブラリを「全社規模」と表現するのは避けます。

導入状況と成果を示します

コンポーネントの統合、重複パターンの解消、実装時間の短縮、アクセシビリティ上の問題の修正、チームの導入など、取り組みとプロダクトチームへの効果を説明します。説明できる数値を使い、必要に応じて期間や対象範囲も記載します。コンポーネントの数だけでは伝わりにくいため、利用状況、保守性、製品の業務フローの改善と関連付けます。

アクセシビリティ対応を説明します

WCAG 2.2 AAなど、使用したWCAGのバージョンと適合レベルを示し、キーボード操作、フォーカス状態、コントラスト、テスト、問題の修正など、実施した作業を記載します。一部のコンポーネントを監査しただけで、システム全体が完全に適合していると主張するのは避けます。広範な適合の主張より、対象範囲、手法、監査後の対応を明確に説明するほうが評価される場合があります。

ツールとガバナンスを明確にします

トークンにFigma Variables、コンポーネントの文書化やレビューにStorybookを使った場合など、ツールの用途もあわせて記載します。判断の理由、貢献モデル、導入事例を伝えられる場合は、ポートフォリオや文書へのリンクを追加し、機密性のある製品情報は削除します。この職種に標準的な資格はないため、関連性のない資格の記載は控え、システムに関する経験を記載します。

よく使われるキーワード

この職種でよく挙げられるスキルやツールです。自分が持っているものだけを、求人広告の表記に合わせて使いましょう。クリックするとコピーできます。

アクション動詞

定義しました構築しました標準化しました文書化しました監査しました削減しました立ち上げました

この職種についての質問

デザインシステムリードの履歴書は何ページが適切ですか？

関連する経験が数年あり、システムの対象範囲、チームへの影響、成果を示せる場合は、2ページでも適切です。最も関連性の高いデザインシステムの経験を1ページ目にまとめ、応募職種に結び付かない古いプロダクトデザインの詳細は整理します。経験が比較的短く、事例を具体的に示せるなら、1ページでも問題ありません。

ポートフォリオやデザインシステムのリンクを載せるべきですか？

自身の仕事がよく伝わり、共有の許可を得ている場合は載せるとよいでしょう。公開コンポーネントライブラリ、事例、情報を伏せたガバナンスの例を通じて、判断の進め方や導入の支援方法を示せます。デザインシステムはチームで構築することが多いため、自分が担当した内容を説明します。機密性のあるインターフェース、ロードマップの詳細、社内文書は公開しないでください。

どのアクセシビリティ規格を記載すべきですか？

実際に使用した規格とレベルを、WCAG 2.2 AAなどの形で示し、適用例も記載します。業務でそのレベルに対応しておらず、対象範囲も明確でない場合は、一般的な履歴書キーワードとして「WCAG AAA」と記載しないでください。要件やテスト方法は、雇用主、製品、適用される規制によって異なります。実施した手法と、確認したコンポーネントやフローを説明します。

デザインシステムリードになるには資格が必要ですか？

米国では、この職種に必須となる特定の免許や資格はありません。雇用主は通常、デザインシステムの実務経験、エンジニアリングチームとの協力、アクセシビリティの知識、導入実績を評価します。資格を記載する場合は、応募職種に関連するものを選び、発行機関と資格名を正確に記します。実務経験の説明の代わりに資格を使わないでください。