Side Project to Product
During the three months that passed between the workshops and the next major milestone, the level of engagement with Helix was everything I’d hoped for. At this point, we were still operating Helix as a side project yet now the front-end developers were starting to really get active with it. Every so often I’d hear “Hey Matt, we added a new component to the Helix library!” which was amazing yet also incredibly terrifying. Amazing as we now had true momentum behind it but terrifying as it was growing faster than myself and the rest of the UX team could keep up with.
Up until now, the design system had only ever had UX driving it as a side project. Whilst we would try to carve out regular time for it, once something got to a ‘good enough’ level, it would always be sidelined if the core workstreams got too hectic. I also noticed that the only reason there were more components being added proactively was that developers were working on them on the side when they had time, or in their own time. Going forward, this would be unsustainable.
It was time to utilise the fruits of the workshops, start the final push to moving Helix into a product and stop treating it as a side project. This was arguably the biggest challenge I faced with Helix to date. Whilst everyone was absolutely clear on the value it brings, up until now, it wasn’t noticeably costing anything. If it were to be treated as a product and still remain without a dedicated team, it would require resources from the existing product teams which in turn could hurt velocity. Support was strong amongst designers, developers and team leads, with senior management happy to go with the consensus, but some work was still required to bring Product Owners on board. To do this I focussed on two areas of direct benefit with one being a current hot topic in the company, accessibility.
Helix was designed from the start with accessibility in mind to the WCAG AA standard. In production, non Helix aligned components did not adhere to this standard both in design and code. Having recently faced legal challenges due to not being compliant, and clear development work required in order to achieve it, this was the perfect opportunity. Adopt Helix and in turn, every one of our products that employed Helix would become compliant.
The second area of focus was that used throughout the journey to date, the expected increase in efficiency. The faster we can get our ideas in front of real customers, the quicker we can learn, drive key metrics they were targeted against and enhance the experience for customers.
Through firstly winning the support and backing from the Product Owner Team Lead, a collective presentation took place, followed by individual fireside chats, which eventually led to the full backing from Product Owners.
Achieving C-Level Buy In
Here I have to admit that I am very lucky to work for a company that was receptive to the idea of creating a design system from day one. That said, moving the system into production would now require significant investment and further justification was required. As my approach was not to pitch for a dedicated team (I’ll come back to this in the next section) but instead look to prioritise development and maintenance of Helix within our existing product teams, this would remove capacity for other work.
In order to achieve buy in I focussed on the following:
- Highlighted success stories seen within the company through its current existence.
- Illustrated how its adoption (number of components in use) will ultimately contribute to more profit and revenue. This is the key metric stressed that will in turn signify whether we have been successful or not (see image below).
- Reiterated the five key benefits a design system brings to an organisation.
During this process, an idea was pitched in order to prove the true in-production value of Helix which was given the green light. This was to run a ‘Helix Week’, in which predominantly front-end developers and UX designers could step away from their respective teams and produce a production-ready Helix 2.0. It was impossible to be able to understand how effective Helix would be in the areas of value communicated without moving it into production. This enabled us to do just that within a short, finite space of time, which was widely agreed upon as a sensible next step.
This part of the journey in creating our design system may seem relatively easy looking in from the outside. Admittedly, yes, it certainly was easier than I imagine most people find this process but there is an important reason as to why. Through taking the bottom-up approach previously mentioned, everyone was already very aware of the support throughout the company which made this step more of a formality.