by Paul Drummond on 09 Jan 2019

At SaleCycle, we have developed a UI component library in ReactJS to make it easy to build UI’s based on the SaleCycle design system. This introductory post tells the story of how the component library came to be.

When I started at SaleCycle back in November 2017, one of my first tasks was to implement an end-to-end solution for an early prototype of the MySaleCycle Dashboard. The first part involved working on several Java-based backend micro-serivces to stream, convert and aggregate incoming impression data and expose it via a RESTful API. The second part involved the development of a UI to consume the data from the API and present it to the user via a graph-based Dashboard UI.

While the UI was the part I was looking forward to the most (because I’m a self-confessed UI nerd), it actually turned out to be the most daunting aspect! I found it difficult to focus on the functionality of the end-to-end solution because there were so many general UI/UX issues to consider such as:

  • Responsiveness. “How will the UI adapt to different devices and screen sizes?”
  • Consistency. “How do I ensure the UI is consistent with the rest of the app?”
  • Browser Compatibility. “What level of browser compatibility do I need to support?”
  • Reusability. “When designing components for the UI, should I focus only on the functionality required for this piece of work or take extra time and effort up front to design reusable components?”
  • How to source 3rd-party components? “If a component isn’t available in the codebase, should I download one from NPM? If I use an NPM library, is it acceptable to use the default styling even if it isn’t consistent with other components? If components need to be re-styled for consistency, what if the component isn’t customisable enough to match our design system?”
  • Keyboard Support. “Do I need to consider keyboard support and if so, how to I ensure it’s consistent with the rest of the app?”
  • Accessibility. “What level of accessibility do I need to consider?”
  • Internationalision. “Does the UI need to work with multiple languages? Does it need to consider language features such as RTL?”

It’s possible to utilise a 3rd party UI toolkit like React Bootstrap, Semantic UI or Material UI to avoid having to worry about common UI issues like those listed above. These toolkits provide you with a wealth of components and standards out of the box which allows you to develop an impressive UI with the minimum amount of hassle. Concepts such as consistent look and feel or accessibility support are largely handled for you, allowing you to focus more on your customers needs rather than implementing what is now considered boilerplate work. Moreover, many of these frameworks provide ample documentation and active communities who are more than willing support you during development. But there are downsides to consider too. Fully featured component libraries tend to give you more than you expect or want quite often. While most of these libraries are quite flexible and configurable, there is always going to be limits to what you can do with them. The price you pay for out-of-the-box features is less control over behaviour and styling. I’ll be going into more detail on how these downsides impact UI development in future posts.

Often the trade off is worth it, but at SaleCycle the lack of control conflicts with the company vision for its UX and branding. We’re looking to deliver a platform to our users where they can “feel at home” while interacting with it. It should be a place where everything looks familiar and behaves as expected. Users should be able to intuitively navigate and interact with all the different areas of the UI without confusion as this helps to increase user satisfaction and loyalty.

When I started working on the SaleCycle UI, the design work for a component-based design system was already underway, but it was still unclear how the rules of the design system would be implemented in the main codebase. After deliberating on this for a while, our research revealed that many companies had been in a similar situation and their solution was to create a custom UI toolkit based around their own brand and design system. Companies like Amazon, IBM, Airbnb, Atlassian, Starbucks, Lonely Planet, Pinterest, Sage and Uber all achieve consistent UI through a component-based design system. So we got to work developing our own React-based component library that would serve as the “glue” between our application code and our design system, and within a few months the first version was integrated into the main codebase.

The Tech Team at SaleCycle have been using the new UI component library for several months now and while it’s still in its infancy, we are already reaping the benefits. I’ll be going into more detail on these benefits and also some of the challenges we’ve encountered along the way in future posts. For now, here’s a summary of some of the topics I’ll be covering over the next few months:

  • Why the component library is intentionally not general purpose by design.
  • The layout system in the component library.
  • How we test the component library.
  • How we document the component library.
  • How we style the components using styled-components.