7 lessons we learned while building a modular web design platform
Hey there, I’m Tyler Schuett. I’m a Lead UX Designer at Riot Games. I joined Riot from the Universal Shopping Experience (USX) team at Amazon just over two and a half years ago. I came to work on the overall experience our players have on web when they’re not playing our game, League of Legends.
My team and I had many challenges to solve, including figuring out global navigation and browse systems, planning content discovery and personalization across sites, and thinking holistically about how we get the content we create out to players. The bigger problem we identified was how to get everyone making web products at Riot Games onto the same page so our players could have a consistent experience. A fractured web ecosystem is a problem because players have to relearn UX and visual patterns on every site and even on different pages within a site. We needed to get Riot to speak with one design language.
A bit of context
Outside of the client experience, League has a large ecosystem of companion sites and apps that offer a variety of content and services. Here are just a few examples:
When you visit each of these sites you may notice that they all look, function, and feel different. In some cases, they should look and feel different; they’re different brands with distinct objectives and functionality. But do our players think about our sites as individual places or just as the “League of Legends website?”
I would argue that they don’t break this down the way we do internally. One of the things my team and I started to tackle was figuring out how to align our experiences where it made sense, while still allowing the flexibility that our different brands require. That led us to modular design.
Why a modular design platform?
Riot’s web ecosystem is rather vast as you can now imagine. There are lots of moving parts. Rioters (employees of Riot) of all disciplines around the world have their own opinions, needs, and ideas for web. At Riot we’re fortunate that teams are empowered with autonomy. We can move quickly and make decisions without a lot of red tape. The downside, however, is that each new web project often continues to fracture the consistency of our players’ experience across the web ecosystem.
As an example, here is just a small collection of our primary call-to-action (CTA) buttons:
Our UI audit highlighted a couple of internal issues.
- Efficiency sink: Developers and designers at Riot have no single source of truth for what good looks like, so they continually need to reinvent the wheel.
- Pattern drift (shown above): Reinventing the same patterns over and over is impossible to maintain.
It became increasingly clear to us that we needed to build a platform which helped teams at Riot come together. Because Riot has multiple brands, any solution we created hinged on building a flexible environment which empowered teams to deliver distinctive brand experiences while upholding best practices and standards.
So my team and I set out to build a modular design platform for Riot Games. Along the way, we gained some insight. We’re guessing any company looking to scale its products, services, and/or brands will face similar challenges, so here are a few pro-tips that we learned along the way.
#1 — There’s no one ring to rule them all
At first we set out to find “the solution” for our problem set (efficiency sink, multiple brands, and pattern drift). We looked at a number of options from Bootstrap to internal kits to Material Design. Indeed, there are many frameworks out there, and we’ve linked some of our favorites at the end of this article for you. We spun our wheels for quite a bit searching for the perfect single solution. We rabbit holed a few times trying to make different solutions fit our needs, but it always seemed like trying to put a square peg into a circular hole. Nothing fit perfectly.
At Riot we have multiple distinct brands (League, Riot, eSports, etc..) that need to stand on their own two feet. Their brand identities are in many ways core to the experience.
- Example: eSports should deliver a sports themed experience and to do otherwise wouldn’t fulfill a players expectations of an eSports website.
- What works on the eSports website wouldn’t work on something like Universe, which is all about storytelling and needs to immerse you in the world of Runeterra. Hextech embodies the essence of Runeterra and is all about the confluence of magic and metal.
We needed a solution that could allow our web experiences to be both thematically unique AND consistent. Buttons should look and feel a bit different but function completely the same. Components and patterns should adhere to a core set of standards on what we think “good” looks like.
Eventually we arrived at the question: “Do we need all of one, or can we just take the parts we like from each?” Put simply, yes we could.
We broke apart the ideologies and tech from each solution we liked, and ended up with a frankenstein of features that, together, made a lot of sense for us. Our particular model mashes parts of Atomic Design Methodology with Polymer. Our spin on it adds a stronger focus on long term scalability and maintainability of multiple distinct brands.
The little nugget here is: Don’t spend time trying to find “the solution.” Instead, look at the features of many solutions and use the parts that make sense for your goals. And, you can and should infuse your Frankenstein with your own perspicacious thinking.
#2 — Help in the right places
We create a large variety of web experiences at Riot. Some of them are highly immersive. Some are temporary. Some are incredibly complex. Initially we tried to catalog everything we thought teams would ever want to use. We tried to anticipate every possible permutation and make a design for it. This became completely unmanageable.
We realized that trying to boil the ocean by cataloging every possible variant of every component in our UI kit often led our designers towards feeling too constrained. It often didn’t help them solve their problems either. We started to feel it ourselves as we tried to use the platform on our own projects. We had to keep adjusting or tweaking components to fit each project’s needs.
We began to think more about what would be most helpful without being too constraining or impossible to manage. We came to the conclusion that even if buttons looked slightly different across brands, they could still function the same. We could bake in a whole host of best practices like WCAG standards, ideal padding and margins, language conversion considerations, platform compatibility, and interactivity requirements.
Above example: We separated a button’s style from its functionality. The button element is completely functional at its core, but has no style until it’s extended into brand themes which each contain a different look and feel. Each themed button can easily adhere to global standards and best practices while still retaining their identity.
In the end we learned that it was important to help in the right places. Empower teams with the knowledge that will enable them to make new components the right way. Elevate the conversation about what good looks like and why. This works a lot better than trying to make it all for everyone.
#3 — Make a platform, and make it useful
It’s not enough to have some components on a company wiki page that everyone is supposed to use. Apparently we have a League UI kit, which after two years of searching Confluence, I have yet to find. When I came on board, finding any information about web at all was like a grand easter egg hunt. While fun, it wasn’t the most efficient use of my time. I knew if I was struggling, many other Rioters were too.
My team and I started thinking about why this was the case and what we could do to create a more useful platform Rioters could utilize. Finding things like fonts, guidelines for brands, and best practices has been notoriously difficult. We thought this was a glaring opportunity to provide value.
We built a platform which has all our elements on it — similar to others you’re probably familiar with like buttons and tabs — but we didn’t stop there. We included things we thought solved major pain points across our organization like:
- Getting started guides for designers, developers, and product owners
- Digital guidebooks for every single brand at Riot
- Easily find-able standards and best practices
- Downloadable fonts, colors, and UI kits for each brand
- Responsive previews to see any component at any device width
- Case studies showing performance
- Examples of live sites built with the platform
Bringing all of this value together made it really easy for teams to naturally gravitate towards:
- Getting up and running with web projects quickly and easily
- Funneling the saved time and energy into making better things for our players
Design for usability. Understand your company’s unique situation and what your peers would find valuable, then package that up into one place the entire company can utilize.
#4 — Devs are your friends
We learned it wasn’t enough to think about designing cool buttons and carousels. Besides, you shouldn’t use carousels anyway. Getting the developers to be just as excited about the platform as the designers are will help increase adoption. We reached out to some of our developers who were passionate about the web space to understand what challenges they faced and what they thought would be good scalable solutions.
One issue they pointed out was that maintaining web pages is traditionally difficult. That difficulty often led to pages being deprecated or neglected. Any time a designer wanted to change the structure of a button (let’s say, by adding an icon), a developer would need to find every button and manually add in that icon.
They pointed us towards web components and Polymer. Polymer allows us to build components like buttons and maintain them centrally. When we want to push updates to those components, we only have to do it from one place. So now our design platform could be consistent and better performing while creating efficiency across the entire organization.
By working with our passionate developers and adopting the solutions they proposed which we felt made sense, we turned them into advocates for our platform. They were already excited about the technology they suggested, and this gave them an opportunity to see it utilized in meaningful ways to solve real problems at Riot.
This opened our eyes to new ways of thinking about design. It made our designs better. It made the overall platform more valuable. So go find some passionate developers and get their opinions and insight. If you can turn them into advocates, it can help get things done more quickly inside organizations that move slowly.
#5 — Start small
We rushed too quickly into building a bunch of our components. When we found out something wasn’t working as planned, it was painful to update them all. We revisited the user stories for the platform and made sure that a smaller set of components met all of those stories before we scaled outward.
As an example, two of the stories we wanted to tell were:
- I can include components in an existing web page and it is guaranteed that the component will not interfere with or break my page.
- I can embed a component into any web page and it is guaranteed that my component’s styles and functionality are not wrecked by the containing page.
Once we had a solid list of stories, we then set about building 2 or 3 components that we called “the golden components.” We worked to ensure they accomplished every single story. Once we felt confident in the golden components we proceeded to scale out the rest of the platform.
This ended up being a better way to prove out and refine the structure before sinking a bunch of time into a direction only to realize you made mistakes after the fact. Start small, prove out the model, and then scale.
#6 — Eat your own dog food
We designed a lot of individual components before we used them, and when we used them ourselves we were able to quickly identify where/how they needed to be tweaked. Prior to that, when we looked at individual component designs in review, we didn’t notice the things that should be adjusted because we lacked context.
So my suggestion to you is to actually build something with the concept components you want to make as you design them. Go use them. See how they look in context of an actual web product. See how they behave out in the wild. You will shake loose all of those pesky edge cases that are nearly impossible to think of during design review. Prove the patterns out before you ask the wider organization to use them or you invest too much energy in a direction that may not work.
#7 — Good design leads to greater adoption
During the design process it was really easy for us to get wrapped up in designing components without considering how different people would use them. We had to continually pull our heads out of the clouds and ask ourselves “If I’m a developer, how do I quickly get started using the platform?” or “What information is important to me as a product owner?” or simply considering the frequent behavior of how someone who would use the platform to build websites.
Additionally we asked ourselves:
- Would they keep the platform site up and in the corner of the screen?
- Would they open a bunch of tabs with individual components as references?
- Where would they spend most of their time? And why?
- Who is going to use an awesome component that hundreds of hours were put into if they can’t find it or figure out how to use it?
We came to the conclusion that we needed to design the system with the same audience understanding and rigor that we’d apply to a product through a user-centered design process. Think about what the ideal state looks like and what outcomes you want to create for designers, developers, and product owners. The more clearly you understand your audience and design for them, the more folks using the platform will come back to it.
Wrapping Up
These were the biggest lessons we learned while building a modular design platform. They’re certainly not all things you should know and perhaps not even right for your particular situation, but they’re worth considering before you start.
Here are a few great starting points for you:
Stanley Wood over at Spotify wrote an awesome article about scaling Spotify’s design which you should read. Google has Material Design built on Polymer (web components). If you’re having trouble figuring out even how to advocate that your company create a set of standards, check out Brad Frost’s Atomic Design ebook. He provides a whole list of things you can do to get that conversation going. One of the things that worked well for us was the Design UI Audit. The button collage earlier in this article was one artifact from ours. It can paint a very clear picture of the experience your users are having to almost anyone.
If you’re interested in learning more about my team’s experience or want more information about Riot, feel free to comment below or reach out to me. I’m interested in hearing your thoughts and misadventures regarding what you’ve learned while making modular design.
Thanks for reading.
