BRIX Pattern Library
DESIGN SYSTEMS / DESIGN OPS
Creating a scalable, mobile pattern library to bridge the gap between a lack of design standards, engineering regression and customer facing UI.
Overview
When I joined the Best Buy Mobile Apps UX team in 2017, the Seattle based app org was composed of 60 people and was growing its UX team. The Best Buy iOS and Android apps had been available to customers for three years at that point, and due to previous experience working on and passion for design systems, I joined the Design Standards team to assess and scale Best Buy's mobile pattern library for a growing design team.
In eight months, we (co-designer Dave Kover and I) built and launched BRIX on Sketch to support a mobile app design team that had grown to 15 designers. What started as a team of 2 has grown into a fully fledged enterprise design org complete with dedicated engineers, content, research, product and accessibility partners. In 2020, BRIX was migrated to Figma and adopted across all customer facing UX teams at Best Buy.
Discovery & Starting From Scratch
I started on the Design Standards team under the pretext that the library the mobile app team had been using, called Brisbane, was "a mess". Not knowing what that meant for designers or devs, I attempted to use it myself and began collecting feedback from both design and engineering teams to create an experience baseline.
100% of designers were using their own home brew versions of Brisbane.
I found that each designer had started with the original Brisbane template, and kept the Sketch file hosted locally. So each time they made a symbol or pattern change it was saved to their personal copy of Brisbane ... which they'd come back to later to start another project.
Each designer had effectively made their own design library salad, introducing wildly variable patterns being delivered to developers at a regular cadence.
iOS and Android devs spent an average of 6 hours per week developing and redeveloping against inconsistent designs.
I interviewed junior, mid-level, senior devs and dev mangers and plotted their feedback against UI tickets, ultimately uncovering they were spending a lot of time playing expensive hot potato.
Personas
Since the Design Standards team's internal customers were Designers and Devs, I created personas based on team interviews and plotted Lucy's journey since her work stream helped us pinpoint root causes for both designer and developer frustration.
Lucy's Journey
Lucy's Journey
After a series of card sorting exercises, Dave and I finally had a prioritized map of the problem space
1. There was no central source of truth for designers to reference when building flows. The library had been distributed as copies of a single file on their machines rather than a managed resource they could reference through the cloud.
2. Brisbane had limited components and design elements that weren't built using the full capability Sketch's nested symbols had to offer at the time, so designers had to break symbols and make their own. Hence the designer and developer time waste and frustration.
Ideation
Library Hosting & Distribution
Problem 1 contained both design infrastructure and scaling challenges, so we started by looking at hosting solutions that would allow Dave and I to create a central design repository that could be deployed to the app team at scale.
Dave, having more experience navigating procurement at Best Buy coupled with his personal passion for building computers, was better equipped to take on this task while I focused on how we might build the library itself to accommodate designer goals.
Drag & Drop Components
In order to build an effective library to match or exceed the design team's need, I started by seeing what components I could salvage from Brisbane to help me create a laundry list of components and styles that could quickly be formatted for easy drag, drop and override using Sketch's library function at the time.
After creating a stable set of components and styles to deploy to designers as an interim solution, I pulled heavily from Material Design's base 8 grid system and mobile best practices to afford designers a single library that would work across Android and iOS devices rather than splitting the library into two separate platform specific halves.
Dev Resources & Design Guidelines
Dave and I had differing opinions on how to approach the problems of design prescription and dev resources. On one hand, I thought we should front-load the prescribed best practices and layouts within the Sketch library itself so that designers could reference the DOs and DON'Ts within each instance of the library file they created.
Dave thought my approach would bloat the library files and cause performance issues. Instead, he advocated for a larger scale, separate site similar to Material.io, Firefox Photon or Salesforce Lightening Design to serve both designers and devs.
Our desired outcomes were the same, but our micro vs. macro approaches to solving this problem were far apart. After asking both dev and design teams how they'd expect such guidelines to manifest, I advocated for patterns and prescription in the library for designers to onboard with while also acknowledging that Dave and I needed to support our devs as well with a dedicated online repository similar to Photon where designers and dev could grab code snippets or read documentation.
Design Explorations
One of my favorite, and most challenging, parts of creating BRIX was figuring out how to make usable and scalable design components so that we could provide designers with a balance of stand alone design elements like text, buttons, icons and containers as well as nested components like product modules, carousels and input fields.
Some of design challenges that guided Dave and me were:
-
Construction: How might we build page layouts so that designers don't need to constantly build new pages? Do we build and maintain each page of the app 1:1, or should we break common page elements down into modules that designers can use to lego-build their pages?
-
Accessibility: How might we design for inclusion? How do we help our design teams create accessible experiences?
-
Feedback: How might we empower designers to request new components or updates to existing patterns/components?
1. Library Construction
One of my first ideas was to provide prebuilt pages so that designers could place a single Home, Account, Stores, Products and Cart page into their workspace instead of building pages from scratch or using screenshots of the mobile app. But this approach clashed with our Modular and Scalable principles because it would have required that Dave or I constantly monitor each of the 20+ possible page builds for changes with each app release and manually update them (not operationally scalable). From a usability standpoint, if we provided designers with fully built pages, they'd be required to break the symbols in order to use the components which would have hindered workflow and introduced more 1-off variants (the exact problem we were trying to solve from the start).
We noticed that designers were using screenshots from the app to frame up their designs, so there wasn't a need for us to build full page layouts, so my first approach was a non-starter. However, as we broke out pages into modules like lists, galleries, buttons and content sections, we saw opportunity for us to build the most common components in the app as symbols for designers to pull into their designs to assist with rapid ideation.
Leaning on a drag-n-drop framework tested better among our design peers because they were able to build up their design from various "lego" vs. break down a pre-built page in option 1. Option 1 freed up the design team from having to worry about the right font weight, color and size to simply dragging text styles or content blocks into their files. One stretch goal was integrating Sketch's data feature with Best Buy's internal APIs so that we could feed real SKUs, pricing and fulfillment info into our designs, but at the time Sketch was limited to using public APIs and the Best Buy data flow teams had security concerns so that goal was tabled.
2. Accessibility
One of my favorite areas to work on was accessibility - mostly because I had no experience with inclusive design and I knew it was absolutely paramount to integrate into the library. When we started creating BRIX, we approached accessibility in 2 ways:
-
Component Level: Making sure our colors, text size and contrast were ADA & WCAG compliant
-
Feature/Journey Level: Changing the team's design process to include inclusive design from the start. This ended up being a longer term initiative that required us to build out an entire A11y team complete with accessibility QA reviews and standards.
3. Feedback
Lastly, we needed to figure out a feedback loop for designers to flag component bugs and suggest new components, so Dave created a JIRA board so we could hold the Design Standards team accountable for library maintenance, prioritize requests and track library stability.
BRIX 1.0 is born
After months of research, planning and trial and error and testing, we released a stable version of BRIX to the app design team. The name BRIX stuck with us because Dave and I always talked about the library as a collection of Legos that designers could use to plug-n-play. Guiding our work along the way were the design principles we agreed upon after sizing up the problem space. BRIX would need to be Modular, Scalable and Platform Agnostic if we planned to achieve the outcomes our design and dev partners wanted.
Outcomes
Adoption
About 30% of app designers started using BRIX right away while the rest were slower to make the switch mainly because they were in the middle of feature cycles when we launched. After 2 months, all app designers had started using BRIX.
Measurement
About 30% of app designers started using BRIX right away while the rest were slower to make the switch mainly because they were in the middle of feature cycles when we launched. After 2 months, all app designers had started using BRIX.
Feedback + Iteration
About 30% of app designers started using BRIX right away while the rest were slower to make the switch mainly because they were in the middle of feature cycles when we launched. After 2 months, all app designers had started using BRIX.
Challenges & Growth
This project was a huge growth opportunity for me, but to this day I'm grateful for Dave, our fellow designers and engineers who helped me along the way. One of the main challenges I faced while building out the component side of the library was my ignorance of the box model used in web development and app development. At one point (early on thankfully) Dave pointed out that I had been making symbols with elements all globbed together in a single container rather than approaching each symbol as a collection of partitioned containers that could stack (remember, one of our guiding principles was Modularity).
There were numerous occasions when Dave and I didn't see eye-to-eye on things like padding, margin and font weight. During these disagreements, we brought in engineers to weigh our options and looked to other apps in and out of the retail space (Target, Walmart, CapitalOne, Google Map etc ...) to see how their design languages handled such things.
You may have noticed there's no mention of accessibility above. While we used contrast tools for text readability, neither Dave nor I knew anything about inclusive design at the time and therefore hadn't included any guidance on the subject in the first release. Since the launch of BRIX 1.0, the Standards Team has incorporated A11Y standards, held training and requires accessibility annotation.
What started as a series of design library experiments between 2 designers has blossomed into an enterprise Design Standards team that supports hundreds of designers at Best Buy. The Standards Team grew from a clandestine operation in a satellite office (Best Buy HQ is in Minneapolis) into a team complete with dedicated engineers, product, content, research and accessibility partners all working together to help customer and employee facing design teams create better experiences.