Resoluut - a Case of the Right Tool for the Job
There are so many different ways to set up your design process and pick tools that will fit in. We spoke with Vincent Koopmans, Design Director at Resoluut, a Dutch Design agency, to explore how Sympli Versions fit into their process and asked him to share more on Resoluut’s way of working.
Resoluut is an Amsterdam based digital design agency that designs brands, interfaces and products. "We fuel your innovation and enable your customers to intuitively consume your brand or service at any stage in their customer journey. We create products and brands, people love to use."
Tell us about what Resoluut does, how is your team set up, what type of clients do you work with?
Vincent: We are a digital agency: we design digital products, sometimes we also develop them in house. Our work is almost always focused on digital products and branding. We have pretty big clients here in the Netherlands like Bol.com, a prominent online retailer, and one big Dutch bank. Sometimes we support their existing projects and sometimes we work from scratch.
Do you create design systems for your clients?
Vincent: For one of our clients we did, and we see it becoming more common. We have already kind of used design systems in our projects, though we weren’t using this name. We see now that the design system itself becomes a product that you can sell.
How do you manage design systems?
Vincent: Sometimes, the client manages the design system themself because, in the end, as an agency, we’re just passing by. The client we’re working with now has a lot of products, and we set this up so that the design system is not managed by the design team. Instead, the product teams maintain it, and we have two people who are gatekeepers, meaning you have to discuss changes with them.
I did some investigation on the version control, and there were a few, but I didn’t want any speccing, or anything else. My goal was to find a tool that was really close to the way that developers version control their code; that’s why I picked Sympli Versions.
Did you have any trouble with your clients setting up your system because of their security regulations?
Vincent: Yes, corporate clients ask questions about hosting, and their security team wanted to have an on-premises option, to store everything in their environment. For us, it is usually a short discussion — we need this tool. Otherwise, it’s not going to work. Sometimes we end up agreeing on the cloud set up. We now store everything in Git.
How does Sympli Versions fit into your design process?
Vincent: One of our clients is a broadband company. It owns multiple brands they need to support, and they have this Multi Label Design System that, has to be transferred to the brands. I knew we were going to have several people working on the same design, and I was looking for a tool to help me with version control. I wanted to be able to be the project’s gatekeeper and approve or disapprove of the changes made. On half of Resoluut’s projects we work in Sketch, so the tool had to be compatible with Sketch. I did some investigation on the version control, and there were a few, but I didn’t want any speccing, or anything else. My goal was to find a tool that was really close to the way that developers version control their code; that’s why I picked Sympli Versions.
One of our other clients also uses Sympli Versions. Both of these projects use this tool from day one because we set version control as a requirement before starting.
What are the challenges of working with large corporate environments?
Size, definitely size. Due to the company’s sheer size and the different branches it has, there is just a lot to do. When those systems become too big, it takes away the speed. Now we have a very complex design system, and for example, a new component has to be mature enough for us to even let it in.
This approach allows us to add a new brand to the system very quickly. We use code to import style components to Sketch, and then we have a design system specifically for this brand. That makes it really fast and easy to implement.
Until now, we had a system where each brand had its own library. This means that if there is an addition or change, you would have to make sure to add them to the other libraries as well. And since we’re humans after all mistakes are bound to happen. And when they do you need to be able to roll back that specific change.
With this extensive amount of brands and localizations, you must have a lot of stakeholders. Do you ever get tangled in communications? How do you share the designs and get feedback?
Vincent: We have a tight team of designers and developers. And we have product owners in charge of certain features within the app. So if someone wants something specific, they talk to the product owner. If they need to talk about branding — they come to me. It’s a short line, and that’s why it works. You can have a ton of stakeholders, but in the end, there is always one central person who makes the decision. If they like what they see, they will make that work.
How do you present your work to these people? I remember the time when it was all presentations, presentations, and presentations :)
Vincent: Well, we still do presentations, but it depends on the people you’re talking to. Obviously, managers and directors always want to see presentations, they want something to be able to send to decision-makers. But we have demos every 2 weeks, for everyone involved in the product — developers, designers, managers of the specific features. It is always in an interactive and touchable way, so people can see how it works.
Who would you say benefited most from using Versions?
Vincent: I’d say in my team, it’s mostly the designers because it saves them time and in the end — the client because it saves them money.
Until now, we had a system where each brand had its own library. This means that if there is an addition or change, you would have to make sure to add them to the other libraries as well. And since we’re humans after all mistakes are bound to happen. And when they do you need to be able to roll back that specific change. For example, before, when people were using Dropbox for this, you had to roll back to the whole previous version. And if you set up the practice where everyone leaves meaningful commits, it makes the process easier. Moreover now, being able to track this in Jira is very useful.
From next week on, we’re changing this: we’re going to have a single library, and we’re going to change the brand of it through code. Then version control is even more critical, and it helps us lower the risk of human error. Again, this is the way developers do it, and this approach has proven itself reliable and timesaving.