アプリケーションを実装していくと、「大規模なUI改修」に遭遇することがある。 あちこちで見聞きした結果、以下のようなパターンがあるように感じたのでまとめてみた。
（UI改修なので基本的にフロントエンドからみた内容）

1. 機能実装を進めて行った結果、UIの実装が難しくなる。

これは一般的に「技術的負債」と呼ばれることが多いが、デザインの負債（UIを置く場所が無くなったり無くなったり、同じ概念のUIが分散したり）である場合も多い。
（ちなみに、デザインの負債は「ダイアログを多用する」とか、「最小画面サイズが大きくなる」とかの形で現れやすい）
そして、デザイン負債に対応するために実装の困難なUIが増えるため、技術的負債も高くなる傾向がある。
（サーバサイドの技術的負債がDBの負債に起因する場合が多いことと似ているかもしれない）

2. 技術的負債の解消とデザイン負債の解消を目的とした「大規模なUI改修」が企画される。

これは主に技術的負債の解消を目的に行われる傾向が高いが、「せっかくなのでUIも整理したい」という形になる場合が多い。
ただし、ここで、技術的観点での改修の場合、ユーザに提供される機能の整理が行われる可能性は低い。
新規機能の実装は平行される場合とされない場合がある。ただし、新規機能の実装が停止される場合、「大規模なUI改修」にかけられる期間は短くなる可能性が高い。

3. 「大規模なUI改修」が長期化する

基本的に大規模な改修の事前見積もりは大きく外れる可能性が高い。
特にコードとデザイン両方を改修する場合不確定性が非常に高くなる。
（両方合わせてリスクの評価、見積もりを行うのは不可能と思った方がいい）

4. リリースが延期される

以下のような理由でリリース判断が延期される可能性が高い。
PM「ここまで時間をかけたのだから、この機能も入れたいし、完成度も上げたい」
マーケ「ここまで時間をかけたのだから大規模な告知をしたいから、ぎりぎりまで社外秘にしたい」

5. ビッグバンリリースが行われ、ユーザの反発を受ける

ユーザはなんの告知もなく、急に新しいUIを強制されるため作業性が低下し反発する（大きな「UIギャップ」がある状態）
特に新規実装が停止された状態で改修を行っている場合、ユーザは既存UIになれる時間が長いためUIギャップはより大きくなる。
しかも、社内ではずっと新UIを使い続けているため、急にUIが切り替わった場合の検証ができない。
そのため「一時的なもの。そのうち慣れる」、「新規ユーザの満足度は高い」という理由で既存ユーザのUIギャップは無視される。
（が、場合によっては新UIの提供を断念することもある。この場合、社員の人事的なインパクトが大きい場合も多い）

どう回避したらいいのか

これは途中の選択肢によって状況が緩和されたり、そもそも問題が起こらない可能性もあるが、それぞれどういった方法で回避、緩和できるかを考える。

1. デザイン的な負債も継続的に返却する

デザインも負債化する前提で、継続的に改修を行う。
これはユーザが継続的なUI改修に慣れるという意味でも効果がある。
UIの改修（場所の移動）や廃止（機能統合や廃止）はユーザの反発を受けやすいが、後述する方法でUIギャップを減らすことも可能。

2. 「大規模なUI改修」を行わない

これは技術的な意味と、社内告知的な意味が含まれる。

技術的な意味だと、できる限り改修を細分化し、総合的な時間ではなくリスクに注目して改修を行った方が良い。
（UIの改修（デザイン負債の回収）は可能であれば技術的な負債の回収後に行う方が安全だが、難しい場合はUIの改修も細分化し、技術的負債の回収と交互に行うと良い）

社内告知的な意味だと、そもそも技術的、デザイン的な負債の回収を目的とするのではあれば、技術的、デザイン的な責任範囲以外に改修を行なっていることを知らせない方がいい。
まず、なんであれ負債の回収は継続的に行なっていくものだし、「大規模なUI改修」が必要とされているのであれば組織的に負債の返却が行われていない可能性が高い（もしくは負債の返却が追いついていない）
負債の回収を「大規模なUI改修」に頼る体制だと毎回大きなリスクを背負った改修が必要になるし、改修のためのに社内の知識、メンバーだけでは足りず、無理な採用を行うリスクも高い。

それでも「大規模なUI改修」を行う場合

それでも「大規模なUI改修」を行わざるを得ない場合、UIギャップを考慮したリリース（段階的UIリリース）を行う。

UIの改修（場所の移動）や廃止（機能統合も含む）など、ユーザの反発を受けやすい改修を行う場合、以下のような段階的UIリリースを行うことでUIギャップを抑える。
（もし、この選択肢を取れないほど大きなリリースを行う場合、改修と新規実装を並行して行いリリースまでの期間をできるだけ柔軟化すること）

UI移行（ボタン等のUIを別の場所へ「移動」させる場合）

1. 移動したい先へUIを追加する（一時的に同じUIが2箇所に存在することになる）
2. 元の位置のUIへ移行先UIの案内を出す（hoverや(?)などで「このUIはこちら(リンク)へ移動予定です」などを出す）
3. 元の位置のUIをクリック時に新しいUIがある場所を開いて、新しいUIがクリックされたものとして扱う
4. 元の位置のUIをクリック時に新しいUIがある場所を開いて、新しいUIをハイライトさせる（新しいUIのクリックはユーザに行なってもらう）
5. 元の位置のUIをクリック時に新しいUIへの案内を出す（「このUIはこちら(リンク)へ移行しました」等）
6. 元の位置のUIをグレーアウト（disable）して新しいUIへの案内を出す（hoverや(?)などでのみ案内を出す）
7. 元の位置のUIを削除する

UI廃止（機能統合も含む）

1. ヘルプ等に案内を出す（これまでと同じことをするにはどうしたらいいのか。もしくは、なぜ廃止するのか）
2. （機能統合の場合）統合先のUIを追加する（一時的に同じUIが2箇所に存在することになる）
3. 対象UIに案内を出す（hoverや(?)などで「このUIは廃止予定です。詳しくは(リンク)をご覧ください」などを出す）
4. （機能統合の場合）対象UIへの操作を統合先UIへの操作として扱う
5. （機能統合の場合）対象UIへの操作時を統合先UIへの誘導を行う
6. （機能統合の場合）対象UIをグレーアウトして統合先UIへの誘導を行う
7. 対象UIを削除する

この手順はUIの重要度、改修が行われなかった期間（ユーザのUIギャップ量）、ユーザの使用頻度に応じてスキップされる。
また、各手順は同時にリリースされる場合もあるが、基本的にはユーザがUIに慣れるために1手順につき1週間程度は期間（UI廃止の場合はそれ以上）をあける。
（訪問頻度が1週間以上のユーザはUIギャップを受けるが、そもそも訪問頻度が低いユーザはUIへの慣れも少ないので問題は少ない）
これ以外にも、色を変える時に「中間色も用意してステップを踏む」や、UIの形状を変える時に「徐々に変えていく」と言った段階もありうる。

段階的UIリリースの欠点

段階的UIリリースはユーザのUIギャップを抑えるが、以下のような欠点もある

1. 実装コストが高い

中間状態を実装するため、新規の追加実装が必要になる。
これは、上記のステップのうち、実装が簡単なステップのみを実装するという方法で緩和することもできる。
また、実装期間を「ユーザがUIを慣れるための期間」に当てることでフロー効率を取ることもできる。

2. 完璧でないUIを提供することになる

ユーザに中間状態を見せることになるため、「常に完璧なUIを提供する」と言った考えと相容れない場合がある（これはデザイナから言われることが多い）
これは「新規ユーザには最終段階のUIを提供し、既存ユーザには段階リリースを行う」ことも可能だが、実装が非常に複雑になるのでおすすめできない。
ユーザのUIギャップに関してチームで話したり（ユーザのUIギャップをどの程度と見るか、他に緩和策はないか）、LTVの観点から判断することも必要になる可能性がある。

UIギャップの指標

UIギャップの緩和策が適切か（各ステップが大きすぎないか）はステップごとに（おそらく最もヘビーに使っているであろう）社内ユーザに見てもらうことで判断できる。
社内ユーザに何も情報を与えずいきなり画面を見せて問題なく操作できるならステップは適切な可能性が高い。
（UIに慣れたユーザで評価が行えるため、UIテストの対象者が豊富なのもこの手法の利点）

段階的UIリリース以外の方法

UIギャップへの対応には段階的UIリリース以外にも以下のような方法がとられることがある。

1. 事前告知

ブログ等で画面キャプチャを使って事前に告知するパターン。
ただ、実際操作できない画像等ではユーザが事前に受け取れる情報が少ないためUIギャップの回避にはそこまで影響しない可能性が高い。

2. 新UIのベータリリース

特殊なURLからアクセスした場合のみ新UIを提供するパターン。
画面キャプチャより受け取れる情報は多いが、既存UIに慣れたユーザほど新UIへの以降は難しいため、UIギャップが大きいユーザほど新UIを使わない可能性が高い。
また、ベータ状態で挙動が不安定だとユーザから見てどこが改修対象か判断できず、UIギャップが大きくて使うのに違和感がある場所も不具合と考えてしまい「まだ未完成だからフィードバックしなくていい」と判断してしまう可能性もある。

3. 旧UIの並行提供

新UI提供後も設定の切り替えや特殊なURLからアクセスした場合のみ旧UIを提供するパターン。
旧UIに慣れたユーザは旧UIを使い続けられるためUIギャップはほぼ存在しないが、複数UIを同時提供することになるためメンテナンスコストが高い。
また、ユーザサポート時に新旧どちらのUIを使っているのかの切り分けが必要になるためサポートコストも高くなる。
APIの設計変更に伴って旧UIが使えなくなったり、旧UIのセキュリティリスクのため旧UIを廃止する場合が多い。
旧UIを廃止する場合UIギャップが存在することになるが、並行提供の期間（半年程度）、廃止するまでのアナウンス期間（3ヶ月程度）等によっては問題ない程度までUIギャップを抑えることができる。

まとめ

1. 「大規模なUI改修」は不確定性が非常に高く、経営判断に近い問題（技術的、デザイン的な問題に起因して行うのは非常にリスクが高い）
2. UIの改修も細分化して行うことは可能（その場合、ユーザの「UIギャップ」を意識して進める）
3. 技術、デザインに寄らず負債の返却にはコストがかかる（ただし、大抵のプロダクトでは「リスクが高い」よりは「コストが高い」方がコントロールしやすい）

みなさん、よい「大規模なUI改修」を。

リンク

pixivサイトリニューアルの軌跡　長寿サービスの刷新において大切なこと - ログミーTech

Backlog UI リニューアルの舞台裏 / Backlog Renewal UI - Speaker Deck

『マネーフォワード ME』Web版リニューアルに関する今後の方針について｜Yosuke Tsuji｜note

大規模なUI改修 の話したやつ - Togetter