GitLab ナビゲーション

オーナーシップ

以下の RACI テーブルは、私たちのプロダクトの道案内体験を構築するうえでの Growth: Engagement チームと Foundations: Design System チームの協業を示しています。Engagement チームがナビゲーションの意思決定とユーザーフロー最適化の最終的なオーナーである一方、Design System チームはこれらの体験を可能にする構造的な基盤、すなわちコンポーネントのフレームワーク、レイアウトのテンプレート、レスポンシブデザインのパターン、一貫性の標準を作り上げる主要な責任を担います。Design System チームが足場と再利用可能なシステムを構築し、Engagement チームはユーザーがこれらの構造をどのように移動・操作してビジネス目標を達成するかを決定します。

凡例

• R = Responsible（作業を実施する）
• A = Accountable（最終的な意思決定者）
• C = Consulted（意見を提供する）
• I = Informed（情報を共有される）

RACI テーブル

協業の原則

1. コンテンツのないテンプレート: Design System が構造的なテンプレートと領域を定義し、Growth がそれらの領域内のコンテンツを定義します
2. 要件よりガイドライン: Design System は厳格なルールではなく、柔軟な原則を提供します
3. 拡張可能なフレームワーク: Growth はシステムを拡張でき、パターンを Design System に還元できます
4. まず相談する: チームは、主要なオーナーシップを持つ領域であっても、大きな変更の前に互いに相談します
5. 反対しても決定には従う（Disagree and Commit）: 合意に至らない場合は、Accountable な当事者が最終的な意思決定を行います

エスカレーションのプロセス

• レイアウトとナビゲーションの衝突: 両チームのリードにエスカレーションします
• 機能とシステムの優先順位付け: プロダクトリーダーシップにエスカレーションします
• 新たに生じたオーナーシップの問題: ブロッカーになる前に、定例の同期ミーティングで対処します

ナビゲーションの変更をリクエストする

注: 承認されていないナビゲーションの変更を防ぐため、Code Owners の承認ルールが設定されています。このプロセスに従っていない場合、あなたのマージリクエストはブロックされます。

ナビゲーションとは何か？

ナビゲーションとは、ユーザーが GitLab 内を移動する助けとなる要素を指し、その構成や道案内の手がかりを含みます。ナビゲーション体験は、私たちの機能の使いやすさと発見しやすさに直接影響します。このドキュメントでは、私たちの目標を満たしつつ、ナビゲーションを集団的にどのように進化させられるかを説明します。

なぜナビゲーションを変更する際に慎重である必要があるのか？

過去には、チームが新機能を目立たせるために項目を追加していました。しかしこれは、ユーザーが必要なものを見つけることを困難にする、圧倒的なナビゲーション構造を生み出しました。私たちの四半期ごとの GitLab SUS 調査は、これらの繰り返し現れるテーマを引き続き浮き彫りにしています。

• ナビゲーションが複雑、または混乱を招く
• ナビゲーションが習得しにくい
• ナビゲーションが直感的でない

どのようなナビゲーションの変更に承認が必要か？

GitLab の UX はユーザーがさまざまな方法でプロダクト全体を移動できるようにしていますが、承認プロセスの焦点は左側のナビゲーションにあります。この領域はナビゲーションとしての役割と、ユーザーにとっての機能の発見ポイントとしての役割の両方を果たします。ナビゲーションが進化するにつれて、コアワークフローへの注力と機能の可視性のバランスを保つことが極めて重要です。

このバランスを保つために、私たちは左側のナビゲーションへの変更を提案する際に、全員に次のプロセスを使うようお願いしています。

• 第 1、第 2、第 3 レベルのナビゲーション項目の追加
• ナビゲーション項目の名称変更
• ナビゲーション項目の削除
• ナビゲーション項目の並び順の変更
• ナビゲーションの機能性や機能の変更
• Experiment または Beta 機能のローンチ
• ナビゲーション項目の表示対象の変更（例: デフォルトで無効から、デフォルトで有効への変更）

いつナビゲーションを変更するか

私たちは、ユーザーワークフローの最適化を目的とした慎重なプロセスを通じてのみ、GitLab のナビゲーション構造に新しい追加を行います。この動画は、ナビゲーションをイテレーションする際に考慮することが重要な主要な要因をまとめています。過去には、チームが新機能を目立たせるために項目を追加していました。しかし、すべての新機能を取り込むことは不可能になります。なぜなら、それはユーザーがタスクを完了するために必要なものを見つけることをあまりに困難にする、圧倒的なナビゲーション構造を生み出すからです。

したがって、私たちは次の目的では新しい項目を追加しません。

• 新機能の発見しやすさを向上させること。代わりに、プロダクト全体でその機能を目立たせる他の機会を探します。
• 起こりうる将来に向けて最適化すること。私たちは過剰に最適化することなく、先を見据えるべきです。機能が開発・追加されるにつれて、成長する機能をサポートするために必要となりうる変更を検討できます。

ナビゲーションの変更をどのように評価するか？

ナビゲーションの変更について、私たちが答える必要がある主な質問は 2 つあります。

1. このナビゲーションの提案は、私たちの主要な JTBD の 1 つを促進するか？ どのジョブか？
2. この変更は、そのジョブを完了しようとするユーザーのワークフローをどのように改善するか？

ナビゲーションの機会の領域を学ぶために実施できる問題検証リサーチには、さまざまな種類があります。実施する具体的なリサーチの種類は、調査のリサーチ質問と目標に基づくべきです。以下のリサーチ手法とフレームワークは、既存の GitLab ナビゲーションへの新しい追加を正当化するためにリサーチを使える方法の例です。

1. コンテキスチュアル・インクワイアリー: この手法では、ユーザーが自分のロールに関連するタスクを実行する様子を観察・インタビューし、その背後にある「なぜ」と「どのように」を理解します。
   • 例: ユーザーが、ダッシュボードを見つけるために GitLab 内の複数のメニューやページをどのように移動しているかを示すことがあります。このインサイトは、すべてのダッシュボードを見つけるための単一のページが GitLab に必要であることを明らかにします。
2. Jobs to be Done (JTBD): このフレームワークは基礎リサーチの一種で、顧客が自分のロールの中で達成したいジョブを学ぶことを目的としています。ジョブによって、私たちは顧客の仕事の状況、目標、成果を定義できます。
   • 例: ユーザーへのインタビューを通じて、彼らにはアプリケーションの健全性を示すためにメトリクスを追跡し、アプリケーションが故障しているときを特定できるようにするという主要なジョブがあることを学びます。このインサイトは、アプリケーションのメトリクスを表示するページを追加することで GitLab において埋められるギャップを示唆します。
3. 日記調査: この手法は、一定期間にわたってユーザーからのフィードバックを得るために使われ、日・週・月単位で起こる変化を明らかにできます。
   • 例: ユーザーが GitLab のナビゲーションバーへの大きな変更にどう関わるかについてのフィードバックを集める際に、GitLab の管理者が設定を調整するための管理者エリアを見つけることに、月をまたいで継続的に苦労していることを観察します。このインサイトは、管理者エリアが時間が経っても見つけにくいため、ユーザーインターフェース上でそれを浮かび上がらせる必要があることを示唆します。

ナビゲーションの変更が必要かどうかを学ぶために尋ねる質問:

1. 現在のあなたのロールに関連する主なタスクは何ですか？
2. なぜそれらのタスクは重要ですか？ それらのタスクを完了できなければ、何が起こりますか？
3. 既存のツールを使って特定のタスクをどのように実行するか見せてください。
4. そのタスクを完了するプロセスについて、もしあれば、何を改善しますか？

ナビゲーションの問題に対するインサイトが得られたら、プロダクトチームの DRI は、後続のソリューション検証調査を通じて理想的なソリューションを評価するために、Product Design と UX Research と協力すべきです。

ナビゲーションの変更を提案する方法

もしあなたの主要な目標が自分の機能の発見しやすさを向上させることなら、まずはプロダクト全体でその機能を目立たせる他の機会を探してください。

1. Issue を開く前に、Pajamas のナビゲーションの要素とパターンを確認してください。
2. ナビゲーションの変更の一覧とその内容を確認し、あなたの変更が該当することを確かめてください。
3. Growth: Engagement のプロダクトマネージャーが、ナビゲーションの変更の DRI です。あなたの提案が完全な検証を必要とするか、限定的な検証を必要とするかを判断するために、彼らに連絡してください。
4. ナビゲーション提案の Issue テンプレートを使って、このプロセスのレビューを開始できます。
5. Growth: Engagement のデザイナーが、提案をレビューして意見を提供することで DRI を支援します。Growth: Engagement チームからの一般的な所要時間は 1 マイルストーンです。フィードバックを提供した後、提案を前進させ、必要に応じて追加のフィードバックを求めることは DRI の責任です。
6. 承認を得て実装を開始する準備ができたら、ナビゲーションへの項目追加に関する GitLab Docs に従ってください。

完全な検証パス

このパスは、GitLab ユーザーの大多数に影響を与える、または新しいデザインパターンを導入するナビゲーションの変更に適しています。完全な検証が必要となりうる変更の例:

• Beta または一般提供 (Generally available) 機能のローンチ
• ナビゲーションの構造や機能性の変更
• 既存のナビゲーション項目の削除
• 既存のナビゲーション項目の名称変更

Growth: Engagement の PM が、あなたの提案が完全な検証パスに従うべきかを判断する DRI です。このパスでは、ナビゲーション提案の Issue の一部として、次のステップを完了し文書化することを求めます。

限定的な検証パス

このパスは、少数のユーザーに影響を与える、または既存のデザインパターンに従うナビゲーションの変更に適しています。限定的な検証が必要となりうる変更の例:

• フィーチャーフラグの背後で利用可能な実験的機能
• 既存のインテグレーションのパターンに従う新しいサードパーティ製インテグレーション
• すでに不整合がある箇所に一貫性をもたらす変更

Growth: Engagement の PM が、あなたの提案が限定的な検証パスに従えるかを判断する DRI です。このパスでは、ナビゲーション提案の Issue の一部として、次のステップを完了し文書化することを求めます。

調整のプロセス

ナビゲーション提案のプロセスは、コアワークフローへの注力と機能の可視性のバランスを取ろうとするものであり、これは提案の作成者が Growth: Engagement チームの決定に同意しないことがあることを意味します。もし私たちが誤ったバランスを取ったと感じたら、提案にコメントを追加して次のことを行ってください。

1. 提案がなぜ却下されたか、そしてこの決定がなぜ正しくないと考えるかについてのあなたの見解を要約する
2. あなたのマネージャーと Growth: Engagement の PM のマネージャーにメンションする
3. その決定についての彼らの意見を求める

ページのソースコードを見る - ページの編集 - please contribute.