Behind the Uniform

The Story of Hudl’s Design System

Photo taken and provided by Bianca Zongrone Jefferson

Last month, Michael Fouquet and I presented what it’s like behind-the-scenes building Uniform, Hudl’s design system. We had many requests across the world to stream, but we couldn’t make that happen — although we were able to record it! Find the recording and a short synopsis below.

Before Uniform

Uniform officially launched in March 2018 and it wasn’t even version one — it was version three. A lot of good people put a ton of hard work into building it. After all, it’s an accumulation of two and a half years of dedicated focus that continues to this day. But we’re the first to admit we didn’t get it right on the first try.

Trying and Failing, and Failing Again

We had tried our hand at systematizing our interfaces before. In our own homegrown way, we built style guides and systems that worked for a while, but never stuck. We had two kinda-systems existing in our product and it showed. Our product wasn’t cohesive across different sports, versions and platforms and the differences were clear. Nothing was enforced and we were flying by the seat of our pants. This was no way to live.

Kickoff was a quasi-federated system. Image inspiration from Nathan Curtis of EightShapes.

Initially we released Kickoff, a quasi-federated system, that allowed people from multiple teams to contribute to the system. But there wasn’t a single owner; no one to say yes or no, keep scope or promote and enforce adoption. For example, a simple icon–a circle–quickly became out of hand. With no one championing the system, we ended up having three separate icons for the same thing. They were all next to each other in the directory, but it didn’t matter.

Core Components was a solitary system.

Core Components followed not too long after. It was a solitary system as one team made a set of components that fit the needs that they had at the time. This worked fine for that single team to share components. But a solitary system doesn’t benefit anyone else when the team building it is doing so only for their use cases.

In our first pass of our product, we found over fifty different buttons.

When we met with leadership, it was our collection of buttons that did most of the talking. We found over fifty different buttons in our initial pass. With no system in place, buttons were built by whoever needed them, however they decided to build them, including how they looked and functioned. That meant that teams kept dedicating their time over and over and over again to build a button.

Documentation

Perhaps not ironically, our documentation isn’t a version one either. We designed a site that had everything all in one place–including things that weren’t needed at all. The result was documentation for single components that was quite lengthy and difficult to follow. It even included details that were unimportant, like the border-radius for buttons. Why did we go into such detail about something handled by the component? We tried to be thorough, but we ended up being overwhelming.

Our previous documentation for Uniform was lengthy and, in many ways, unhelpful.

We surveyed our designers, engineers, quality analysts and even product managers to see what we could do to improve. The results were painful, but we needed to hear it.

…I can’t even count how many times I’ve found some documentation about Uniform or Uniform Components only to find out some similar yet completely different set of documentation was what I should be reading instead. It also adds a lot of overhead when I’m trying to have discussions with my designer or another developer.

We set out to make our documentation easy to update, use it as a dogfooding opportunity, and provide what our users needed, when they needed it. We did our research and landed on Gatsby as our foundation and divided our guidelines between designers and engineers. The best part of doing this means we’re able to use our components as they are in the system. It’s a battle-tested way to ensure we’re releasing quality components. Instead of relying on a dummy test site we’re using them in our documentation, so they’d better work, right?

Maintaining A System

Now that we’re 18 months into Version 3 of Uniform, we’re feeling confident in our estimates to keep building. Before it could take two months to build a component from start to finish. Between concepting the design, identifying use cases, architecting the component and writing the documentation, we were pretty open-ended. We’re down to two sprints per component. We’re proud of that.

Every day we work with our designers and engineers to identify new components or enhancements. We attend design critiques, host one-on-one’s, and attend chapter meetings. We’re also piloting a contribution system to make building Uniform a product team effort.

An abstraction of our adoption efforts over 12 months for our Hudl products.

It took a year to get here, but adoption of Version 3 is 100%. Our product is much more polished than it was a year ago and Uniform has grown tremendously. But the work isn’t done–and it won’t be. We’re actively working with other teams to build our next set of guidelines, components and patterns that will benefit everyone. A design system is a product, not a project, and we’re excited for what’s next. We alluded to what’s coming when we presented, so watch the recording to find out.

The recording for our Nebraska UX presentation, Behind the Uniform.