As someone who designs products for administrators and medical workers, interface design isn’t so simple when applied to those fields. Now, the facts are clear: senior developers now need to realize that sometimes, it isn’t about how they see the problem. With UX receiving increased recognition across many industries, it’s no surprise that “legacy” product teams are starting to see some value in improving their user experience. This also means a massive change (and growth!) in team structure.
When describing big, old, complex software products, legacy products fit the bill. Often mired with complex features and even more complex language, legacy products are difficult to pin down. As a designer, you’ll know when you’ve been given a legacy product: there will be a few things that strike you as “antiquated” or, for a better use of words, “a usability nightmare”:
The use of outdated visual standards. Legacy products usually have their own batch of unique of unique iconography and color schemes complete with no documentation on how they are to be used. This will require your expertise on many levels — and this especially applies if the documentation is not there.
A poor approach to addressing early user pain points. Often built entirely by developers, legacy products can only improve if management recognizes one thing: senior developers need to realize that sometimes, it isn’t about how they see the problem.
And finally, technical language that almost begs to be simplified. Give developers and inch with technical jargon and they’ll take a mile — and not even technical writers are of any help since they often fall into the same confirmation bias. In other words, they will also use technical language because of their history with the product. The problem? New users won’t have the same level of comfort.
As the sole designer on the project, you’ll be responsible for making the product easier to use (and understand).
This means you’ve got to approach this process with a keen sense of what mental models are. These models are a subconscious mode of thinking — it’s how a user believes a product is supposed to look or act. Throughout our lives, we build mental models around simple tasks from how we do our work to how we eat our food. The same applies to legacy products and the language they use.
Since you have little history with the product, you are less likely to fall victim to groupthink, and this gives you an advantage. Now, you can use what you have at your disposal to improve not just the product, but your team’s collective idea of how it can be better.
And given the history of your legacy product, it’s likely that there are a few resources within your company that can help you tackle the feat of simplifying product language. Here are a few that I can note just from my previous experience.
Since legacy products often have more history, help documentation is a given since customers often need to reference this information to learn how to use them. You can generally find this information within the software product or stored within company file managers as a PDF.
Upon first observation, you will find that help documentation serves a double purpose: by educating you on how the product is to be used, help docs also give you the opportunity to re-think mental models. With this in mind, your only limitation is the degree at which the technical writer provides the needed product info.
Never underestimate the value of social capital.
“Collaboration allows us to know more than we are capable of knowing by ourselves.” — Paul Solarz, educator
Not knowing is the greatest gift of all because it precedes the opportunity to learn.
Look around you — the best relationships start with a simple question and can benefit you greatly down the line. You’ll find that people are more likely to help you if you ask them questions about the product and how it works. In fact, it’s well known that asking questions increases likability.
In addition to people being more receptive to you, you will obtain more information that will aid in understand the legacy product you are redesigning.
Legacy products aren’t built in a vacuum — they are created over time and with the input of developers, technical writers, and product managers. As a designer, you’ll need to answer the question: how is this information organized, and where can you find the information you need?
Depending on the products used, the information may be stored in a workplace software product like Jira or Confluence. Some companies have been even known to use Aha!, a roadmap software for product managers. In this case, roadmaps are useful as they provide you with an idea as to how the team expects the product to be developed as time goes on.
The best weapon a designer can use against any legacy product? A good sense of organization.
“Good order is the foundation of all things.” — Edmund Burke
Combat legacy product jet-lag by starting from the beginning and organizing your research notes and other design-related items. You can do this by labeling your files and folders a specific way — numerically, then with the subject matter the folder is dedicated to.
By building this information library, you save yourself time. Simply creating a sense of control within your environment is key. You don’t have to consider every area of the legacy product you are designing as you create this “information library” for yourself — yet. For now, just focus on the major areas you’ll document.
I'm David Louis— a designer who works with startups looking to push creative boundaries