Explain The Changes #

Making changes to an existing system is harder than delivering a new feature because your users are already familiar with certain features, and workflows, and because you have to work with an existing thing that is interconnected with the whole system.

We are creatures of habit and once we solve a problem a certain way, and unless it is a tedious process that we put up with for lack of other options, we want to keep what works as it is because it is familiar to use.

For this reason we have to plan and make sure the amount of change that we are going to introduce is a digestible amount for our users and also if it something that is bothering them or something that we think we can do better but actually nobody wants, needs and we risk to alienate our users because of changes that were nice to haves but not needed.

We can differentiate between two types of changes, the look & feel and the functionality. The more you change of one the less you can change of the other because if you attempt to do both at the same time, your users will to re-learn how to use it from scratch because they won’t have the visual familiarity and have a lot of functionality that they don’t know what it does.

Scoping the changes to either be about the look & feel or the functionality gives your users the opportunity be amazed at the new design while having the same functionalities and nothing new to learn or explore the new functionalities while being familiar with how everything looks.

If you end goal is to refactor the look & feel and the functionality of a feature you have to keep in mind that the pace at which you make the changes is influence by how much your users can absorb at once. Even you have everything ready from the get going, you should split the refactoring into releases that have at least a few weeks in between them so that your users can get familiar with the new look & feel or have the time to learn the new functionalities.

A good way to bring everybody up to speed is to compare between the old and the new implementations to help bridge the gap created. This list should include what was originally available, what has been removed and what is being added. Adding examples of how it impacts the end user is a nice touch that should not be overlooked as it provides clarity to what can no longer be done and which are the new possibilities.

Working this way, also helps the people who will work on the refactoring because they will be able to compare and ask themselves “Does it still look like before but does more things?” or “Does it still have the same functionality but looks different?”. This will ensure a greater quality in the end result because it makes clear to everyone what is the end goal and what should guide their decisions.