genesisWorld
How do you do a facelift for a 30 year old software?
When it was created, the software was destined to rule the market. A real customer management powerhouse, making an impact on how businesses handle their customer data since the nineties. But as time flew by, even though it grew with many new functionalities, it’s appearance remained the same.
Funny how aging works in tech, isn’t it? If a 50 year old person would look exactly like they did 30 years ago, people would think they are young and beautiful. But if softwares keep their old image, they become quite outdated and unattractive. Well, trends come and go, but there is a huge benefit to rethinking our old choices in this field. If you keep a simple but user friendly interface, optimize old workflows and seek better technologies, you can keep a product young and fresh.
We can’t just change everything
Sometimes to update a huge product is simply not possible. But we still need to freshen up what we have. What can we do then? Ah, a facelift!
A facelift means that we do not want any structural or interaction changes in the product, but giving it a new outfit.
Stripping the old design to make room for a new look
Risks
People sometimes have a hard time adapting to change, especially when they are powerusers of a product. When you do something over and over it becomes muscle memory and you almost don’t have to think about how to complete the task. With a fancy new look, even if you don’t change anything integral, you may give the impression that the whole product changed.
This is both a positive and a negative effect. You want to avoid confusion and the frustration of the users that they might not find the usual functions. But also change can be great for business as the users may feel like they get a fresh new product for their money. This is especially true when you deal with something that has been designed in the 90s.
The plan
After clarifying the business goals and the direction we want to take with this project, we set ourselves to building vision screens for the UI. The only exact request was to have a style that follows the current OS aesthetics with rounded corners, soft shadows and clean design. Since our software is only compatible with the Windows operational systems, it had to adapt to this one platform alone. After some revisions we had the winner style and we could start building the main elements and screens.
Icons-shmicons
The system had around 1000 icons (how on earth, right?) and most of them had to be remade. In pngs. In multiple sizes. Yep.
Firstly, I had to get a grasp of what I have to work with. The old icons were to be found in different folder structures and all kinds of formats. I gathered and quickly dropped all of them into Figma. I clustered the icons by type, their places in features and use. It turned out that many of them were resized copies of an other. So then icon paires were formed, the pairs then were grouped in with the similar kinds, and ordered in neat columns.
With help from an expert of this product, I managed to sort the icons by priority. This meant for me that A priority icons would be needed first and in most sizes and colours, then Bs were next in only one colour and lastly Cs were the nice-to-haves. All of this work helped me greatly to see the scope and to be able to plan the whole design process ahead.
Guidelines
I had to make sure that the new modern design was true to the DNA of the product and kept the symbolic connections of the previous one. Users over the years got used to these images and I did not want to alienate them with unusual symbols. The most important task here was to create rules for the new icon design. This was necessary because we want to make sure that every icon is consistent in structure and quality regardless of which designer creates it. Also it is a future-proof method, as it can be replicated any time the need arises to.
The design guideline consisted of: Sizes, Grids and guiding shapes, Colours and where to use them, Symbol creation best practices, Export settings
Work work work
After a couple of trials and refinements of this method, I held a briefing to my design team. There was nothing left to do but to get our hands dirty. We blocked the whole day for an icon-drawing marathon where we tried to create as many icons as possible. This was a huge team effort and at the end of the day I really felt proud of us.
old
new
old
new
Challenges
The hardest part of the project was the fact that this software was hard-coded in Delphi and any change took serious labor to make. Therefore we had to be very thorough with our design decisions and minimise the chance of double work and last minute changes. It was essential that we have a great communication not only on our part to let developers understand our decisions but to have feedback whether or not our ideas were technologically feasible.
Results
The release was successful and this wind of change made way to open discussions on the redesign of the other existing CAS products. This however is a long journey and we still are at the beginning.