UX オペレーション
このページには、GitLab の UX 部門で働くための運用情報が記載されています。
ヘッドカウント計画
UX チームメンバーは、Product Management および Engineering 全体の安定したカウンターパートと協力して働きます。アライメントのモデルは、職種や作業の種類によって異なります。
プロダクトデザイン
プロダクトデザイナーは、主に次の2つのモデルのいずれかで働きます。
- ステージグループアライメント: ステージグループに割り当てられたデザイナーは、特定の製品領域について専任の PM および Engineering チームと協業します
- プロジェクトベースの業務: デザイナーは、複数のグループにまたがる、または独立して運営される横断的なプラットフォームイニシアチブ（デザインシステム、ナビゲーション、戦略的プロジェクト）に取り組みます
ステージアライン型ロールの計画比率:
- プロダクトデザイナー対 PM = 1:1
- フロントエンドエンジニア 1〜3名に対してプロダクトデザイナー 1名。4〜5名に対して 2名
UX リサーチ
UX リサーチャーはセクション内の複数グループをサポートします。
- UX リサーチャー対プロダクトマネージャー比率 = 1:5
- UX リサーチャー対エンジニア比率 = 約 1:35
テクニカルライティング
テクニカルライターはそれぞれ複数のステージグループをサポートします。
- テクニカルライター対ステージグループ比率 = 1:3
- テクニカルライター対エンジニア比率 = 約 1:21
デザインシステム
デザインシステムチームは独立して運営されており、すべてのプロダクトデザイナー、エンジニア、テクニカルライターに役立つプラットフォーム全体のインフラを構築しています。このチームは、特定のステージグループや PM には割り当てられていません。
マネジメント
各機能に応じて、マネージャーのサポート体制が適切に整えられています。
- UX リサーチおよびプロダクトデザインの場合、マネージャー対直接の部下比率 = 約 1:5
- テクニカルライティングの場合、マネージャー対直接の部下比率 = 約 1:7
調達リクエスト
新規プロダクト／サービスをリクエストするには、UX 調達提案 Issue テンプレートを使用して Issue を作成してください。マネージャーが UX リーダーシップと協力して支出ニーズを特定し、FP&A と連携して予算を確保した後、ベンダーライフサイクルに従います。
UX ラベル
GitLab では、ラベルを使用して作業を分類、優先順位付け、追跡しています。以下は、UX ワークフローに最も直接関連するラベルの内訳です。すべてのラベルの種類と用途の概要は、contributing doc を参照してください。
UX ラベル: この Issue で UX 作業が必要であることを示します。これらの Issue は、新機能、改善のアイデア、または UX が専門知識を提供すべきその他のものになります。
Inclusion ラベル: 私たちの多様性バリューに関連して、包摂を促進する GitLab への変更。
Inclusive design ラベル: よりアクセシブルな体験につながるコンテンツへのアクセス、操作、貢献のさまざまな方法を検討、探求、評価します。
Accessibility および scoped accessibility ラベル は、アクセシビリティへの影響がある Issue を特定するために使用されます。scoped ラベルは、アクセシビリティ監査によって影響が検証された後に追加し、priority および severity ラベルと組み合わせて Issue をトリアージするために使用してください。
- Accessibility ラベル: アクセシブルなプロダクト体験の作成に役立つ実行可能な項目を含む Issue。
- Accessibility-audit ラベル: アクセシビリティ関連の改善の可能性を理解するために既存の体験を監査することに関連する Issue。
- Accessibility-ops ラベル: 内部ワークフローにアクセシビリティを組み込むことに関連する Issue。
accessibility::critical: 一部または全部のユーザーが、回避策なしで重要なタスクを実行できなくなります。accessibility::high: 一部のユーザーが重要なタスクを実行できなくなります。回避策が存在する可能性はありますが、不満や非効率を生み出します。accessibility::medium: 一部のユーザーが重要でないタスクを実行できなくなる、または特定の支援技術を使用するユーザーのユーザーエクスペリエンスが著しく低下します。accessibility::low: 特定の障害を持つユーザーや、特定の支援技術を使用するユーザーのユーザーエクスペリエンスは低下しますが、ユーザーはタスクを完了できます。
learnability ラベル: ユーザーが GitLab の機能にすばやく慣れるのを助けることで、学習しやすさの問題に対処する Issue。
Scoped workflow ラベル は、Product Development Flow からのもので、Issue が開発ライフサイクルのどこにあるかを示すために使用されるべきです。Issue は必要な回数だけワークフローラベル間を移動でき、すべてのラベルがすべての Issue に適用されるわけではありません。UX を必要とする Issue には、Product Development Flow で定義された次のいずれかのラベルを使用します。
workflow::validation backlogworkflow::problem validationworkflow::designworkflow::solution validation
Pajamas コンポーネントライフサイクルラベル は、Pajamas コンポーネントを作成・更新するために使用される scoped ラベルです。ラベルの使用ガイドラインは Pajamas コンポーネントライフサイクルドキュメント を参照してください。
UX problem validation ラベル: Issue が、ユーザーに関連する問題であることを検証するために UX 作業を必要としていることを示します。このラベルは Product Development Flow の scoped ラベルに加えて使用し、UX パフォーマンス指標 で経時的に検証努力を追跡できるようにします。
UX solution validation ラベル: Issue が、提案された解決策が技術的に実行可能でユーザーニーズを満たしていることを検証するためのタスクを必要としていることを示します。このラベルは Product Development Flow の scoped ラベルに加えて使用し、UX パフォーマンス指標 で経時的に検証努力を追跡できるようにします。
UI polish ラベル: 既存のユーザーインターフェースへの視覚的改善のみを扱う Issue であることを示します。
Deferred UX ラベル: Deferred UX は、UX ビジョンや MVC から意図的に逸脱する決定によって生じ、ユーザー体験を犠牲にするものです。Deferred UX のラベルが付いた Issue は、後続のリリースに含まれる必要があります。次のいずれかを満たさないリリース UX を示すためにこのラベルを使用してください。
- UX および Pajamas の仕様
- ユーザビリティ基準
- 機能の実現可能性基準
このラベルは、UX ギャップに対処するフォローアップ Issue に適用されます。Deferred UX を作成した Issue やマージリクエストには適用されません。たとえば、合意された MVC のデザインソリューションが、リリースのプレッシャーや実装の見落としにより完全には実現されない場合、それは Deferred UX と見なされます。
デザインが正しく実装されているのに予期しない UX 問題が特定された場合、それは Deferred UX とは見なされません。
このラベルをいつ適用するか迷う場合は、次のルールを使用してください。「この UX 問題は Issue やマージリクエストから生じたものではない」と言える場合は、それは単に UX であり、Deferred UX ではありません。Deferred UX を含む MVC を出荷する決定をチームが行った場合、変更がリリースされ次第、追跡するための Issue を作成することが推奨されます。
System Usability Scale (SUS) ラベル: Issue が、SUS リサーチ活動のいずれかで明らかになったユーザビリティ問題に関連していることを示します。より具体的には、優先順位が付けられた SUS 関連の Issue は、対応する会計年度と四半期でラベル付けできます。例:
SUS::FY22 Q2 - Incomplete。 SUS スコアを UX 部門のパフォーマンス指標として詳しく知るRegression ラベル: 最新のリリースで導入された、正しい動作を破壊するバグを示します（詳細は 貢献ガイドライン を参照）。
UX scorecard ラベル: UX Scorecard のメイン Issue またはエピックを示します。このラベルを使用して、現在の作業を簡単に見つけ、経時的に活動を追跡できるようにしています。
UX scorecard-rec ラベル: この Issue が UX scorecard レビューの結果として生まれた推奨事項であることを示します。スコアカードが行われる前に Issue が作成されていても問題ありません。それでも推奨事項のセットに引き入れることができます。
cm-scorecard-rec ラベル: この Issue が CM スコアカードの結果として生まれた推奨事項であることを示します。
Actionable Insights は、対処する必要があるリサーチからの学びを文書化します。
- Actionable Insight::Exploration needed: さらなる探求を必要とする UX リサーチ研究から得られたリサーチインサイト。
- Actionable Insight::Product change: UX リサーチ研究から得られ、プロダクト体験への変更を必要とするリサーチインサイト。
Type ラベル: feature、maintenance、bug の Issue や MR を追跡するために使用されます。UX リーダーシップは、これら 3 つの作業タイプすべての優先順位付けに影響を与える積極的な参加者です。機能、メンテナンス、バグの優先順位付け DRI も参照してください。
Theme ラベル は、同じユーザー体験の問題を解決するもののどのカテゴリーにも属さない Issue をグループ化するために作成できます。これは、プロダクト全体にまたがるユーザー体験に対して特に役立ちます。これらの Issue にも UX ラベルが必要です。
UX: Feature Discovery Improvement: Issue が機能の発見可能性を向上させる可能性があることを示します。
UX: Onboarding Improvement: Issue が潜在的なオンボーディング改善であることを示します。
UX カレンダー
UX カレンダー（社内限定）は、私たちのチームミーティングの SSOT です。UX 通話、UX フォーラム、その他のチームミーティングの詳細をここで見つけることができます。これらのミーティングは GitLab の誰にでも開かれています。UX 部門の誰でも Google カレンダーにイベントを追加できます。マネージャー以上は変更や共有の管理が可能で、IC はイベントへの変更が可能です。
レトロスペクティブ
UX 部門が直面する具体的な課題を理解するために、各マイルストーン終了後に非同期 UX レトロスペクティブを実施しています。このレトロは、ux-retrospectives プロジェクトで最近のリリース用に作成された新しい Issue を通じて実施されます。目標は、うまくいったこと、うまくいかなかったこと、改善できることを評価することです。
bfd74782)