Usability in Extremes - Designing a Scalable Twitch overlay

Tagging into my first open-source project, a graphic overlay plugin for Twitch.tv, was a fantastic lesson in communication, accessibility, and collaboration. Let me tell you about it.@DesignersI joined this project from a ping on Open Source Force, a community dedicated to open source projects and the people passionate about them.

The original predictions overlay plugin (since abandoned by developer).

The dev was picking up a project to visualize real-time votes/odds in Twitch’s predictions system — for the uninitiated, here’s how it works:

1. The streamer creates a “poll” with options predicting the outcome of some event (e.g. — will this chest have a Heart Container in it? How many tries will it take to complete this level?)

2. Viewers wager a currency called channel points to vote on what they predict will happen — they have a certain amount of time (set by the streamer) to place their bet. All votes and vote tracking takes place in the chat, in a widget managed by the official Twitch platform.

3. When the time runs out, the poll switches to a “Locked” state while the prediction plays out.

4. Once the event has happened, the streamer selects which of the predictions was correct and the wagered points are distributed accordingly.

This project would take the predictions feature and metrics outside of the stream chat and place an overlay on the stream to make it more visible and to create better opportunities for audience interaction.

The original project, started by another developer, supported polls with two options (while Twitch’s feature supports up to 10 different options) and had since been abandoned.

He didn’t really know what he needed, but he knew he needed help.

Discovering the Roadmap

Our first challenge was the requirements. After a lengthy discovery session (via Figma’s in-line chat), I brought on another designer to help shoulder the load. We wanted to build fast and I needed a sanity check.

Our dev’s communication medium of choice.

To start — I charted out the screens we would need and we worked together to create a list of potential charts we could use to visualize each option. This gave us all a clear picture of how much work was going to go into this project and would help us all visualize how close we were to “done”.

In the moment, this felt like a solid plan — but we quickly realized that this was the wrong approach.

Our earliest visualization to show the screens we would be creating and possible charts to use for each.

Even in our first iteration, it was evident that our priorities were not in the right place. Whatever we created would need to be:

• Highly flexible — it would need to be able to be displayed on any background.

• Easy to maintain — as many components would need to be reused across different versions as possible. We had one dev and this was one of many projects.

• Instantly readable — testing with our first iteration showed that we couldn’t change the layout too much between different versions. Users were being inundated with content and they needed to be able to instantly understand what the overlay was trying to tell them.

Our first low-fi overlay with some of the biggest issues highlighted.

Building the Baseline

When we took our designs back to the drawing board, we changed our tactics.

• Everything was a component first — ensuring that it would be reusable through all other iterations. We wanted to change as little as possible from version to version.

• Everything needed to be accessible on the first iteration — this meant spending a lot of time testing palettes, text sizes, and the readability of animations, even in our lower fidelity designs. Each iteration was tested on six different backgrounds from real streams to challenge readability across many possible scenarios.

Light- and dark-mode mocks of our first two-option poll iteration.

This next iteration gave us a clear idea of where we were going, but user testing and collaboration with the developer helped us identify a couple of issues:

• The timer looked like a thermometer — it wasn’t easy to read and could sometimes be confusing.

• The title could be hard to read on some backgrounds — while we tried changing the title stroke to match, we ended up creating a new container to group the title and timer (this also worked better for transitions between states).

The evolution of our first design — the two-option poll.

Designing in MotionFrom here, we planned out each state and how we would navigate between them. Because space was at a premium, we would need to figure out how we got the less important data out of the way and made room for the more critical data points at each stage of the prediction.A couple of questions we had to consider —What information is most important in each state?How do we prevent viewers from having to reread info, just because it moved?In the end, we came up with the rough transition below — just high enough fidelity to communicate it to our dev.

Early prototype of the state transition for 2-option polls.

Final Step — Scale and Test

Once we had our components set, our initial round of feedback from users, and had run through any potential issues with the dev, it was just time to scale.

We had 8 more iterations to design, each with four unique states and animations to move between them. From here, it was all about laying out the design and then seeing where we could squeeze out more space without sacrificing readability or accessibility.

Percentage vote component with variants for Light Mode, Dark Mode, and each number of poll options.

Resulting in different iterations that are instantly readable and recognizable, even on the most chaotic of streamers’ backgrounds.

Comparison of two-option poll and five-option poll.

Lessons Learned

This project was a great opportunity to design for consumers, collaborate directly with a developer, and plan my own product roadmap for a larger design effort. It drove me to focus more deeply on accessibility than I have in the past and pushed me to think about all of the environments and scenarios in which my designs might be viewed.

While this project is still in active development, my fellow designer and I are still focused on troubleshooting, testing desirability, and tackling any unexpected challenges that arise. A public release should be available soon, but feel free to reach out to me directly to view a demo or to learn more about this project.