Component UI is a balance of consistency with flexibility and the best tools encourage collaboration between design and dev.
Back when I was scaling the product design team at Infor — we were challenged with unifying the broad cross section of incredibly large scale enterprise applications. The kind of ERP software that drove an organization’s complex business process – from finance and human resources to manufacturing and supply chain.
At Infor, our first mission was to identify and sort the common elements from these large, diverse UI systems. It was a complex endeavor that involved documenting everything from how type and buttons would be handled to eventually the herculean task of reimagining the extensive data visualization that is ever-present in robust ERP systems. This whole endeavor was only made more difficult by the fact Infor had been made up of so many business acquisitions that there was very little in common with the front-end framework and back-end architecture.
Once all of these components were documented, we coordinated with the over 7,000 developers that existed across the organization, eventually creating a comprehensive component library called SoHo (Now called Infor Design) — that could be imported to any of Infor’s applications.
Our reasoning for building these components outside of our applications was to keep them consistent and versioned. This also allowed our design team to inspect the design and behavior of these components decoupled from the GA business logic.
Additionally, we created a gating system to ensure these components would not be changed unexpectedly by a rogue development team.
Once these components were verified, they were slowly integrated into each product team’s roadmap, taking into account the diverse underlying code structure of Infor’s entire application library.
It’s important to mention this was 2012-14, a few years before a stable release of React or the launch of solutions like Figma (we did have Sketch though). At the time the closest analog to our process was Bootstrap, which provided CSS and JavaScript-based design templates. So we were essentially taking a similar tact, creating design systems, style guides, pattern libraries, and basic component libraries. At the time, we had to focus on the graphical representation and functionality of the UI elements and patterns because we were informing the front-end logic across a large cross-section of development teams and tools. This had a lot of inefficiencies — often involving design file and code revisions, some requiring more time than others depending on the interdependence of the business logic to the UI.
A lot has changed since then — more complex frameworks and libraries like React and interface design apps like Figma, or new UI dev tools like Storybook have reshaped how front-end UI teams and back-end development work together.
A design system is not a style guide.
Fast-forward a bunch of years, and at Facebook, my enterprise design team designed and maintained UI component libraries with products like Sketch and more recently Figma. This allowed product dev teams to deploy these experiences on Facebook’s React platform. Yes, this is a colossal over simplification , but let’s go with it for the purposes of this brief article. (If you’d like to nerd out — watch this react conference video)
This integrated workflow gives each design team at Facebook the ability to compose complex UIs from small and isolated pieces of code or “components” and deploy them rapidly across many different internal product dev teams. This allows Facebook to efficiently build the very powerful and complex enterprise apps that run the hundreds of in-house processes from recruiting, interviewing and hiring to the more public-facing Facebook Ads Manager.
React, and let’s not forget, Angular, are clearly powerful dev tools to build and deploy UI at scale - and I’ve been seeing more and more use of Vue.js as well.
Candidly, I am far from a JavaScript specialist, so I’ll just let Skillcrush explain the React JS ecosystem:
It’s common to see React JS described as both a JavaScript library AND a JavaScript framework, so which is it? Or is it both?
At Skillcrush, our curriculum team defines React JS as a JavaScript library and not a framework. This is an important distinction.
The difference between JavaScript libraries (like React) and JavaScript frameworks (like Angular) lies in the fact that—in the case of a library—the developer applies library code in individual instances that call for it. When it comes to frameworks, however, the framework creates a scaffolding that arranges your website or application and provides dedicated areas for framework code to be plugged-in.
To dig into the difference between a library like React JS vs Angular (a framework), you can think of code from a Javascript library in terms of furniture and decorations for a house you’ve already built, while a framework is a model home template you use to build the house.
React JS is sometimes mistaken for a full-blown framework since its robust ecosystem and extensibility makes it such a versatile JavaScript library. Remember, when you use React JS to build website and web application UIs, you have access to:
React code snippets and components (building blocks of React code used to create specific parts of a user interface)
The option to use JSX to directly manipulate your DOM
A Virtual DOM to improve your website’s performance
So whether we’re talking about a JavaScript library like React or a full framework like Angular or Vue.js — it’s clear when combined with UI component libraries this workflow has a lot to offer:
- Fast — A UI component library has a huge impact on development speed, allowing components to be collected into patterns, making deployment much faster.
- Well Designed — With the proper workflow, component based UI ensures a consistent and high-quality product UI and avoids developers taking “less-than ideal” liberties with the user interface.
- Simple — Good component libraries are well-organized with intelligent documentation. Code-snippets can make a component library even more functional.
- Compatible — Takes away any concern over inconsistent browser or device compatibility.
- Accessible — Adhering to accessibility guidelines is a big part of a component libraries success and takes away any guessing on the developers part.
But let’s get back to the tactical UI design question — you’re looking at your design team and they’re asking you “Sketch or Figma? Who’s right?” Well, I think that answer is definitely clearer than it was over a year ago when my Facebook team asked me to weigh-in.
Clearly, they’re both incredibly powerful interface design tools, with robust features that support design teams working collaboratively with developers across the entire design and build process. But, while Sketch has been improving, the limitations on how designers can collaborate with developers puts Sketch on the defense here. Its reliance on providing pixel perfect designs, while helpful isn't really efficient in today’s UI workflows.
To be honest, I’m not really sure it’s a contest anymore but this Medium post by Ami Ballo does a great job analyzing the upside and downside of both Sketch and Figma.
TL;DR: Figma is the future, but Sketch has an unmatched wealth of resources. Follow your heart!
Frankly — you could have saved yourself a ton of time by skipping right over this article and just watching this video from last year’s React Conference, you know back when there were live conferences. Maja Wichrowska & Tae Kim from Airbnb “take you through the journey of Airbnb’s experience creating an effective, widely-adopted design system and the decisions and trade-offs that were made to get there.”