A Design System is a product.
It has users and so needs resources.
A design system isn’t a sketch/figma library. But it’s a good way to start.
Salt Design System SDS
During my years at Ocado Technology (2016 to present), I had the chance to create, maintain and scale our design system: Salt.
It started from the necessity to align a few designers together, and rapidly grew into a common language shared between Engineers, Designers and Product Managers alike. We’re not done yet, and we have so much more to do, improve and document.
Accessibility, maintainability, scalability… these aren’t mutually exclusive but when it comes to Design Systems, they are a constant challenge to reconcile. Our Salt DS needed to allow Designers to create new solutions in the least expensive way, avoiding extra development on new custom components.
Yet, every problem is different, and that tension between reusing and creating custom things is a hard one to solve, and often the start of passionate discussions.
No magic here, just a good dose of collaboration.
A single language
Working on such a huge product as the Ocado Smart Platform, the Design System aim is to become a shared language between all its stakeholders. A way for users to recognise patterns and find ways to fulfil their mission in a consistent and delightful way. A way for our retail partners to understand how new features work instantly, making them quicker to explain to customer care agents. A way for the UX and Product team to take decisions that would shorten development time. And more importantly, a way for engineers to update our front-ends, without wasting time in coding the same things over and over again.
To support this vision, I advocated for the recruitment of a dedicated UX resource to the Design System. Today, we have 4 full time designers working on our Design System, and engineering is following our footsteps, creating the first front end Design System team in Ecommerce.
