How we adopted the open source Ant Design System and supercharged our effectiveness
Design systems are cool and extremely useful, but we do not always have the time and resource to build one ourselves. This is a story of how we defied the odds and adapted a public design system
History of the problem
The clock was ticking.Tensions were high. In the cold, dry atmosphere of the air conditioned office, sweat gripped the mouse more than the hand did. Friday was near, and the end of the sprint was approaching. Screens were needed. Developers were getting ready for the hand-off, and the product manager’s watchful eyes felt like omnidirectional closed circuit surveillance cameras watching every click of the mouse. The page froze, triggering a refresh. A component was needed.
“Where was it? Where was it kept? Did I create it? I need that button now.”
“Heck, I’m just going to duplicate this other button and change its colour.”
“What the heck? Why is she using #ABB2B2 and not #ABB3B3?”
“Why is this #818181 and not #808080?”
“It’s okay. Consistency. I’ve gotta keep it consistent. It’s #ABB3B3 and #808080.”
Times up. “I have to submit this now. We’ll see if the devs can figure… ah never mind. Problem for another time.”
Was that what went on in the minds of the pioneer members of the design team when they were rushing to ship high fidelity screens to meet the timeline? I can only imagine.
In the early days of our product, two designers worked on totally separate experiences of the platform, with promised regular sync ups. It started with clear communication, guidelines, and a load of excited energy to build something big. However as the days passed and pressure started to build, the sync ups decreased in frequency, and they eventually ended up operating in two separate silos. Being inexperienced designers working in a fast-paced environment, it was forgivable, though many steps seemed to be skipped or missed out entirely.
Little was it known back then, that every little misstep would imminently snowball into a huge, painful problem months down the road when new designers came onboard (myself included) to start building feature updates and usability iterations on top of a brittle, hollowed infrastructure.
Allow me to digress and talk about how Stephen Covey’s principle of effectiveness from The 7 Habits of Highly Effective People has shaped how I view and take on workplace challenges, wherein this case, about design processes. Grab your coffee and let’s get rolling! ☕️
The principles of effectiveness in design
I believe that it is a common problem for product designers to struggle between speed and scalability in design, especially with small teams. Be it pressure from product managers, stakeholders, or members in the organisation who do not have the understanding of the importance of going slow and steady with good foundations, designers can tend to be pushed to churn out screens efficiently in high speed today, but sacrificing the effectiveness of going far with what they have built for tomorrow.
When you go for efficiency, you kill effectiveness.
What it means — and costs — to be efficient
In an ‘efficiency focused’ design process, the focus is on the now. What matters is the deadline in two weeks, not where the design will be in two years. More often than not, every new component created only works on the screen they were needed for, and not if they can be reused seamlessly in the next product iteration. Pages and pages of design components cater to every different product feature, but with little to no value for reuse or recycle. Design guidelines are created for specific scenarios, and not as an entire product in mind.
Imagine if every Lego set was made with new bricks, where the ones from past generations basically become obsolete.
Why effectiveness is important, especially in product design
Effective design focuses on the now and how it impacts the future. Thinking and working effectively means sparing the time to prevent problems from arising in the future. What matters is not just the deadline in two weeks, but ensuring the components we create fits back into the greater system of design (aka design system) that runs across every vertical, feature, page and interaction. This provides the ability for design components, whether they were created today, or yesterday, to be drawn from and be used tomorrow. As this process continues, the design process becomes exponentially efficient as the product scales. And that, my friends, is effectiveness.
Having had experience shipping countless small scale WordPress projects for clients in the past, long term scalable design has never been something I had to consider. Websites were designed and developed in short waterfall processes, go-lived and pretty much forgotten about by the clients and us. We simply moved on to the next project.
Designing a product is vastly different. Almost every design decision made today could impact something that needs to be done tomorrow, or the day after tomorrow, or the day after that. Heck, maybe weeks later. No, months after. You get my point. 😅
I remember having to come back and answer questions on button sizes when we handed off a fresh set of screens, four months after the initial button style sheet was created.
Now, back to the story shall we?
How efficient design resulted in an extremely ineffective upkeep
When I first joined the team along with a few others, what we picked up from the predecessors was the literal manifestation of efficient design at its best. Scrutinizing the design files showed so many issues with scaling them for updates and new features. At one point, I even joked that we had 50 shades of greys used across various parts of the UI, and more variants of buttons that we could count. There were even different colors for the same buttons! It was a living nightmare. 😱
The real pain arose when we got hands-on in creating new design files using what we had inherited. There was no way to accurately verify the consistency of any particular component across design files, front-end implementations and native apps — just which of a component was the most correct? 🤯 If there was a ‘high level’ change required for a design atom or molecule (following the Atomic Design methodology, which this story by Audrey Hacq details in such an unique perspective), said change had no way to be pushed and reflected across the myriad of screens and files.
Because of how things were not created for the future in mind, we encountered countless crises where additional hours of repair work was needed outside of our already cramped working hours to forestall the inevitable — we needed to rebuild the design from ground up.
Our ambitious but futile mitigation plan
As with any startup, time and resources were constraints, and nobody in the organisation would buy the idea of prioritizing a ‘design file fixing’ as part of the precious roadmap. 🥲
We tried to overcome this huge problem by organising a proper, uniform design library (we have not even gotten to a design system yet 🤪). We consolidated and reviewed every single component that has been made into one organised file, where the goal was to eventually sync it up with the developers’ front-end component library and turn it into a version 0.1 design system. This resulted in us having to pick apart every screen to pixel-peep component by component to find out which was the right one to be used consistently across all our design files (a problem highlighted in the previous paragraph).
It was an uphill task 😵
We only managed to scrape together a few of these components before our next big crunch, which drove us back into an efficient process as we simply could not beat the problem and the deadlines.
A saviour arrived and saw our struggle through his past experience
It was a matter of time before the problem festered and became an obvious issue: there were too many design churns, and the design machine just does not seem as well oiled as before.
Eventually, and thankfully, a new but experienced product manager who used to stand in the shoes of a product designer spoke up in the council of product managers (this is just me exaggerating it) and made our voices and problems heard. He saw how inefficient the design process has become, and questioned:
Why are we trying to build our own design system? We’re a small startup. We won’t have the resources to do that. Why don’t we use an open source DS?
We must have been fools or overworked to not have thought about this before. How could this idea not have crossed our minds before?! 😧
My quest to find the perfect open source design system ⚔️
After a few weeks of council debates, we finally found the opportunity to squeeze in our plan to rework our designs with a design system. However, time was still against us, as the downshift in velocity in the product roadmap was only momentary.
The enormous burden of journeying far and wide from the desk to seek the one true design system was entrusted to me, Manager of User Experience, Leader of Product Designers and Writer of Overly-exaggerated stories. The future of the design kin in my organisation rested on my shoulders. My choice will single-handedly decide the fate of their day to day welfare for days to come.
I spared no time and immediately started work on locating all the public design systems I could find on the internet. Thanks to that same new product manager, I had a head start on a list of public design systems to explore.
With so many public design systems out there from big brands like Google, Microsoft, Salesforce and IBM, picking the right open source DS was not as easy as it seems. In fact, some might argue that public design systems should be learned from, not copied (thoughtfully debated by Alex MacDuff in his story, Stop using other people’s design systems).
Contrary to the quest I embarked on to find and leverage on an open source design system, I actually agree with Alex. Studying public design systems from big brands could certainly give me valuable insights to continue building our own DS. However, that was not my mission, as we have already established the time and resource limitations we have.
However, just like the many shades of grey in our colour palette, the choice here was not a ‘black and white’ or ‘either or’ decision. We did not have to either copy or build our own DS: we could adapt.
Adapting is different from copying.
How we ended up with the Ant Design System
adapt
verb: to make fit (as for a new use) often by modification
In order to adapt a public DS, we could not just select any of them and modify it to work for us. Each one of them was unique, and the challenge was to find out how each of their ingredients suit our taste buds. 🌶🧄🧀🥦🥑
Just like how humans’ digestive system works, a product’s design system does not simply take in whatever is ingested. A person could be lactose intolerant (I love a flat white too much to give it up, sorry stomach 🤭), allergic to gluten, or simply choose to be vegan, I had to identify what could actually be compatible with our product’s DNA via the design system.
My epic quest then turned culinary.
After studying each public DS I could get my hands on, I eventually distilled down the key ingredients and figuratively tasted their ingredient makeups and matched it against the figurative digestive (design) system of our product.
- Front-end framework
We have an innate allergy to non-Angular DS since our front-end was basically composed with Angular. - Design library support
We use Figma as our primary design tool, thus non-Figma DS will most definitely result in a massive indigestion. - Design language
Our dietary preferences generally prefer something more casual and less like it came from a major SaaS tech brand. - Design values and principles
As long as it was made for humans, it is good (hey did you get the joke here? Made for humans, both metaphorically as a digestible food and also human-centered design? 🤣) - Motion design
We like smooth, natural movement in our bowels. - Community support
If we ingested this DS and run into problems, how easily can we find a doctor?
After much sampling of different design systems, we eventually landed on the Ant Design System as we realised the nutritious benefits of ants 🐜🐜🐜 , — oops I meant,— how suitable Ant was to our product’s bodily needs. Ant boasts a large community base, usage by some renowned products, and also supports our Angular front-end framework as well as having a Figma design library.
Ingesting Ant, part by part🐜
A lot of ground work then needed to be done. Painful as it was, we gritted our teeth and reminded ourselves:
It will have to be done eventually. Better feel the pain now than later.
Adapting the design library
Ant maintains an actively updated Figma library which is free for duplication. This is available from their website and also the Figma community (just search Ant Design and you will not miss it).
We simply duplicated the Figma file into our team project, then published it as a shared library.
The process afterwards was straightforward: find all the components we needed, and style them based on how we needed them to be. That included updating the colour and font styles to align with our brand, followed by some tweaks to the sizes of the core components.
One thing to highlight, however, was that we left the shadow effect styles largely alone, except to change the primary highlight colours of focused objects with our brand colour.
Even though we had a huge head start in building our DS on top of Ant, not everything was adapted immediately. We practised an ‘update as we require’ to balance between efficiency and effectiveness. While building strong foundations was necessary for the future, there was no point creating components that we did not immediately require.
Till today, we are still updating and polishing Our ANT Design library as we continue to iterate the product.
Our hybrid approach
We did not rework all our design files immediately. In fact, our hybrid implementation approach slowly phased out legacy design components as we only used Ant for new product verticals. Updating of legacy feature UI was minimised as we slowly moved towards a much needed refresh of our brand identity, which was the best avenue to conduct a mass revamp of design files and front-end using Ant.
Supercharge to the moon 🚀
The Ant Design System was like a translation device that finally let the developers and designers speak the same language. With the benefit of a ready-made Git along a well documented website of components, pushing design specifications became drastically easier for our teams as they became more familiar with using Ant.
Where in the past we had to painstakingly create every state of a component with samples and detailed write ups on how they should behave when interacted with (which gets increasingly tedious as we move up the chain of Atomic Design components), we now simply identify the corresponding Ant component while providing a mock up of the general design specification.
Not only that, we now have excellent control over the consistency of any UI component, where everyone easily draws from a master library and continually contributes back into. We no longer had any problems with buttons of different sizes, greys of different hex codes, and abomination of page templates put together with incoherent lego pieces.
We started focusing more on the experience, less on the pixels.
As Canva’s success story in building their own design system puts it, our DS helped to establish a single source of truth across the organisation.
Well of course, this also gives the product designers an excuse to ‘blame’ the Ant Design System if a particular UI looks rather rigid and uninspiring. We’d simply say “Oh, Ant Design doesn’t allow us to modify it in that way you imagined.”
Psssss please do not tell my product managers.
Key takeaways 🔑
Although we did not build our own design system, adapting Ant really helped to accelerate our design process. Honestly speaking, if left unsaid, users will not even realise that — heck users probably would not even know what a design system is.
Using a public design system really isn’t that bad.
After all, how different can fundamental components like buttons be?
A button is a button, and adapting the Ant Design System did not restrict us to stick to their style. In fact, we have personalised it in a way it complements our brand and design language, yet still being able to leverage on the benefits of their actively updated documentation and libraries.
What's next? 🤔
The quest to find the perfect open source DS has been an eyeopener, and implementing Ant was an invaluable learning experience. It is unlikely that at the pace we are running in the product roadmap, we will be looking at replacing Ant with our own DS anytime soon.
I would love to have the opportunity to work on a living, breathing design system and grow together alongside it.
And hey! If I can make sense of it, you can make sense of it 🤓
What are your thoughts? Drum your keyboard, drop a comment, and I’ll respond after I have a coffee ☕️
