it-swarm-ja.com

UXが低い大規模なレガシーシステムから段階的に移行する方法

私たちの多くは、以前にこの問題に直面していると思います。中規模組織で唯一のUXデザイナーとして、プロジェクトの実行中にいくつかの課題に直面しています。組織には、製品を販売するための内部および外部(エンド)の顧客向けのレガシーWebベースのシステムがあります。既存のデザインと使いやすさの背後にある思考/理論的根拠はほとんどありません。

新しいプロジェクトでは、ユーザビリティとユーザーエクスペリエンスの重要な側面に対応しようとしていますが、'Chicken or Egg'タイプの状況があるようです。あるプロジェクトで何かを使用すると、他のプロジェクトには適しません。したがって、何かが(機能レベルまたは新製品レベルで)新しく設計されている場合、私は既存のものを検討する必要があります。私のデザインと既存のデザインの違いは、フォント、ボタンスタイル、ポップアップまたはページはめ込みコンポーネントの使用、確認、フィードバックメッセージタイプのスタイル、配色などから直接確認できます。しかし、それを使用するまでは、新しいものを使用することはできず、一貫性が失われます。ユーザーは、35歳以上のタイプのユーザーよりも、ほとんどが技術系ウェブに精通していないため、既存のインターフェースからの移行が問題となる場合があり、適切に行わないとビジネスが失われる可能性があります。私が考えることができる3つのタイプの解決策があります:

  1. 現在のシステムを使用して続行(しかし、その役に立たない、魅力的ではなく、拡張性がなく、これ以上の期間は機能しません。さらに、これは私が得ているものではないため、このように楽しむことはありません)
  2. 新しい新しいシステムを構築する(私はこれを気に入るでしょうが、それは高価で、時間のかかるものです。非常に難しく、このために便利なチームにとって不可能に近いものです)
  3. ミックスする(ただし、エクスペリエンスは一貫しません。同じページに、2つの異なるスタイルの2つのボタンと、このような多くのものがあります。良いミックスではなく、混乱します)

これらすべてを考慮して、古いインターフェースからより良いインターフェースにスムーズに移行する方法(ここでは戦略的な観点を期待)

5
Spicerjet

まず、簡単な答えはここにはありません。第2に、ソリューションのリストから、1番は実際にはソリューションではなく、2番はスターターではないように聞こえます。

問題は、エクスペリエンスを改善する目的で、可能な限り最小限の影響で、大規模なレガシーシステムを段階的に置き換える方法についてです。

権力と予算の問題

ロードマップと予算の文字列を保持している部門の支援がない場合、世界で最高のUXの目的は、これでどこにも行けないことです。このサイズの事業は複雑で高価であり、重要な支援がない場合、あなたの唯一の選択肢は雑巾を出してその土を磨き始めることです。

バッキングがない場合は、少し後退して、この再構築に必要な潜在的なバッカーをどのように説得するかについて質問する必要があります。

レガシーシステムアーキテクチャの問題

これに対する次の最大のハードルは、レガシーシステムアーキテクチャとその柔軟性です。それが変更またはアップグレードされない限り、これらの新しいインターフェースは弱い基盤上に構築されることになり、長期的にはより多くの作業とトラブルを引き起こします。理想的な状況では、新しいUIはシンプルでスケーラブルなシステムを反映したものになり、単純化されたアーキテクチャの設計は、物事を機能させるという問題を解決するよりも簡単になります。システムが変わらない場合、あなたの仕事は本当にあなたのために切り取られています。

製品/プラットフォームセグメント別の移行

(これは、実際にシステムをゼロから再構築しようとしていることを前提としています)1つのアプローチは、独立して機能することができるプラットフォームの最小の完全なスライス、理想的には関連するがそれほど重要ではない何かを取り、それを再構築して開始することですと。プラットフォームについて何も知らないため、これが何であるか、おそらくいくつかの二次サービスを提案することは困難ですが、アイデアは、概念を証明し、システム全体に関連する問題を解決できるセクションを分割することです。これを古い環境と一緒に配置する新しい環境として起動し、プラットフォームのスライスをどんどん大きくして再開発します。

機能/機能による移行

(これはあなたのケースではより現実的かもしれませんし、必ずしもすべてを再構築しているとは限りません)機能/機能によってプラットフォームをセグメント化します。認証、ユーザー管理、注文、ナビゲーションなどを行い、一度に1つずつ使用します。あなたがそれを正しく理解していると仮定すると、このアプローチはユーザーにとってほとんど混乱を引き起こしませんが、あなたにとってははるかに多くの作業です。

テクニカルノート:私は、このアプローチを採用したシステムアップデート(完全な再構築ではない)に取り組んできました。機能ごとの移行を可能にするために、エンジニアリングチームはレガシーアーキテクチャよりも軽量で柔軟性のある新しい内部APIを構築することになり、改善のために機能を分離する自由が与えられました。

システムビルダーとのコラボレーション

あなたは本当にこれをシステムを構築する人々と話すべきです。最終的に取るアプローチは、最終的にはリソースに依存します。完璧な移行戦略を想像するだけでは、達成できないことを見つけるだけです。

結論:これはほとんど出発点ではありません。あなたは非常に複雑なプロセスについて尋ねています。幸運を。

4
dennislees