BigDesign: Lessons Learned From The Development Of Our Design System
Design Language Systems and Front-End Component Libraries. The “white whale” of product design and engineering teams. We all know the value of utilizing standardized design systems and frameworks. But getting an organization to prioritize, build, and adopt a design system can be challenging.
Software development is an evolving discipline, as is user experience design. Like most software platforms at our level of maturity, BigCommerce has been built by many different teams, using different codes bases, over the better part of a decade. The result has been not only tech debt, but “design debt” as well.
Defining the Problem
A Design Language System is a solution. The product design team at BigCommerce operates on a “double-diamond” process model of “Discover, Define, Develop, Deliver”. Before we can begin discussing solutions, we must first properly define the problem.
Everything we do at BigCommerce starts with our users, and this project was no different. As a SaaS e-commerce platform, we have several distinct user types. Merchants use our system to manage their business. Partners are 3rd party developers looking to build their own applications that integrate into our system (ex: MailChimp). Agencies are 3rd party design and development firms that use our platform to build custom web ecommerce solutions for their clients.
We began by conducting interviews with all of these user groups. Some of the insights we generated included: Merchants find our UI confusing and difficult to navigate. Patterns and behaviors are inconsistent from feature to feature. Partners would like their applications to feel native to the BigCommerce experience. Often times they are hacking our code to find simple information like “What color blue are our buttons?” Agencies have similar needs as Partners and are looking to expedite development time.
Establishing Value Propositions
The next step in our design process is to establish value for both our users and the company. Often times this takes the form of defining key User Stories to solve for.
As a merchant, I want to perform my tasks more quickly and reduce my cognitive load.
As a partner, I want my application to look and behave like native BigCommerce features.
As a developer, I want an easier experience building into the BigCommerce ecosystem.
In addition to user facing objectives, we ensure “design-driven” projects ladder to company initiatives and goals as well. By creating a library of UI components our internal engineering teams around the globe can move exponentially faster in terms of feature development. Providing tools to 3rd party teams helps solidify those relationships and ensures they view BigCommerce as a trusted partner they want to work with and recommend in the future.
Getting it on the Roadmap
Here’s where so many Design Language System initiatives peter out. Product owners want to create great user experiences as much as designers. But, they also have the burden of managing feature priorities, bug fixes, stakeholder requests etc. The result is that often times DLS tickets are sent to the backlog, patiently waiting for downtime that will never come.
So, as designers how do we ensure our system will actually see the light of day? This is a question that can extend to all design-driven product initiatives.
At BC Product Design, we have had some success in this department. First, we are lucky to work in an extremely user-centric org. From executive leadership on down, roadmaps and initiatives are defined and measured by the value they provide our users. This is admittedly half the battle.
We also make a concerted effort to ensure design-driven projects ladder to company initiatives and goals. We prepare roadmaps and project plans in an iterative manner. Following agile methodologies we plan small incremental releases that “unlock value” for users with each step.
In the case of our Design Language System: Instead of proposing we dedicate countless design and engineering hours to creating our component library upfront and then refactoring our entire product experience, we took an iterative, phased approach.
The ability to list your products on external sales channels like Amazon is a major selling point of our service. Another key differentiator is that we are an open platform and encourage external developers to contribute to our ecosystem.
As such, one of the projects on our product roadmap is the Channels SDK (Software Development Kit). This will allow 3rd parties to build their own applications that integrate with BigCommerce and our channel listings service.
This project provided us the perfect opportunity to layer a design-driven initiative into a larger and already established project. In a bit of fortunate luck and timing, the front-end development team working on the Channels SDK project had already been experimenting with component libraries to speed their own internal development.
The design team partnered with product and engineering to investigate the value of combining our efforts. Together we formulated a plan. As part of the release of Channels SDK, we will provide 3rd parties with the foundational elements of our Design Language System. We resisted the urge to “boil the ocean” and develop all design elements upfront. Rather, we focused on the insights and problem statements we established during our discovery phase.
We established an initial set of design elements that would unlock value for 3rd party designers and developers. Colors, typography, grid and layout, iconography, form elements, inputs, actions, and status indicators.
This allows us to address key user needs in the short term, and establishes a pathway to boarder internal adoption as we move forward.
Design Process
With our project officially “green-lit”, it was time to get to work. Our design team is incredibly collaborative and this was and continues to be a team effort in every sense. Designers were each tasked with a different design component, and we set about doing our due diligence. We conducted competitive analysis to understand how other design systems utilized components. We audited our own product and understood how use cases for components might vary depending on feature.
Then we began to design. Our system is based on Atomic Design, a methodology defined by Brad Frost. You can read more about Atomic Design here. In short, chemistry becomes an analogy for component-based design. Base elements or “atoms” are combined to form “molecules”, which can be reused and combined to create more complex “organisms” and eventually pages.
We began by defining our foundational design elements which we would reuse as we graduated to more complex design components.
We established weekly design review sessions where the team would come together to discuss and refine concepts. When a designer was ready with a proposal, the team would pressure test it throughout our product to ensure edge cases had been accounted for. Once the design team has aligned on a conceptual direction, we begin the engineering handoff.
Because our internal front-end team is building these components, we follow our traditional handoff process. We use Figma and our traditional project management workflow to define design specs, behaviors, and use cases. One aspect we focused on was defining a universal vocabulary. Our design and engineering teams operate around the globe and in multiple languages. By establishing consistent terms for things like colors and component anatomy, we ensure everyone is speaking the same language, even when they’re not.
Next Steps
We have established that refactoring our entire product experience to align with React components is not feasible in the near future. As we move forward, new development will use BigDesign, but there are still a number of teams with no plans to adjust their code base. Our partners in engineering are working to solve this by embedding components within “wrappers” that will allow us to utilize React components in Angular based features. This will not solve for all cases though, and we will have the challenge of “catching snowflakes” instances that are outliers of our system.
We are again taking an iterative approach in this regard. As a design team, our goal is to create a unified product experience. We will be able to visually align some of these problematic features using simple css overrides. While not ideal, and does not solve for having instances “off-system”, it’s a start. From the user perspective our experiences will be consistent, which is a BIG improvement from where we are today.
