Not Reusable Anymore
I’ve encountered situations when teams start building components with the intention of making them common or reusable but get carried away and include so much functionality that there’s no practical use for it outside the current implementation. Remember, Common Components are meant to be so simple that they can be applied in various situations and if they need to do more, they can be extended in the implementation, not in the component itself.
Messy Style Sheet
Do not overlook the importance of the Style Sheet. Make sure you establish a common/shared Style Sheet in your component library and put strict governance around it. Developers sometimes get lazy and make up their own class names and fail to follow the standard and structure set by UI/UX Designers—not to mention coming up with their own look and feel and ignoring the Style Guide altogether, reducing the usefulness of the component. Don’t hesitate to put in the work to establish your style sheet. Because if done correctly, you will only have to do this once.
Bad User Experience
So, the team codes effective and efficient components that are reusable. Do they fulfill the needs of users? Do they improve the user experience? If the answer is “no” to both questions, the component you built will go unused. We encountered a date range component where users enter the start and end dates—like the ones used in travel sites. But this component did not let users type in the dates. Rather, users had to open the calendar control and click the day in the calendar. Though not a problem for 1 or 2-month ranges, the average relevant date range was 10 to even 20 years. As a result, we didn’t use that component and instead opted to use two separate date controls.
Not Updating Your Library
I worked with a client that took pride in a component library they had been building for years. We were ordered to use their components in a modern web application we were building. Unfortunately, the components were dated, and the library had not been updated to modern conventions and styles. The company did keep up with technology versions but were slow to adapt to the new features. In addition, most of the controls were not responsive. This was a big problem, considering we were building a web application meant to work on all devices, including mobile.
Reinventing the Wheel
Controls are available in Angular, React, or even HTML that in most cases will do the trick. Use them instead of building components that only slightly improves them. Check out Angular Material and Material-UI. They have built-in components that will satisfy most requirements and seamlessly work with Angular and React, respectively—not to mention the open-sourced component libraries that are available on the web.
Lastly, if your organization has any questions around building or implementing UI common components, please don’t hesitate to reach out to us. We’d love to help you get started.