1

First some context. So my organization is in the process of switching our JS frameworks (From Angular to React) and possibly even backend technologies for our web app. We don't have time/resources to simply stop and redesign the app all at once, so there will need to be a transition between technologies. The proposed strategy is that, from now on, each new section/feature will be developed in React while maintaining the old sections in Angular (to be switched over eventually).

My question is, rather than attempt to duplicate the UI in the new sections, and trying to 'fool' the user into thinking the new sections are exactly the same as the old sections (and all the maintenance issues that go with that), would it be kosher if the new sections were a totally separate entity? New header, cleaner look, improved colors... etc. This implementation would be easier from a technical point of view, but from a design point of view, I can see benefits as well. I could redesign layout and navigation and not have to worry about backward compatibility.

Of course, there is the concern of disorientation, but I believe it's possible to communicate the new section is a part (though obviously separate) of the rest of the app. Of course, we would always offer a way back to the old app.

I was thinking it would look something like this:

Old Sections vs New Section

I was just curious if anyone was familiar with any other apps doing something similar. Is this particular technique have a name?

Thanks in advance.

  • What is the approximate size of your user base? How tolerant are they to change? – bloodyKnuckles Dec 8 '16 at 16:08
  • It's for a B2B audience, so our user count is rather low (probably < 10,000 users), but they have a lot invested in it. Generally, change tolerance among our users is low, but the old section is so bad at this point, I think any change for the better will be welcome. – eRocket Dec 8 '16 at 16:57
1

This would be an ongoing slow-motion fireball of a disaster, in terms of usability, product coherence, and user trust in your company's capabilities and professionalism.

Not to put too fine a point on it.

Usability

Throughout the transition period, your users would have to cope with two competing layouts and two conflicting navigation structures. This would double their cognitive load in trying to keep track of where everything is, and would cause confusion about how the two halves correspond to one another.

(Looking at your before and after screenshots, it's totally unclear to me which links are intended to correspond to each other in each layout; this would be confusing even if you weren't planning to change the structure of the application along with the redesign.)

The problem will be exacerbated by the fact that things will keep moving around on them as you gradually transition from one framework to the next; it's unlikely you'd be able to document the current state of the system during the transition period, or that users would be able (or willing) to keep up with it even if you were.

change tolerance among our users is low

...so it's maybe not a great idea to subject them to months of ongoing, gradual but radical change.

Product Coherence

But it's even worse than that, because you're also planning to

redesign layout and navigation and not have to worry about backward compatibility.

...which means that the navigation structures will be in conflict; sections which are to be removed from the old design will be inaccessible from pages which have the new design, and vice-versa. The user will have to remember things like "ok, to get back to this old feature from this new page I have to click one of the nav links that I remember happens to point back to the old design, so I can get to the old navbar which links to the thing I actually want to get to. Oh, wait, I guess they updated that page now. How do I get back to the old design? Where am I?"

Or alternatively, you'll have to preserve and maintain the entire "old" application throughout the transition, just so you have a reliable fallback for the missing parts of the incomplete "new" application. This would be effectively the same as just redesigning the whole new product behind the scenes and cutting over on launch day, except much more difficult because you'll have to support both in public throughout the transition.

But you can't do that, either,

because of the extensive database redesign that's involved in this project... it would be impossible (or at least undesirable) to maintain both at the same time

Not worrying about backward compatibility is one thing -- you're proposing not worrying about current compatibility. Right now your users have a product they can use. While they wait for you to finish your redesign, they'll be stuck having to work with two halves of two different products.

Professionalism

We don't have time/resources to simply stop and redesign the app all at once

That may be true, but it's probably not a good idea to expose that fact to your users quite so blatantly.

Redesigning only part of your application clearly sends the message "we lack the capability to do this job properly, so please just bear with us while we muddle through."

No need to belabor this point further, I think.

So.... Instead of that...

It is probably not a great idea to redesign the product's appearance, and its functionality, and its navigation structure, while simultaneously transitioning from one front-end framework to another, as well as redesigning the database structure -- everything, in other words -- in public, with live data coming from both sides, while trying to keep everything in synch.

That's, like, a totally full Risk Factor Bingo card, even if you set aside the UX factors this answer is putatively about.

You need to separate these processes, for your own safety and sanity, as well as that of your users. Don't try to do everything at once; you'll fail.

If you need to change frameworks, I'd suggest completing that transition first, without considering any changes to functionality, layout, or structure. This will tend to make the code transition much quicker and smoother than if you're trying to make other changes at the same time. (It'll also have the incidental benefit of letting your devs get a handle on how React works before they have to dig in on the "real" new design; they'll be doing their learning on the version you plan to throw away, instead of on the code you'll be living with long term.)

Some database structure changes probably go along with that by necessity, but keep these as minimal as possible.

Once you have a solid footing from a technological standpoint, then it's time to start thinking about redesign and structural changes.

Especially with a change-resistant audience, I like to do this in two separate stages:

  1. Cosmetic changes. If these are major, do them all at once. Rock that new look-and-feel, move the layout around like mad, but keep all the functionality and the navigation hierarchy exactly the same, so the user doesn't feel lost; it's the same product, it just looks prettier. This is what will be perceived by users as the real redesign, even though it's functionally identical to what was there before.
  2. Functional changes, incrementally. Restructure your site map as needed, change the functionality that needs changes, but do these gradually and incrementally. This is where the real change happens, but it generally won't be perceived by users as a "redesign" because it all looks the same -- bits and pieces of it just work better every time you do an update. Doing this incrementally means you have the opportunity to get user feedback as you go, and back out mistakes before you've committed too heavily to them. It also mitigates the change resistance on the part of the user, because you're not changing everything around on them, you're just improving bits and pieces.
0

If the Old Sections are not available when New Sections are rolled out then put a "sticker" on the New Sections that gives a brief explanation and a link to a more detailed explanation.

New look sticker

I suggest acknowledging the mental effort the user has to make during the change and particularly the transition period and why you think it's worth it.

When there are more New Sections than Old Sections take the "sticker" off the New Sections and put a "sticker" on the Old Sections that state something like "Bear with us as we update the rest of the site".


However, the ideal situation is to give your users the option to upgrade to the new design, or at least ease them into it. Different people have different tolerances so having both old and new designs available at the same time is optimal.

To do so, default to the old design and put a "sticker" that entices users to try out the new design on the Old Sections that have a new design available.

Old design with "sticker"

.

Then, on the new design, ask the users if they wish to load the new design by default when available.

New design, with permission popup

Once a user chooses "Yes" or "No" you no longer need to present her the "Preview" sticker.

Do this until the entire site is redesigned, then roll out the new design as an upgrade.

  • So I really like this approach, with the only caveat being that the old section the new section is replacing will not exist anymore. There would be no option for the user to BETA the new section (this is mainly because of the extensive database redesign that's involved in this project... it would be impossible (or at least undesirable) to maintain both at the same time). – eRocket Dec 8 '16 at 15:55
  • 1
    This won't work. They're designing new functions in a new design, and have the old functions in an old design. Your method requires crossover; either by duplicating old functions in the new design, or by making the new functions in 2 styles. – PixelSnader Dec 8 '16 at 16:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.