Updating Our Design System Post-Acquisition: A Tale of Swift Rebranding
We navigated uncharted territory in a rebrand by creating a process that was tailor-made for our unique situation. This was done in two months to update our fintech portal’s UI to match with the parent company.
By Federico Marroni and Katherine Lu
Situation
Vermietet.de, a startup that addresses property management in Germany, was acquired by Immobilienscout24 (IS24), Germany’s largest real estate marketplace. After acquisition, it took about one year of negotiation before push came to shove, and finally it was decided:
The designers are tasked with a rebrand!
In a team of three, we came up with a timeline by working backwards from the deadline. The goal was to be as speedy as possible as we had to rebrand the entire portal and while we were at it, create a design system alongside this endeavour. Up until this point, we had a small working design system set up by one designer, as a design system had not been considered a strategic priority by the organisation.
One of our main challenges was how to integrate our parent’s company design system to our needs, as the plan was to integrate two tools that had very different use cases.
In a sense, we faced a new problem:
How might we incorporate brand in a portal-type tool when the brand guidelines don’t directly apply to a fintech portal?
How to include the new primary colors? Our original primary color was blue, which was used as a background, to color icons, alerts and also our primary CTA. We could not simply adopt IS24’s primary color or else we would run into color contrast issues, not to mention the portal would be very teal!
How to adapt our current customised components? in Vermietet.de, we had a number of components that were not available in IS24’s design system.
What would be the quickest wins, we asked ourselves?
During our talks, we defined the touchpoints for designers, working meetings to unblock and approve each other’s work (as we would all be using the new design system), and carve out milestones for us. In the meanwhile, another designer researched the best options for existing component libraries to adapt for our needs. In the end, we went with Material UI for Figma because it suited our needs well with its range of components that were easy to customise.
We adoringly named our Design System “Chameleon” to represent the quick change of the portal’s original skin and color scheme to the parent company’s new one. (Also, chameleons are super cute and make for a nice mascot.)
The way we divided the work was based on the file itself. We each claimed different components to re-skin, and asked another designer to approve our update. We also needed conversations on main elements of our portal, like navigation elements, as there was no equivalent on the parent company’s side.
To prioritise components (from atoms to templates) we considered the product as three layers.
Level 1: what site visitors would see during the first login or session
Level 2: The beginning of user flows
Level 3: granular pages and smaller actions that seasoned users would see
We considered this process to yield the highest impact, as we wanted to prioritise aspects of the portal that would have the most eyes on it, and also be able to communicate to users as soon as possible that we were going to have a new look!
Engineers obviously were also essential to this process, and so we also worked with the two main frontend engineers on this project to check if the way we broke down the process made sense from their point of view, and would give them enough time to develop. Most of the technical foundation was there as our team of engineers already pull components from Storybook. Still, it was time consuming and company wide agreement was needed to understand that designers were supposed to allocate the majority of their time for the next month on this.
Encountering Gray Areas
As we got deeper into our rebrand project, we learned a lot of the styles could not be applied 1:1 because there was no equivalent. It was like making a square peg fit into a round role. This was frustrating as there was no time to hash out these differences. As we were pressed for time due to the business need, we simply had to do our best to reach a consensus, and move forward.
Another issue we had faced was the topic of illustrations and graphics. IS24’s illustrations are hand drawn calligraphy-based graphics, which were created for flashy landing pages, as opposed to a fintech tool with emphasis on data entry.
On top of that, the colours designated for infographics could not be applied 1:1 to how we visualised data in Vermietet.de’s bar graphs and circle charts.
In the end, we did our best to make use of the illustrations when appropriate, but continue to face the challenge of fully doing justice to the new brand, simply due to the nature of these two products being different.
Conclusion
Not only did we reach our goals and the deadline, we also discovered that the project boosted our morale as this was one of the most collaborative projects between designers and developers we’ve experienced. We worked together closely to ensure we were all on the same page. Even though communication was frequent, the collaboration went smoothly. And as designers, we learned that fast changes can be easy with stakeholder buy-in, prioritisation due to business needs, and strategic planning.
In the present day, we face common design system issues like maintenance. However, it’s been almost half a year and it has also sped up designer workflows, promoting consistency between design and development as well.
Writing credits to Federico Marroni and Katherine Lu.
