New Threads: Uniform’s Next Major Version
It’s been two years since our first major release of the Uniform design system, and a lot’s changed. We’re excited to announce the launch of Uniform v4!
From Nothing to Something
In 2017 when we launched Uniform, we worked furiously to bring coherence across our products. We tried twice before to make this happen, but it wasn’t until Version 3 that we’d hit all the marks. Our launch was successful — it was seen, scrutinized and praised across the world. And we had a mighty tall mountain to climb to gain 100% adoption. It took a year, but we did it! We chanted our mantra, “Hudl is a premium product, it should feel premium.” and aligned our products across the globe. We made the right thing easy.
Since then, the system blossomed to support multiple platforms, include 13 new components, visual guidelines, and entirely new sections dedicated to interface patterns and words. We opened contributions from our product team and collaborated on new components. We’re just opening the door to data visualization at Hudl. All of this, while we’re a tiny-but-mighty team of two. This system can be a lot to own, and even more to govern, but we do so with pride. We love collaborating with designers and engineers to pitch ideas and gather feedback before embarking on our next ascent.
What Fell Apart
One might think once something big and brand new has launched it’s easy to keep things tidy and working. But as team of two supporting a 200+ person product team, there are a few things that get missed. We were building adoption while feverishly creating new components to meet all sorts of needs. Each new component had their own subtleties that started causing problems.
Building with Uniform should always make doing the right thing easy. Sure, using it was easy enough, but the wasted time started to add up. Especially if you can’t figure out why a message in a Toast isn’t displaying as it should, but it works fine in a Notice. Key props were created in misalignment. Was it `Text` or `Message`? `Action` or `Button`? `Header` or `Title`? Individually, these differences were minor, but these details are a really big deal to us.
We also had a serious case of design system bloat. Our components and styles lived in different areas. We had an untold number of unused variables in our Sass and component packages. We ended up with “magic numbers” for colors that weren’t part of the system.
We were losing control of our source of truth. Some dependencies, like React, had released their next major version and teams here were quick to adopt it. We couldn’t tie into those upgrades without a breaking change to some of our components. Some teams were having to take some unfortunate steps in order to keep using Uniform within their project. Additionally, TypeScript was starting to gain more traction and it quickly became our developer’s number one request.
The Nuts and Bolts of V4
To begin, we started at our base styles and that meant taking a hard look at our Sass setup. After some careful consideration and discussion with our devs, we decided to move away from Sass and fully embrace CSS variables. Not only are we looking forward to handling more robust theming, we also have plans to implement density support — a long requested feature from coaches — all thanks to CSS variables.
As mentioned above, we let the API to our components get a bit out of control and we didn’t put enough of a focus on maintaining a consistent naming scheme. This was one of the easier things we ended up doing, but obviously has one of the bigger impacts since it will require updates from our devs.
Finally, to really bring this thing home, we upgraded our package to support and use React 16 and TypeScript. Our components now utilize hooks and we added robust documentation with TypeScript — we even included links to the documentation in case developers want more context. Being able to see all of the available props and their values as you’re developing has been a game changer, even for us (we can’t remember everything after all).
Our Next Season
Our first priority is to get V4 to 100% adoption. It will be very difficult for our small team to maintain two major versions for a product team that’s only growing.
In addition to that, we have two other projects. As a video and data company, we need a standard way to display data. We serve a wide spectrum of users — from elite analysts in the Superliga to a dad coaching his daughter’s volleyball team. Our data needs to be precise, interesting and compelling. It needs to tell the story of what’s happened in an accurate and visually engaging way. Since we’re in sports, we’re starting with fields of play, colors palettes, icon signifiers and data tooltips. We need to do this while remaining accessible. Which brings us to our other project.
As part of Version 4 we completely refactored component’s focus states. Whenever someone tabs through our interfaces, they can actually see where they are. We take a11y seriously and have ARIA labels where needed already. We use Stark to check color contrast and ensure our system colors are accessible for anyone with any type of colorblindness. But we can do better. To us, being inaccessible is unacceptable. So we have a plan. We’ll be following WCAG 2.1 guidelines more closely to bring accessibility to the forefront of Uniform, and our product. Our guidelines and components will be built using inclusive design principles, and so much more.
We’ll have plenty of new components, patterns and guidelines to help us get there. There’s definitely no shortage of that, so stay tuned!
Thanks for reading!
