Have you ever given up on using an application due to poor performance or because it took too much effort to navigate? Or have you found yourself in a situation where you are commenting on the bad UX of some application?
While many applications have teams of people working on usability and design matters, there are also projects where design was not in focus when they were first built. Especially if those applications are low budget, specialized in a certain field, or meant for an internal group of users (e.g. within one corporation or institution), there is a good chance that their UX is not the best. The users are also likely already used to the look and feel of the application or well trained to use it, even though such an application does not adhere to some commonly recognized standards.
Here at Atlantbh, we have taken over several software development projects for products that have been built by our client’s internal engineering teams, or their previous partner companies, and have been in use for years.
The early development for those products did not include a budget for UI/UX, so the applications were not so intuitive to use and required training for new users. Despite the issues present, these applications are important and extensively used daily.
However, while that was only the user impact, other arguments helped us decide that redesign is an excellent decision. You can find the checklist that will help you decide if your product is an ideal redesign candidate in one of our previous blogs.
In this blog, I will discuss what is important for the Product Owner to keep in mind through the redesign process.
Connecting the Dots During the Redesign Process
Suppose the Product Owner realizes that too many compromises are being made for new requirements that cannot fit into an existing design and the situation will not improve for the upcoming features either. In that case, it is probably time to consider a redesign.
The first important thing is to get aligned regarding the reasons as well as redesign goals with the team and the client. All sides need to understand why the application needs to be redesigned and if it is important to have it now, at this particular point in the product development timeline. Clients must understand the purpose of redesign and support it. There has to be a mutual agreement on the scope of the project e.g. whether it is just UI reskinning, or some features will be changed or even the whole processes need to be designed differently. Potential risks need to be evaluated, first internally and then transparently towards the client.
Secondly, it is important to decide whether the previously formed backlog will have to be postponed or included in the redesign scope. Having an important feature clients want in production as soon as possible could be challenging since the complete redesign could take several months to implement. So there should be an agreement on whether to start working on redesign at all before those features are completed. If everyone agrees to deliver them first, there should be mutual awareness that those features would have to be re-implemented later on to fit the new design.
Another important step in this conversation is considering the client’s plans. The redesign plans need to be aligned with the clients’ vision of both application branding and the timeline for its implementation and release to production.
We at Atlantbh hold transparency in high regard, considering it among our most valued traits. In such situations, clients must be informed and aligned with the amount of work that redesign might take and kept close by for feedback during the whole process.
Going forward with the redesign plan, the Product Owner needs to keep the rest of the team in the loop since early feedback on what an achievable goal is is valuable, especially at this early stage of defining current pain points and scope.
This kind of transparency is always good since it brings different perspectives and experiences. While designers know the UI/UX standards, developers and QA engineers might have some information to share from logs, analytics tools, or production issues filed before, where they recognize patterns of where users encounter problems in the application.
In the actual application redesign phase, good collaboration with the designer in the team is crucial since the result of that communication is the new look and feel of the application. In cases where an application did not previously have a designer, the person assigned to the project will need a detailed walkthrough of the application vision, mission, purpose, and the implemented business logic. To balance out that effort, bringing in a fresh pair of eyes could bring multiple benefits to the result the client and team are looking for.
After setting the foundation for this collaboration, depending on the scope and type of problem being resolved, a design sprint can also be organized. If you want to know more about the design sprint process for a redesign of the application that we established at Atlantbh, make a small detour to read this blog.
Keeping The Mind Open to Change
While working with a designer on a redesign project, the Product Owner must make sure to keep an open mind to changes and different ways things are perceived.
However, this is not always as straightforward as it may seem since it could often be a project Product Owners work on for years. They are used to how things work and the reasons behind them being the way they are.
This is also important because users might be well-trained to use the application as it is, and a radical change might not be well-accepted. In this case, the Product Owner is the voice of end users, clients, and the product itself. Knowing the application, its history, and how it is being used will bring real-life context to the process.
The most challenging part might be making peace with the freedom a designer needs for the creative process to take place, and those constraints in business logic, scope, and engineering itself. Some solutions designers present would look good on the UI but would not add value to the purpose of the product or will miss the information users previously had. Others would overextend the scope or would not be technically feasible. There are also some experiences that are important to keep the way they are for the current users, which is something a Product Owner would recognize. The redesign process can be a slippery slope. If we are not focused on the identified problems we are hoping to solve, we can move away from our goals and try to solve many more problems while we are at it.
This is why constant communication between the designer and the Product Owner, often with consultations with the engineering team, is required to ensure we develop relevant and technically feasible proposals. If a feedback loop can also be created with a client to show them work done in iterations, the chances of getting a completed product design faster are higher. In applications with internal end users that are easy to reach out to, usability or A/B testing can also be done to evaluate the proposals for new design. This is a luxury the project might not have had in the first place.
If redesign of the entire application is being done, this is not a development effort that can be completed in two-week sprint time, nor is it an item that can be delivered in sprint increments. While engineers can use redesign as an opportunity to reimplement and improve certain technical solutions, assessing whether these efforts will broaden the scope and introduce unnecessary complexity to the process is crucial. You always need to keep things on track, as hitting two targets with one arrow can lead to not hitting the target at all.
Once the redesign comes to a development phase, a part of the team might still have work to complete on the current production version of the application. So the Product Owner needs to be involved on both ends to ensure the active sprint deliverables get completed in time, while having as little throwaway work and as good backwards compatibility with the new design as possible. If you want to know more about how we manage two development tracks and backlogs while still using Scrum, consider checking out this Tech Bite.
The Product Owner is there to solve problems that challenge their product and clients, and provide additional capabilities in the application, while always keeping in mind the future and prospects of the product.
However, it is also important to step back from time to time to see how the application evolved, where it fits in the fast-changing business domain, and if it is still fulfilling its mission.
Remember that redesign does not always mean changing the entire application. Its scope is defined based on the needs of the product. While this blog was focused on redesigning the entire application, all points from previous sections can also be applied to a single screen or section of the application.
A simple redesign in terms of e.g. reordering UI elements, or exposing additional information can drastically change the user experience and help unlock the potential for new features. However, it is up to the Product Owner to recognize the scope of changes that would offer solutions to present problems.
Starting a conversation on redesign is never easy. Benefits are often quite abstract to explain and understand at first glance. A Product Owner’s role is to find the right way to share the vision and convince the clients that it is the right direction to take. Even then, redesign is always followed with great expectations, a need for a deep understanding of the business domain and connecting different stakeholders and tracks.
It all makes the Product Owner an extremely responsible role, especially when investing energy to transform the entire application.
If you found this useful, check out other Atlantbh blogs!