What was the business problem to solve?
Enterprise Sketch customers were missing an easy way to work with Branded Design Systems. Imagine a design team working for a telecom company that has 10 sub-brands. They share the same basic components structure, but have minor visual variations between them. In Sketch, you would need to maintain 10 completely independent libraries (one per design system). This made maintenance a nightmare, was very error prone, and slowed down the app. Also, our main competitor had better tools to deal with this scenario.
We had something to try to solve this problem somewhere in the roadmap, but our customers needed help immediately (some of them were threatening to cancel their subscriptions if we did not address this problem soon).
So we decided to build an MVP of a tool that would solve their main pain points.
How did you measure success?
This was easy: if we could reduce the amount of lost work hours per customer, the project would be a success.
In the most extreme case, we had a customer whose entire design team would spend one week merging changes from the main design system library to the rest of their branded libraries (they had 15 in total, with thousands of components).
We reduced that to a 3 minutes operation that required one click, executed by one person.
What challenges did you face along the way, and how did you address them?
There were 3 main challenges:
The problem we were solving was very broadly scoped. There are literally hundreds of ways in which you can structure a design system library, and it’s impossible to build a tool that covers all scenarios and edge cases. We decided to be very opinionated about what the tool would handle, and how it would work. Initially we considered the possibility of offering many options to customize the behaviour, but that made the code unmaintainable. Instead, we released the code for the tool as an open source project, so that customers with very specific needs could adapt the tool to their workflows.
Our users may not always have a development team. The initial idea was to make Sketch Fusion a command line only tool. But many of our end users were not comfortable with the idea of installing the required dependencies and using the Terminal. We addressed the problem by implementing the tool as a dual command line / web app solution, and hosting it ourselves for “demo purposes”.
We were not intimately familiar with the problem we were solving. Sketch’s design team was/is small, and had never faced the same challenges our large customers encountered every day. So we had to familiarise ourselves with this scenario. To do that, we had multiple work sessions with customers, to understand how they worked and the kind of documents they were managing. NDAs were signed, and we got access to actual production documents we could use to understand the nuances of the problem space, and use as sample documents to test the tool.
What stakeholders did you work with on this project?
I worked both with internal and external stakeholders:
Customer Success Managers: they identified the accounts that had the problem we were trying to solve, got us in touch with their design teams, and kept the customers updated on the progress of the tool. They needed good news for customers as soon as possible.
Design Advocates: worked with customers to understand the problem space, working with their files. They provided great insights to scope the tool, and were of great help when testing the tool (both the features and the usage).
- Design Leads at multiple companies: they were our connection with the real world, and the ultimate responsibles of validating that our approach was good. They wanted to see we really understood their struggle, and that we offered them a real solution they could use.