Our settings page was overwhelming our users. Here's what we did to fix itの意訳です。
CodeRabbitは、あらゆる言語、フレームワーク、チーム規模に対してコードレビューを提供します。サイドプロジェクトをリリースする個人開発者から、数百のリポジトリにわたってコンプライアンスを適用するエンタープライズまで。この幅広さは、多くの設定項目によって実現しています。2004年型ホンダ・シビックのダッシュボードよりも確実に多いです。
すべての設定は、誰かが必要としたから存在しています。パス指定のレビュー指示、ツールレベルのトグル、ドラフトPRの扱い、ラベリングルール、トーンの調整。それぞれが誰かにとっては譲れない機能です。削除すればそのユーザーを失い、残せば設定ページは膨れ上がります。
時間が経つにつれて、設定ページが大量のオプションの壁となり、多くのユーザー、特にCodeRabbit初心者を圧倒するようになりました。その解決方法と、その過程で得た学びを紹介します。
設定ページを使っているのは実際に誰なのか？
何かを変更する前に、設定を使っているのは誰で、そこで何をしているのかを調べました。4つのパターンが浮かび上がりました。
「とりあえず動けばいい」ユーザー。 CodeRabbitをインストールし、レビュー言語を変更するくらいで、二度と設定に戻ってきません。合理的なデフォルト設定と、重要なものを見落としていないという安心感を求めています。
こだわり派の開発者。 トーンの調整、パス指定の指示設定、ウォークスルーセクションのトグルなど、15分ほどかけてチューニングします。その後は放置です。
プラットフォームチーム。 コンプライアンス要件があり、すべてのリポジトリに標準を適用するエンタープライズです。彼らのユースケースがエッジケースそのものであるため、すべての設定へのアクセスが必要です。
「設定はコードで管理」ユーザー。 UIは一切求めていません。バージョン管理されたYAMLファイルをPRでレビューし、自動的に適用したい方。設定はインフラの一部だと捉えています。
私たちのチームにとっての課題は、これらが固定されたユーザーセグメントではない事実を認識することでした。同じユーザーが月曜日は「とりあえず動けばいい」グループに属し、金曜日には「設定はコードで管理」グループに属することもあります。
単純な「詳細設定」トグルではうまくいかなかった理由
設定過多に対する明白な対策は、シンプルビューに「詳細設定」トグルを付けることです。試してみましたが、いくつかの理由でうまくいきませんでした。
私たちの設定UIは、JSONスキーマから直接生成されています。このスキーマは、数百万のリポジトリにわたるすべての.coderabbit.yamlファイルを駆動するものと同じです。開発者がスキーマにプロパティを追加すると、追加のフロントエンド作業なしにUIが自動的にレンダリングされます。この仕組みを失いたくありませんでした。スキーマに「基本」と「詳細」のフラグをつけると、シンプルに保っていたシステムに複雑さを持ち込むことになります。
しかし、より根本的な問題はアーキテクチャよりもシンプルなものでした。何が基本で何が詳細なのか、合意が取れなかったのです。「レビュアーの自動アサイン」は基本設定でしょうか、それとも詳細設定でしょうか？個人開発者にとってはニッチなトグルですが、エンタープライズチームにとっては重要なワークフローです。
基本/詳細の分割は、ユーザーが「習熟度」という単一の軸上に分布していることを前提としています。私たちのユーザーはそうではありません。あるペルソナにとって詳細な設定が、別のペルソナにとっては当たり前の機能なのです。
3つのビュー、1つの真実
スキーマを再構築することも、2つの階層（基本/詳細）に分割することもできなかったため、別のアプローチを試みました。設定の表示方法と保存方法を分離するのです。同じ設定データに対して3つのビューを構築しました。
- 簡潔ビューがデフォルトです。大多数のユーザーが実際に変更する、厳選された設定のサブセットを表示します。利用データ、サポートのデータ、ユーザーからの直接フィードバックに基づいて選定しました。グルーピングもスキーマとは異なります。「動作設定」は複数のスキーマセクションから設定を集約しています。ユーザーがそのように考えるからです。
- 全設定ビューはすべてを表示します。スキーマから自動生成されるUIも、YAML構造と同じグルーピングも同じです。ツール固有のルールやナレッジベース設定が必要なプラットフォームチームは、ここですべてを見つけられます。
- YAMLエディタはスキーマバリデーション付きのMonacoエディタです。ブラウザ上でコードとして設定を編集でき、リアルタイムのエラーチェックも備えています。
3つのビューはすべて同じデータを読み書きします。これにより、議論は「これは基本か詳細か？」から「大多数のユーザーがこれを見る必要があるか？」に移り、別途スキーマを管理する必要もなくなりました。
設定を具体的にする
3つのビューで構造の問題は解決しましたが、より根深い課題がありました。設定が抽象的だということです。「シーケンス図を有効にする」は、PRレビューでシーケンス図がどう見えるか知らなければ、意味がわかりません。
そこで、ライブプレビューパネルを追加しました。設定の横に、モックPRレビューコメントを表示します。
「シーケンス図」をオフにすると、プレビューからダイアグラムが消えます。「Preview」タグが付いた設定は、どれが視覚的な効果を持つかをユーザーに伝えます。推測で設定するのではなく、保存前に結果を確認できるのです。
これにより、設定の再編成だけでは解決できなかった大きな問題の一つが解決しました。ユーザーが設定で何が制御されるのか理解していなかったという問題です。
得られた学び
設定ページは華やかなものではありません。しかし、間違えると、すべてのパワーユーザーがその影響を感じます。このプロセスを経て私たちのチームに残った3つの学びと、次のリデザインにどう活かすかを紹介します。
すべてのユーザーに適した唯一のビューは存在しません。 個人開発者とエンタープライズのプラットフォームチームでは、同じ設定ページに対して根本的に異なるものを求めています。うまくいったのは、同じ設定に対して異なる経路を提供し、それらの間の遷移をシームレスにすることでした。簡潔ビューで始めた人が探しているものを見つけられない場合、全設定ビューにスムーズに遷移できるべきで、袋小路に行き詰まるべきではありません。
構造だけでは混乱は解消しません。 私たちは整理やグルーピングに多くの時間を費やしましたが、最もインパクトのあった変更の一つはプレビューパネルであり、それは構造とは無関係でした。入力の横に出力を表示することで、説明文だけでは決してできない方法で設定を具体的なものにしました。
すでに動いているものを守る。 スキーマを再構築してUIをよりクリーンにすることもできました。しかしそれは、世の中のすべての
.coderabbit.yamlファイルを壊すことになります。データ層を安定させ、柔軟性をプレゼンテーション層に持たせることで、他の部分にリグレッションを発生させることなく、まったく異なる体験を提供できました。
ぜひ試してみてください。CodeRabbitの無料トライアルを始めましょう。
