אין עדיין תגים.
So you have a running application, more or less established in the market. You have customers and users and everything looks just fine. As always there are numerous features you wish to address, customers’ requests and bug fixes that you aim to add to the next cycle. How will you know it’s the right time for a major redesign? How will you know that you should prioritize the UX enhancement? How will you know that fixing a few UI bugs is not enough?
(The video is in Hebrew and contains English subtitles)
From my experience with existing application redesign I think there are some significant considerations you should keep in mind when thinking about focusing on UX improvements and allocating resources for it. Most of us will agree that a 5–8 years old application is considered out of date. But when is “the right time?”- Here are some “warning signs” you should consider while doing so.
1. The Users
If users have hard time with main use cases in the application
If you have many support calls about the UI
If some of your users are not familiar with important features and capabilities
If the users feel that the system is complicated and do not perform flows in the most efficient way
If they say they consider trying your competitors due to their UI
If this miss the past version/ tool they used
If working with your system makes them unhappy, angry or frustrated
Every UX junior will tell you that user feedback is very important for the success of your UX. You should collect this data and analyze it and if these critical point emerge they should be considered comprehensively. I recommend different stake holders will meet and listen to users (and not just PM/ Customer success/ support etc.) in order to understand their needs deeper. You could use feedbacks sessions, surveys and support statistics in order to further understand the origin of the issues and weather this is really a UX matter.
I recommend different stake holders will meet and listen to users (and not just PM/ Customer success/ support etc.) in order to understand their needs deeper.
2. The competitors
If your competitors released a new UI with major UX updates
If you have a new and fresh competitor
If your selling meetings get harder due to old fashioned UX
More and more clients raise point regarding the UI and UX in your talks
If there is a decrease in sales that might be due to the UI
All these signs could lead you to the decision you should do more than minor UI bug fixes. I advise you to review your competitors’ UX and try to assess its strengths compare to your application. If you conclude your competitors has a much better user experience you should prioritize your UX.
I advise you to review your competitors’ UX and try to assess its strengths compare to your application.
3. Frontend/ UI rewrite
If you are planning a major rewrite of the UI for technological reasons: moving to a new technology, additional web or mobile platform, creating an add-on or writing your interface as part another platform.
You created the application in fast pace (maybe for investors or an eager customer) and now you should build a full blown UI.
All these cases are a great opportunity for your product and your User Experience. You could, off course, decide to implement the UI as-is and reduce the cost of the UX process. From what we know about UX ROI and from my experience this reduction will be easily covered after the application is live. In most cases a company decided to write the interface when the code is old and complex and –this will inevitably result in an old fashioned graphic design. In addition, if the UI was initially created years ago the users’ needs and expectations changed during this period and you understand them better. During these years the user interface features were patched together and this is an opportunity to organize the user flows and use cases. Above all that, a UI rewrite in a new technology will lead to changes in the UI controls and behavior. I believe it is best to leverage the UI change and plan a better UX systematically, in high level, from scratch.
UI rewrite in a new technology will lead to changes in the UI controls and behavior. I believe it is best to leverage the UI change and plan a better UX systematically, in high level, from scratch.
4. Major change in the backend
If you added a new significant capability to your product that changes the system offer to its clients, you target a new market or customer’s type.When the change in the engine is minor you could easily encapsulate it to the existing user experience. If you change the backend due to a big functional addition, I’d consider the effects of this change on the users and consider the need for a UX process.
5. Size of UX change
Last note- if you did decide to update your user experience you should consider the amount of change. A UI change could be only a graphical face lift or a more in depth change of the user use cases and flow and the user experience as a whole: A graphical face lift demands less resources and is easier to implement and it has a high marketing value. However, it will not lead to a better, more user friendly UX.A full UX process will include user’s analysis, competitor’s analysis, tasks and use cases while prioritizing them. In addition to these stages that create a easy to use user workflows the graphic design will be updated. This process will lead to a maximal improvement in the UX and the product strategy. I advise you choose this option if several of the points raise above are relevant for you.
A graphical face lift demands less resources and is easier to implement and it has a high marketing value. However, it will not lead to a better, more user friendly UX.
I’d be happy to hear your thoughts. You are welcome to comment and share.