過去4年間、何も変更されずに実行されていたレガシーWebアプリケーションを引き継ぎました。
元のソースコードには深刻な問題があり、単に「捨てる」ことが容易になるため、現在、アプリケーションを書き直しています。書き換えは、非常に類似したWebプロパティのコンポーネントに基づいているため、次のようになります。
レイアウトは完全に変更されます。一部の廃止された機能は削除され、他のすべての既存の機能は再実装されますが、現在の機能とは少し異なる動作をする場合があります。ワークフローに大きな変更はありません。この変更により、一部のコピーの変更がカプセル化され、プロパティを継承したことが反映されます。
ユーザーエクスペリエンスに関して、この移行が1日から他の日に移行するには大きすぎるかどうかについて、私たちは2つの考えを持っています(今日のWebサイトを閲覧し、過去4年間に見られたものを見て、翌日にはまったく異なるものが見られます)。そして、どういうわけかユーザーをそこに「緩和」するのが良い考えかどうか。
大規模なWebプロパティのそのような大きな成功した移行の例はありますか?このジレンマに向けて私たちは何を学ぶことができますか?経験からの他の提案はありますか?
デザインを分けておくことをお勧めしますが、段階的なリリースを提供します。中間設計を作成しようとすると、設計者としての作業負荷が2倍になるだけで、ユーザーは1回ではなく2回方向転換するコストが発生するため、最小限のメリットしか得られません。
段階的リリースは3つの部分で構成されます。
ベータ段階中、ユーザーはアプリケーションの古いバージョンから新しいバージョンに移行できます。これらは興味のあるやる気のあるユーザーなので、フィードバックを提供する機会を提供することはおそらくうまくいくでしょう。ユーザーのテスト参加者を無料で招待する機会さえ得られるかもしれません。やる気のないユーザーは、物事が変化していることに気づくでしょう。
試用段階中、ユーザーは新しいバージョンから開始しますが、古いバージョンに自由に移動できます(または、現在のインターフェースでサポートされていないページにアクセスする必要がある場合)。新旧の動きを追跡し、新しいページの直帰率を確認すると、現在のUIの問題に関する手掛かりが得られます。古いサイトで最も一般的なコンテンツとアクションの新しい場所へのリンクを備えたスプラッシュページの使用を検討してください。
最後に、リリース段階で、古いアプリケーションがオフになります。ブックマークを介して古いアプリにアクセスしようとするユーザーは、おそらく変更を説明するバナー(ヘルプ資料へのリンク付き)とともに、新しいバージョンのページに移動します。
あなたが自分のコントロールを超えて物事を変更すると、ユーザーは嫌いになります。変更の準備をするには、特別なものに見せかけるにします。
Designing for Emotionで、Aarron Walterは、サイトのオーバーホールのためにユーザーを準備するための鍵が、ベータ版のリリースが非公開であること)それに招待されたユーザーが、サイトへの関与に基づいて選択されている(または少なくとも選択されているように見える)こと。
これには排他性の利点が2つあります。
この良い例は、新しいTwitterのロールアウトです。早期にアップグレードされたユーザーは、新機能について自慢し始め、ツイートに#NewTwitterのタグを付け始めました。ウォルターによると:
アクセスが制限されていたため、ベルベットロープの効果が生まれ、強力な感情的影響がありました。早期アクセスを許可されたユーザーは、独占感とステータスの高さを感じました。これは、ツイートすることで高まり、フォロワーからの憧れの@返信を受け取りました。
(古い)コード全体を破棄するため、小さな変更という通常のアプローチは適用されません。
あなたができることは、変更にユーザーを興奮させることです。
ユーザーがウェブサイトにアクセスしてデザインをすぐに変更することを伝えたら、ヘッダー表示またはオーバーレイを使用します。視聴者の共感を呼ぶようなものにしてください。「混乱の準備をしてください。2013年4月4日」または「フェイスリフトを取得しています!」または何かの種類
ユーザーをプロセスに参加させます。何を変更する必要があるかなどについて専門家の意見を求めます。ユーザーからのフィードバックを得て、変更の準備を整え、変更を確認することに興奮します。
全員に新しいレイアウトを紹介します。新しいレイアウトを理解したり関係付けたりするのに役立つ一時的なビデオなどを用意できます。古いものと新しいものを比較し、新しいものの方がはるかに優れていることを強調します。 「ツアーを開始する」ボタンを用意するか、一時的なウェルカムオーバーレイを使用できます。
他のものは良いアドバイスを与えたので、ここで少しだけ追加します。
段階的な変更を行うことができない場合は、ユーザーを関与させ、ユーザーが真剣に受け止められ、変更に貢献したと感じさせます。うまくいけば、あなたはそれがすべてがどれほど素晴らしいかについて伝道する熱狂的なファンを何人か得るでしょう。
これも読んでください: http://www.uie.com/articles/radical_redesign は、まさにあなたの問題であると思われるものと利用可能ないくつかのオプションについて説明しています。
通常推奨されるアプローチ
これを時間の経過とともに控えめに行う方法を理解できる場合は、それを実行してください。コンセプトは進化から来ています-マイナーな変異は、時間の経過とともに伸び、生物を環境によりよく適合させます。 1世代での突然の大規模な突然変異は、生物または世代全体を殺す可能性があります。
問題の説明から私が見ることができる分割は、UIを劇的に変更することなく、「コントローラー」コードの変更と同じくらい試行して実行することです。 UIの変更をすこし始めて、自然のユーザーへの事前警告メッセージを表示することができます。以前は「ここ」であったものが、今では「ここ」にあります。数週間/数か月で沈没するようにしてください。そうしてください。
ユーザーベースのサイズとユーザーのタイプに応じて-おそらく良い方法です。実際に多くのユーザーがいない場合は、必要ない場合があります。 (Facebookがいつ変更するか考えてみてください-どんなに小さなことでも-すべていろいろな人がそれについておかしく思っていますが、壮大な計画の中に、それはユーザーベースのほんのわずかな割合です...そして彼らは通常それを乗り越えますが、変更は比較的小さいです。「ログアウトリンクを移動しました。」)
通常は推奨されないアプローチ
すべてを変更して、新しい方法がどれほど改善されるかについていくつかのビデオとコミュニケーションを作成します-私たちは約束します。これは、Microsoftがリボンに切り替えたときに発生しました。リリース前は、彼らが1年ほど人々を準備する(または少なくとも試す)ことに費やしたと思います。 「それは素晴らしいことになるだろう...」「ユーザーを調査した...」など。一般に、突然の包括的な変更により、ユーザーベースが失われる可能性があります。ただし、すでにユーザーを失っている場合は、ユーザーを取り戻す可能性があります(現在の例では、この記事を書いている時点での金曜日のレストラン)。
私はこの辺りで以前にそれを言ったことがありますが、私は「それは依存する」と言うその男であることを嫌います-しかし、それは依存します。すでにユーザーを失い、劇的な変更の一部を計画している場合は、それらのユーザーの懸念の大部分に対処します。リリースする予定の変更をまとめて市場に出します。ユーザーベースがかなり安定していて、クレームがあまりない場合-遅くなる-壊れていない場合(ユーザーの観点から)、それを修正しないでください(少なくとも一度にすべてではありません)。