Transforming Legacy Software — the 6 Rs every Product Designer should know

Many Product designers know first-hand the challenges of working with legacy software. This is even more challenging in an era when companies are transforming their business model from dated ‘desktop only’ delivery to cloud and mobile and subsequently Software as a Service (SaaS). While legacy software poses tremendous challenges for development on questions such as what technology will allow platform agnostic delivery? What aspects of legacy technology can be re-used? How can we venture into unknown territory of cloud and mobile? So too, product designers face similar challenges such as what should the front end look and feel like? What delivery platform needs to be considered? How will the UI scale? What design principles should guide the process? And mostly what’s the starting point in this rapidly shifting landscape. For mnemonic purposes, I refer to the 6 Rs of Product Design in transformation of legacy software for cloud and mobile.

1. Research — Undoubtedly one of the first discoveries I made about the legacy software worked on over the years is that for every Goliath legacy software, there are many small start-ups that have made a name on offering only one of two functionalities offered by legacy software, enabling them to move much quicker and also keep up with newer technologies. In some manner, you can imagine a relationship akin to a piece of Swiss cheese with many holes in it where the holes represent new startups doing less — often better — poking holes into the pocket books of older and dated software. Not surprisingly, many new and younger users gravitate to the newer more modern looking software often decrying legacy as stale and harder to use. And as ease-of-use becomes a critical selling point today it is ever more important to research your products’currency in the modern market. Consider researching the top 3–5 newer and competitive software — what are they doing better or worse and how can you re-design to meet, and better yet surpass the competition as you transform your software from old to modern?
2. Reach out and up — Legacy software comes with legacy people who deserve the respect of having gone before you. Often these are founding folks who have very high stakes in the software and no interest in ‘rocking the boat’ as things have “always been that way” After all, their careers may be threatened by initiatives to transform the product out of the dark ages. While legacy folks bring lots of knowledge and may be able to provide insight into the reasons for certain design decisions, be careful to not fall into the cracks of legacy thinking, making design progress difficult. Reach out and reach up to the stakeholders with your interest in progress. Align your energies and thoughts with those who do as opposed to those who bask in the glory days of the past. Reach out and up to those who can support the task at hand — akin to renovating a very old house.
3. Re-use & Re-structure –Faced with the challenges of reviving legacy software, consider what elements, if any, that can be re-used and re-structured to provide added user value? This could be anything from menu structures to layout preservation. Look at what has worked in the past for your users? What elements have a higher frequency use? Always keep in mind that like an old house, legacy software has the good, the bad and the ugly and working with it is sometimes like rewiring knob &tube with the electricity turned on. Remember that at some point it was a useful software to core groups of users. At a tactical level, one of the common themes I have seen in my years as a product designers is the cluttered look of feature pack software — trying to put all functionality they can on one interface. A great re-use and restructure example is what I call “workspacing” the WYSIWYG approach to design. Users of specific levels of experience or specific (as seen in the Adobe suite of products) workflow specialty may only want to see only the functions they need and nothing else. Both Adobe and Autodesk have done this nicely — allowing users to select workspaces for better efficiency, without all the clutter. Taken a step further “workspacing” allows for sleeker UI delivery in fluid UIs — limited real-estate can benefit from knowing all the tools are there but not necessarily clogging the interface at the same time, especially on a smaller device.
4. Retire — This is perhaps the most controversial and stressful part of the process for many product designer. You have done your design research (hopefully) and you discover that some of the features that fall low on the totem pole of usage should be retired. You have logged a story after discussion with your team to retire certain features. You then open your email and not everyone is pleased. Legacy employee #9 remembers putting in that feature for a client 20 years ago and insist that it is still useful and needs to be put back in. This is a never-ending occurrence in the redesign of legacy effort. Or even seemingly smaller design issues that an icon was moved to another location and the sky may fall and users will be in an uproar. While both points and others like these may be valid for issues of perceived use and muscle memory, respectively, sometimes an executive design decision, steeped in good research and progress, is needed. No one likes their work retired.
5. Redesign — At some point you would have presented your strategic vision for where the software can grow in product experience, and how cloud and mobile versions may look alongside the competition. Now it is time to lay out a tactical plan of design execution. Does your team have the talent to design for new forms of delivery? Can they re-skill? What should an evolved design look like? Undoubtedly the underlying technologies will change to support web and mobile but how will the front end product experience change? Consider a redesign that respects the legacy elements that worked and how they can be situated in web and mobile technologies without losing the core product DNA. While some of the visuals will change, the manner in which a user accomplishes a task may remain the same — if it makes sense. While all good design relies heavily on agnosticism as a core tenet, respect the interaction models of varying devices. Ensure that your design will allow iOS, Windows, and the major operating systems no shock of use and that users are able to use native features and interaction to accomplish their tasks.
6. Real-Estate — Designing for cloud and mobile can pose challenges as legacy software presupposed set UI frames in which a design would fit. However, today many users will move from one device to another using the same software, performing specific task or a subset of the task. This means that the amount of space or real-estate is fluid when users interact with our software. The real-estate continuum from low-end feature phone to high-definition tablet and laptops requires design consideration. Any graphics used must be able to scale on demand. While the back-end should support the seamless delivery of the appropriate graphics sizing according to built-in auto-detection of device and OS, design must be diligent in designing the appropriate duplicated graphics in various sizes for the many devices so the product experience is preserved as intended regardless of the interface size.

Hope this was helpful to my design peers! Keep your dream job alive!