Designing new interface for a legacy web application

Question

Current situation:

We have a legacy web application. It is been in development for 5 years and already has many customers. It's a very critical and also expensive product and its customers are big organizations, including the government.

At the start of development, the team didn't have any UI/UX designer and each developer did all sorts of work, including back-end and front-end.

Problem:

Customers are not satisfied with the current UI/UX of the system.

Questions:

I'm supposed to address this problem. Now I have many dilemmas and decisions to make.

1. Is it better to make changes on the current UI and improve it, or to design a new interface from scratch? (the current design is like '90s designs and making big changes is almost impossible, especially when changing the UX)
2. If I'm better at designing a new interface, should I use pure CSS or frameworks like Bootstrap/semantic UI or use an admin template from ThemeForest?
3. What's the roadmap for this change? Like, understanding the current system, sketching new designs, implementing a new theme, applying it to the system... Should I apply it to the system or should the developers? The current system used the classic approach for its implementation, I mean it's not SOA and it's not easy to change the theme. Plus, the front-end code is mixed with the back-end. (Django template builder)
4. How to deal with customers? Bringing such a major change is kind of challenging and may have a bad effect on customers.
5. Any other tips that I should know about?

Thanks for your time.

Answer 1

Bringing a fully new design can be catastrophic. Even started over is bring good things, it takes time. So much time. You need to address every mental modal that your customer created with the new design. This is a long journey and can hurt many users.

Instead, you can work on things that can work both for old designs and the new one. This approach will give you time to make decisions based on each part of your product and can be reversible easily. I'm working at OpsGenie nearly 2 years, And I've started to change user interface 2 years ago with this approach. We managed to change our application user interface, public pages, and mobile designs. We've done it brick by brick: applying new features, changing odd behaviors, taking feedback from our customers.

If you want to change things. You should ask yourself when and how you need your product. If your product is constantly changing use the second approach, if not make a big change while addressing currently used mental models with the new design.

Here are my stories behind Lean UX approach: https://engineering.opsgenie.com/lean-ux-or-how-i-faced-a-living-product-and-prepared-a-design-delivery-roadmap-b0ad2c77b515

https://engineering.opsgenie.com/mental-models-and-how-we-are-shaping-new-application-interfaces-at-opsgenie-6dfd41ea7ace

Answer 2

Putting constraints aside for a moment, I think it's super valuable to show the team or organization what they could have if you started over. The Blue Sky approach if you will. It gets people excited and gives you the opportunity to pick a couple big-ticket UX items and show how you would solve them, really showcasing what good UX can do. This means more work for you obviously as you must design this vision. It's a great accompaniment to initial conversations.

The other approach is trying to fix usability issues bit by bit without a big overhaul. This means you need to target all the little usability issues in the UI and prioritize them in some way. Pain point mapping is helpful for this. This approach has a less short-term impact in terms of cost but likely will not improve usability as much as you are still constrained to the current UI.

A mixed approach is picking off parts of the UI to redesign and build piece-by-piece. I.e. let's say you redesign and develop the navigation or a search results page, etc. This can be messy as you are introducing new UI elements in an older interface and you will have to live with inconsistencies for a while.

The roadmap for approach one (Blue Sky approach) should lead with a design exploration phase where you explore and test a new UI and get feedback from internal stakeholders, including technology. It's really a group effort and the final designs really define the rest of the roadmap. From there it's a matter of building in whatever software development process you choose. This, of course, oversimplifies the overall process but the point is to define the new UI first, then figure out with your team how to build it and start breaking the project up into Sprints (or however you work).

Answer 3

a. If you dont have it, install on your site Google Analytics and Mouseflow. Make sketches / document with main user flow based on results from this two tools. In Mouseflow you have also live video session you can look for.

b. If you have some successful flows and patterns in your existing designs, try not to change lot of theese in your new design or try to mimic them. The rest you can redesign from scratch.

c. Create low fidelity paper prototypes, communicate development in this phase. After when you are mostly settled over UI, create clickable high fidelity digital prototypes (can be also close to final designs, with styles and everything), you can use Sketch and Invision for tooling i.e.

d. Pick 5 participants that dont have lot of connection to your company, make a list of 5 tasks for them to perform it, and test your clickable prototypes. After the session, track how sucesuful they were, and ask them opinion on design and experience (u can find thoose questionares if you google Qualitative UX tests i.e.). During sessions dont lead them, and dont help them by words. Use "think aloud technique", ask them to talk while they are going through your templates and clicking to get task done.