When discussing software, arguments on what is visually and functionally “good” can be subjective. While UI/UX principles offer guidance, recognizing the need for a redesign goes beyond design standards.

Decisions on starting a redesign are made based on the different perspectives of Engineering, Product Management and UI/UX, with additional factors such as the impact on users and their productivity, cost and resources.

If an application is being developed for years, the complex UI and technical debts make it hard to keep building on such a product. It requires a significant increase in engineering, UI/UX and product effort, also leading to demands for more time, higher cost and scope of just about anything being added.

Such issues signal that it is time to take a step back and consider redesigning the application.

This blog will discuss important characteristics that make an application a good candidate for redesign.

Ideal Redesign Candidate

  • There is a need for training -> Applications with poor UI/UX often require users to undergo a training process. A well-designed application should be intuitive, even if it serves some specialized purpose. The right question to ask is – what can users achieve on their own before they attend a training?

  • Affected user productivity -> Does every action take more steps than necessary? Is it intuitive to understand what each step means, and is any of them redundant? Do users have a hard time navigating different parts of the application? Is error handling clear enough for users to understand the current state of their process and navigate away from the undesired actions? If the answer to some of these questions is yes, you should probably consider redesigning your application.

  • It is difficult to fit in new features -> If the Product Owner is forced to compromise while solving a present problem at the expense of the business goals, it is time to consider redesign as a precondition to proceeding with the solution. The purpose of the product and the needs of its users must be a priority.

  • Outdated design -> If the application is not public-facing, it can handle some parts of the outdated design, under the assumption that the users can still efficiently achieve their goals. However, for an external application, if you want to keep up with the competition, it is important to keep track of UI and UX standards.

  • Lack of consistency -> Users should be able to find similar actions grouped together or in the same place in all parts of the application.

  • Change in requirements -> For projects that have been running for years, the product vision often changes gradually over the years. What can often be observed are legacy features or ways of doing things. Old rules and connections between some entities within an application that are no longer in use can change or simplify the business logic used today and save time on both the engineering team and the user side.

  • Performance -> Application performance can depend on how some features are built and can be improved through different UI or technologies used in the background.

  • Technical debt -> There is a significant technical debt from features used a while back that, more often than not, stay in the codebase. The team developing the application might also change, losing some context to the application. Furthermore, if new compromises are being made while forcefully fitting in features, it makes applications more challenging to develop and maintain.

  • Defects – Technical debts and features that do not match the product’s vision or purpose can create different edge cases and bugs hidden deep in the code, which can emerge when you least expect (and need) them.

All of the above connect the pain points a bad application design can have from the perspective of product, engineering and design. And it is visible on the “field” as well – each new feature needs to fit into the rest of the application, so it takes more time and compromises to define it and implement. Such an application is an ideal redesign candidate.

Conclusion

The points above can be used as a guideline for assessing if your application has elements of an ideal redesign candidate, and they worked well for us at Atlantbh!

However, you are responsible for evaluating the actual impact on your application and users. It could happen that the application itself fits into each point in the list, but the impact it will make might still not be reason enough to undergo a redesign. On the other hand, it can happen that you have only one point in the list that is a blocker which will push the redesign to become a priority.

To get approval for a redesign, make sure to keep the bigger picture of the project roadmap in front of you and transparently communicate your vision to clients. But more about it in another blog!

Until then, I hope that the points above will help you look at your application from another perspective, and make timely decisions that will help with the further development of your product.

If you found this useful, check out other Atlantbh blogs!

oban
Software DevelopmentTech Bites
February 23, 2024

Background Jobs in Elixir – Oban

When and why do we need background jobs? Nowadays, background job processing is indispensable in the world of web development. The need for background jobs stems from the fact that synchronous execution of time-consuming and resource-intensive tasks would heavily impact an application's  performance and user experience.  Even though Elixir is…

Want to discuss this in relation to your project? Get in touch:

Leave a Reply