In a former company where I worked, the VP of our department made the following statement one day; “If you’re not keeping score, it’s just practice.”
At the time, our department was tasked with improving the adoption of our SharePoint technology platform used for collaboration and document management. The organization had invested millions of dollars in implementing and rolling out the new technology across the enterprise. They wanted a return on their investment. Leadership wanted knowledge workers to leverage SharePoint instead of using Dropbox or network share drives. They wanted empirical evidence that our users were leveraging the platform, not just hearsay. This was a corporate business, and metrics needed to be taken seriously and not treated as a game.
I had a great conversation this week with the Director of a big analytics company about design systems. The UI library they produced internally to his organization helped speed up the prototyping of a new app. A project manager informed him that the UI library helped the team reduce the time to build a prototype from 2.5 months to 2.5 weeks. That’s huge. The problem is that the information was anecdotal. The project manager marked it as a benefit he saw for his project. But there was nothing firm to compare that story against. No prior analysis had been done to ascertain whether, on average, most prototyping took 2.5 months. And that’s where our discussion led to the problems of measuring the benefits of a design system using empirical evidence.
My proposal to the Director of the analytics company was to put some gates in place so that project managers who wanted to use the UI library would give the library dev team access to the project repository. By having access to an existing project, the library dev team can take it upon themselves to perform a quick analysis of the number of major releases and frontend issues the project experiences before the use of the UI library and then after its implementation. If it was a new project, the library team could provide a questionnaire about the project team’s deployment history and frontend issues experience. From there on, the library dev team would monitor the release and issues that come up in the project to compare the current experience against reported past history. This enables the UI library owners to capture concrete, objective data about the benefits the design system brings to the organization.
Admittedly, my proposal to build gates for the use of a private UI library would probably not go so well for developers who are used to just pulling any external library or package from the internet. Instead, perhaps one could monitor the artifacts repository and find out what projects are pulling the UI library as a dependency. Then the library development team could reach out to the development teams and ask questions about the consuming projects. Regardless, building a relationship with the application developers and architects is crucial.
Here’s what I suggest all UI library owners ask and learn from the project teams that are using their reusable styles and components.
- In the last project, how long did it take for a new feature to be released?
- In the last project, how long did it take to prototype a minimum-viable-product using mocked APIs?
- In the last project, how much time was spent working on your application’s frontend visual issues vs backend issues?
- In the last project, how much time was spent improving performance for your application’s frontend vs backend?
- In the last project, how much time did it take to load up a fresh, uncached version of your web application?
- In the last project, how large was the web application build bundle for the client-side?
- For the above questions, ask how things are doing now with the use of the UI library.
The goal here is to start small and keep it simple. You may not get responses to all the questions but something is better than nothing. Gather enough data to make a case to others that a design system and it’s deliverables, a UI library, are important. Thereafter, maintain a close relationship with the architects and developers of the project for monitoring. Like a good scientist, you need to make observations and gather data on the behaviors and patterns.
As a UI library creator and maintainer, we know at the deepest levels of our being that reusable styles and components are incredibly beneficial to developers, product managers, and, ultimately, end-users. Generating anecdotal evidence is not enough. Make sure that our work has clear and quantifiable benefits that can be measured. Otherwise, we’re just playing games.
