Creating an internal framework of UI patterns and components.
I was tired of watching our designers and developers reinvent the wheel every time we built a website. We’d often recreate the same or very similar patterns and layouts at significant cost and resource. I was the product owner and lead designer for this internal project, working in agile sprints around client work to deliver iterations and enhancements based on user feedback.
Product owner / Workshop facilitation / Leadership and mentoring / Stakeholder management / UI Audit / Advocacy and Governance / Design Iteration / Adobe XD / Jira / Confluence / Miro
Discovery.
I facilitated a workshop with the team to understand the requirements. We had to balance our own internal stakeholder’s needs (developers, designers, CMS users) alongside our end users.
We recorded these as user stories in Jira with acceptance criteria and set about producing sketches and mapping out the process of using Greyskull for client site builds.
I wanted us to move fast and created an initial set of patterns that we could test and learn from, as we were largely hypothesising the requirements based on our experience.
Design, build and test.
We created rules and patterns around the default UI kit styles (grids, fonts, colours etc) and also our most frequently used UI patterns. We based these on industry standard guidance such as the 8px grid and minimum font sizes, with a view that this would always give us a solid starting point. The next two sprints were used to build out the patterns, with a view to using them as soon as possible and discovering where we faced real-world problems, and edge cases we hadn’t considered.
The first line of testing sat with my design team. I asked them to create some example designs using only the UI kit that we might use on client sites. I tasked the offshore production team to build these using the patterns – this was a great test and learn exercise as it really showed us where there were holes in our thinking. We captured the feedback in Jira and used Confluence to version and track the changes.
Iteration.
With the changes made, we were ready for version 1 release and the next big test, a client site design and build. Throughout the build process, we raised a number of tickets around improvements to the UI and configuration options. We trained the client to use the CMS and build out pages with the components, while observing how they used these in the correct context of use.
This provided us with even more valuable insights that were captured in a Jira backlog. Post launch we reviewed these and I facilitated an impact-effort workshop to understand which features were quick wins, versus those that were too time consuming and not really beneficial to have in a ‘generic’ framework.
Outcome.
We continue to evolve our UI Kit and have now successfully built 12 sites using it. I’ve created a feature roadmap as we continue to improve this.Using the framework has shaved weeks off our design, specification and build process.
33%
Reduction in build times
12
Live sites using UI kit