How we integrated Design System components into our user interfaces

We wanted to structure our implementation approach so as to front-load return on investment. We discussed what approach would have the maximum impact for minimum cost, how to allocate our dev resources most effectively and efficiently, and which users we should be focusing on.

At Lexoo, we have two different user interfaces – one for our lawyers and one for our clients. We decided to work on the client interface first.

This decision was based on:

• Maximising impact: Since the functionality of our client interface hasn’t changed much since conception, its design was more outdated than our lawyer interface. A re-design would therefore make most difference to our client interface;
• Minimising complexity: Our client interface has fewer pages than our lawyer interface, and is generally less complex. Our client interface would therefore be easier to overhaul; and
• Prioritising sales-side users: Since our marketplace is demand rather than supply constrained, we wanted our design improvements to be felt on the client side first.

 

Mocking up

We were always clear that we were undertaking a re-design rather than a re-brand. It was our desire to improve the coherence, look and feel of our interfaces without fundamentally changing the way users experience our service.

That said – rolling out the new design system across our client interface required more than simply replacing old components with new ones. Our desire to bring more uniformity to our layouts, and in particular our decision to switch from a vertical to a horizontal nav bar (read more about that here), meant some serious thinking about how we wanted our page map to look after roll-out.

We undertook an iterative QA process, and used this awesome user testing tool to help validate some of the more substantial choices we were making: https://maze.design.

Before v After 

 

 

 

 

 

How to access the new design system – creating an npm package

Our design system components were housed in isolation, in a separate repository to our main application. This was beneficial because:

• it established the status of our design system as a standalone component library;
• it allowed us to format our design system as its own Storybook application; and
• it meant that our contractor Nicolai could work on the design system without requiring access to the rest of our codebase.

Components are made using vue.js. Vue is pretty cool in that you can combine javascript, html and styles all in one file (thus our library is more powerful than just say bootstrap components, components include their own functionality and even style).

We needed to decide on a way to import the design system into our application. Rather than simply copy/paste the code across, we decided to convert our design system into a Node.js module, and publish the package to npm.

Creating an npm package means that we can maintain a clear separation between our design system component code and business logic. It will also help us to enshrine the Lexoo design system in a manner that is more resistant to unwanted drift and bloat, and will allow us to continue to use our Storybook app to visualise the components being used in our application. Finally, should we wish to create other Lexoo apps in future, we will now be able to deploy the same component set.

You can read more about creating an NPM package here: https://docs.npmjs.com/creating-node-js-modules.

Use, tweak, improve

So off we went!

There was no better way to test and tweak our new components than to actually start using them. We allowed for a couple of weeks’ overlap between component creation and starting to re-create client interface pages, setting up a feedback loop between the two processes which helped us to polish our components up to a good standard before our contractor finished up.

For details on our roll-out strategy, watch this space.