All the components for our new design system had been coded in isolation and packaged up into a neat little npm package 🎁 .
As the development team began to re-code pages from our Client Dashboard, plugging in the new components, we set up a system for tracking our progress and brainstormed options for putting our new pages live.
The page-by-page rewrite was more complicated than might first meet the eye, as our new components are written in vue.js however we had not yet fully implemented vue architecture across our front end. This meant that many pages on the client interface needed to be converted from standard Rails applications to SPAs (single page applications) before components could be slotted in.
We wanted measure:
- Our progress in re-coding pages from the client dashboard using our new components and mock-ups; and
- The impact of the design system.
When it came to tracking our progress, I put together this chart on google sheets and tracked progress through 4 different phases across our page map of 22 pages on the client dashboard. Over time, we were able to visualise our page-by-page progress.
Deciding how to measure impact of a design system is notoriously difficult. The expected advantages are:
- improved look and feel of our pages for users;
- improved cohesiveness and usability of our dashboards;
- time saved when mocking up new designs; and
- time saved by developers when building new features.
Advantages such as 'improved look and feel of pages' lend themselves to qualitative measurement, but finding something quantitative to measure was much more difficult!
I was lucky to come across an interesting approach in this article from Cristiano Rastelli. Rastelli discusses an approach for tracking lines of .css code changed across a mobile application and parallel design system repo - such data can relatively easily be pulled from GitHub. The idea is that, if the new design system is being used properly, developers should need to spend far less time fiddling around with .css in the main application than they were before (since they should be using pre-styled components from the design system which come ready-made). You would inevitably expect a concurrent uplift in .css modifications in the design system repo, however overall the amount of time spent fiddling with .css files should reduce, meaning.... developers can spend more time doing other useful things!
We decided that we would use this interesting approach to track impact of the design system on development time once it had been fully deployed onto the client dashboard.
We discussed three different deployment options: (i) page by page roll-out; (ii) section by section roll-out; and (iii) beta roll-out.
Whilst we would have loved to roll out in beta, we finally decided on a section by section deployment as a nice middle-ground option after comparing all the pros and cons. This was because:
- section by section roll-out was less costly in terms of development time and effort compared to beta (this was key);
- section by section roll-out was easier to de-bug and tweak compared to beta;
- the client dashboard had a limited number of pages, so sections could be deployed fairly quickly one after the other; and
- clients spend less time on-dashboard than our lawyers, so were less likely to notice changes provided they were made in quick succession.
And there you have it...
We expect the client dashboard to be fully deployed by the end of October, and the Lawyer dashboard will follow!