Wolters Kluwer started in the mid-19th century, as one of the Netherlands’ first book publishers. It was officially founded as a modern company in 1987, following a merger between Kluwer Publishers and Wolters Samsom. Over the years, we’ve experimented with other content mediums, including CDs and DVDs. Most recently, we’ve been focused on adapting more “traditional” content to the web.
On the web, we had to let go of the classic book structure and table of contents and focus on providing answers, not documents. For us, the process of connecting the customer with the right information has to be flawless because the people we’re servicing (doctors, lawyers) rely on our content. And they can’t afford to make mistakes.
I work for the global platform organization, one of the few centralized organizations of this company. My team helps Wolters Kluwer business units across the globe understand who their customers are, what problems their customers face, and create the best possible solutions to these problems.
My team operates as an agency within the company. We work for all divisions and our customers are business units in the U.S., Canada, Netherlands, Belgium, Italy, and Germany, among others. The team consists of UX designers, front-end developers, user researchers and product management consultants. We provide services on many levels, all the way from strategy to execution. Design is a way for us to get concepts out there quickly. We measure results, learn, and iterate to ultimately help our customers build the best thing.
Our team started small and grew each year as we engaged with more and more business units. Unsurprisingly, collaboration became tricky. The main problem we faced was a lack of consistency across product and the quality of experience varied greatly. We wanted to solve this problem by building a design system that we could distribute across business units and divisions. And long-term, we wanted to enable more collaboration across our global organization.
Identifying and documenting patterns
Because we work across divisions, we get a bird’s eye view of what’s happening across our organization. We were seeing inconsistent solutions to the same problem, and we wanted to solve this problem. We set out to build a design system with components and standards that we could make available to every business unit.
If we could identify patterns and document them, we’d:
- Ensure consistency across products
- Help teams get to market faster by letting them pull in consistent resources, rather than reinventing the wheel each time
- Save our organization money
- Allows designers to operate at scale
Thankfully, we’re already on our way to making a dent in each of these. We have UX meetups planned on both sides of the pond to give the Wolters Kluwer design community hands-on training with the Sketch Libraries and to gather as much feedback as possible.
Solo vs. teamwork
Like most design teams, we’ve gone through a slew of tools. A new challenge for us when building this design system, was that it required multiple designers to work on the same files in parallel. We are used to working solo, which meant that we only shared when needed to. But with a new focus on collaboration, we needed a way to work on and version the same files.
Abstract provides us with our own private workspaces called Branches, which allow us to work on the same files and Artboards and then merge our changes together without the fear of overwriting our work. And because Abstract allows us to version our files, we also have the ability to revert back to previous versions of our work.
Without Abstract, our workflow would have been so much messier. We would have Sketch files all over the place and designers making copies of Libraries because they wanted to make a slight adjustment. Abstract allows us to keep all of our design system files in one place. The fact that you can simply link to our Sketch Libraries in the same tool was really an eye opener.
The beauty of creating our design system in Abstract is that it’s generic enough for any business unit to be able to use it, while still leaving room for them to make specific adjustments that might not be a part of the bigger design system. Eventually, if we feel that their adjustments will add value, they could even contribute these back to the design system. The governance part is made so much easier with Abstract.
Establishing a culture of collaboration, starting with our design system
Abstract really kickstarted our design system initiative. Since we started using it, we’ve seen an increased amount of feedback. It’s also made it so much easier for us to communicate out our work and connect with product managers, dev leads, and business stakeholders (primarily, CTOs).
Abstract has been a vehicle for us to improve our cross-functional communication. We don’t want to be forcing the design system onto people. Instead, we want to establish a culture of collaboration.
Our roadmap includes establishing a contribution model to enable this. If a local business owner has a priority that isn’t on our roadmap, they can start designing something on their own Branch in Abstract. This model creates a vision of shared ownership. People can take what they need from the system, suggest changes, and add things themselves.
Paving the way for the next 200 years
Abstract has opened our eyes to a way of working that simply hasn’t been done before in our business. Now, we can see each other’s work and comment on it, without overwriting anything.
As a company grows bigger, silos tend to appear and communication can often break down. This time period is fraught with risk and frustration. People tend to work within their own little team and don’t necessarily reach out to others to ask what they’re doing.
I’m proud to say that we’ve broken a barrier here. This effort has shown us and our extended team that we can still collaborate, even though we’re not part of the same team. Our motto is to break down walls — to make people talk to each other. And with Abstract, it’s turning into a domino effect.