Steven Striegel

I don’t remember much about my first web design class. But I distinctly remember using the eyedropper tool in PaintShop Pro for the first time. I remember picking a color directly from a photograph on my page and then copy/pasting that hex value into my css and changing the text color for my *entire* website. What a rush. The ability to change how someone experiences reading on the web, no matter how small, is rewarding for a designer. Redesigning our corporate blog was no different. We had been dissatisfied with our blog situation for a while and we finally decided "Let's just design and build our own."

A small plan and a few design principles

I’m sure you can find plenty of content marketing pieces on “how to design the best blog” so I’m going to mostly skip process stuff. *But where and how should I begin?* I always get paralyzed by this question so my only guidance on process comes from a John Cage quote: 

“Begin anywhere.”

And we did just that. We got our small group together and asked what objectives we had for the blog and what our guiding design principles should be. Next, Dylan (my developer counterpart for this project) and I jumped into our separate workflows. He started on the backend and migration process (you can read about that here), I worked through the designs, and we removed blockers for each other along the way. We had four design principles that guided us:

Reading experience above all else

A mobile-first reader’s journey

Typography over images

The writing process should be easy

(1) Reading experience above all else

At Mux we spend a significant amount of effort writing blog posts. It’s one of the main ways we communicate our ideas and share new features. We’re writing deep technical posts and well thought out stories, not listicles that people skim to look for images and links. The content has to be the focus. Not the CTA’s, not the signups, not the subscribe forms. Our audience is made up of developers and video experts, people that want to read thoroughly and not be interrupted.

This might seem like an obvious goal when designing a blog but if you spend time looking around at corporate blogs it’s clear they have a lot of other competing goals. The thing about designing a good reading experience is that it’s mostly just saying no to things.






A good reading experience for us looks like:


No obnoxious CTA’s, especially ones that happen mid-article

No social sharing icons (does anyone actually trust clicking one of these?)

No thin, light gray fonts (our old visual identity loved these). Instead we’ve moved to larger text sizes and darker colors for better accessibility.

No comments or disqus, we’d rather discussions happen on places like twitter or hackernews (pro tip: you’ll want to have strategies in place to prepare for this wild beast)

Yes to subtle queues like read time and progress indicators (great for reading long posts on mobile)



Okay, sounds idyllic and all but we’re still a business and we have goals to hit with our website. So assuming people do have a good reading experience, what should be next for them? What are the ideal actions we want them to take?


Drive traffic to mux.com. This surprisingly was a big problem with our old blog. The template didn’t allow us to design a nice/intuitive navigation experience that integrated closely with our normal website. Readers are often new to Mux and want to learn more about our company but previously they didn’t have an easy single-click way to get to mux.com.

Share it (with a colleague or on social media) Some of our most successful blog posts are often ones that have made the front page of hacker news or get circulated internally at companies/teams we think highly of.

Read more of our writing. Pretty straightforward. If the reader likes our writing we want them to find more of it.

Subscribe to our newsletter. If the reader enjoyed what they read and wants to stay informed on what Mux is up to, enter the good ol’ newsletter.

Now this is where I think a lot of blogs get it wrong. They look at this list of actions as just that, a list. They figure out how to make all of these actions available to the reader at the same time but really these actions all have very different places in the reader journey and require different context. Our second design principle helped us break up these actions and figure out how to sprinkle them throughout the reader's journey.

(2) A mobile-first reader’s journey

The common occurrence of opening a blog post from twitter was reason enough to focus on a mobile-first approach but it also helped us exercise constraint when starting to design. It’s very easy just to glom all the actions together into a spacious desktop experience. So before starting any visual design I created some really simple wireframes (adding desktop as well) to help us answer the “where do you want to go from here?” question for each part of the reader journey.

Let's start at the top of an individual post: Arguably the most valuable section. It’s also the section that’s easiest to clutter with that extra junk we talked about. If readers don’t make it past this section and actually read the article what would they care about at this point? One common scenario is a viewer who isn’t interested in reading right at that moment–maybe they just want to see who Mux is or maybe they want to see the blog overview to see what we write about. This was where it was important to have a link to our main website as well as the blog home/overview. Another scenario is the return visit from someone who remembered the post from before and wants to verify it before copying the link to share it.

Halfway through: People form opinions early and share articles before they’ve finished reading. We all do it. To share something you need the URL and most developers (myself included) are going to delete those junk tracking parameters added to the end so let’s just agree to not do that. We stuck with a simple, click-to-copy button that gives you the base-only url. 

However after testing it first on mobile I realized the most common mobile browsers (Safari and Chrome) now have easy “Copy Link” options that only require only two taps. We ended up removing this from taking up coveted mobile real estate.

When you’re halfway through reading a post, it may be likely that you forgot the title of what you’re reading and when you share it, you’ll want the title for context. We figured if we added the title in a fixed nav bar there would be no need to scroll back to the top and get distracted. Again, this was not needed on mobile as you see a bit of a link preview after tapping the share icon.

Those wonderful people that made it to the bottom of the post: While this is likely our most engaged viewer it’s rare that someone is ready to sign up for a product trial immediately after reading a blog post. The more likely scenario is that they’ll visit our website to learn more about our products, perhaps read more of our writing, or look for a way to stay informed to get more of our writing in the future.

Moving beyond the mobile

The nice part about nailing the mobile experience first is that it allows you to use your desktop space in more interesting ways like expanding the width of components that can really take advantage (e.g. images, code blocks, data tables). 


Because you know, it’s free real estate.

(3) Typography over images

The aesthetic choices for our blog design were mostly inspired by editorial publications rather than other corporate blogs. A problem I started noticing was that a lot of the editorial and blog examples we liked relied on commissioned art and photography or an in-house illustrator to design cover graphics. As a small startup without access to any of this, I chose to lean heavily on typography to evolve the aesthetic we started with.

I created an are.na channel to collect layouts, interactions, and type treatments that we liked


We’ve been using the Akkurat typeface from Lineto since early on. Early on however we used the thin 200 weight of Akkurat and, when combined with our light grays, it became very inaccessible. Instead we’re now applying a big bold treatment which really embraces our direct and occasionally cheeky blog titles. Balancing this with the technical aptitude of Akkurat Mono for annotating details makes for a solid pairing.

Visual design: Starting with the body text

The obvious starting point for the visual design of a blog is the text body. It’s the main vehicle for the words and everything else is there only to support it. The width of the text body is usually determined by a combination of type scale and readability. I generally shoot for an average of 12 words per line on desktop and cut that in half for mobile.

Type scales

What is a type scale and why do I need it? If you really want to understand the math and aesthetics behind type scales, learn from an expert like Tim Brown. My oversimplified takeaway: for visual consistency you want to limit the number headline sizes you use and why not base those choices off of a natural, mathematical scale that looks nice visually. It’s less about “this should be an H1 vs an H2” and more about here’s a multiplier to give you a list of steps you can choose from. Steps that we already know will look good and keep us consistent. Luckily there’s a handy little online tool to help you out.

Full disclosure: while designing our type scale last year I used this tool more as a guide than as a hard set of rules. Asking my engineers to deal with arbitrary decimal places felt silly. After reading Frank Chimero’s excellent deep dive on his own redesign process, I felt reassured *this was okay* 😅

Mux “perfect fourth” type scale (1.33x):

67 / 50 / 38 / 28 / 21 / 18* / 16 (base) / 12

*wait, 18 isn’t on your “Perfect Fourth” scale! Nope, it’s not. But I wanted the blog to be larger and distinct from the rest of the website and guess what, it just looked good after eyeballing it. As I said before I think it’s OK to break seemingly arbitrary rules as long as there’s at least some intention behind it ¯\_(ツ)_/¯

Here’s a static image of the full Mux type scale I designed (soon to be applied to the rest of mux dot com)



I want to address one quick subject on line height: somewhere along the way the generic 150%-is-the-most-readable-line-height rule has been ingrained in every developer’s head. This is merely a suggestion which applies only to body copy where you have lengthy text in generally small sizes. Larger display fonts need much less line height because you’re reading them as a single package, i.e. a headline which is not a continuous reading experience.



The prototyping process

Mockups can only tell you so much about how well a design will work with such a wide range of content. Crazy long titles to three word titles, small gifs to wide aspect ratio cover images, code samples, multiple authors, etc. There was so much to visualize and I couldn’t predict how all of the content would respond. Our prototyping process was done more on the front end than with design tools. Because Dylan was able to migrate our old blog post content quickly, he was then able to build quick front end prototypes where I could inspect the elements and tweak things in Chrome’s dev tools to see how it felt. Sitting right next to each other* and going back and forth on nuanced details made this actually kind of fun and allowed us to perfect those small details that are often ignored. *Before you get concerned about social distancing I should add that this was clearly a pre-covid world and as much as I like to see remote work prosper, I definitely miss the ease of collaboration that the office allowed.

An early mobile prototype to test the visual design of the reading experience


(4) The writing process should be easy

I initially wanted this last design principle to be ‘Make writing enjoyable’ but let’s be honest, writing is hard. It’s not going to be enjoyable for everyone. Instead, we focused on improving all of those little inconveniences that make the process so frustrating. We figured that simplifying the workflow of getting a blog post out would be a huge win in itself.



Cover images

This is always more of a struggle than it needs to be. Many blog templates have cover images as these big, beautiful full-width placeholders. This can put extra pressure on the writer because it makes the image that much more important. Instead we made them a more manageable, flexible size and put them right next to the title to help add context.

^^ Our previous approach (and most blog templates): “Hey add a photograph of something beautiful that will take up half of the opening landing page and be the visual representation of your writing. No pressure. Oh and source it on your own and make sure it works with other elements on the page like the logo.”

^^ Our new approach: Add whatever image works for the tone of your post. From gifs of memes to technical diagrams, our new layout will make it work and keep it alongside your title for context.


Knowing exactly how your post will look

How and where your post is viewed determines if it gets clicked and read. How will this look in search results? How will this look on Twitter? Is my title too long? Is my image too obscure? What will it look like if viewed in this very-specific way? All of those little unknowns can be crippling for a writer.

Not only did Dylan build a nice web preview but he also added SEO previews right in the CMS.

Adding code

Because we write for developers, and many of our writers are developers, we really care about how to import and display code. Initially I thought simply having things like accessible colors, nice line heights, and monospace fonts was good enough but I learned very quickly that we had to make it easy and compatible with developer workflows. Syntax highlighting was really necessary for long blocks with specific language requirements. Gists were needed for really long code samples that synced with an actual Github Gist file. Later on we also added sandboxes like the Glitch code editor for more interactive code samples.

Multiple authors

Very few projects are complete solo efforts. Just like it’s much easier to have teammates to help build something it’s also easier to have help writing about that something that you built.

Knowing how well it’s performing

Not everyone has access to Google Analytics or even if they do they’re not likely to login and know where to look at the performance of their post. We added some basic stats integrated right into the CMS. We thought making this look like a leaderboard also might add a nice little competitive incentive.


So... Has all of this been effective?



^^ The Mux team since launching the new process + design



I don’t remember much about my first web design class. But I distinctly remember using the eyedropper tool in PaintShop Pro for the first time. I remember picking a color directly from a photograph on my page and then copy/pasting that hex value into my css and changing the text color for my *entire* website. What a rush. The ability to change how someone experiences reading on the web, no matter how small, is rewarding for a designer. Redesigning our corporate blog was no different. We had been dissatisfied with our blog situation for a while and we finally decided "Let's just design and build our own."

I’m sure you can find plenty of content marketing pieces on “how to design the best blog” so I’m going to mostly skip process stuff. *But where and how should I begin?* I always get paralyzed by this question so my only guidance on process comes from a 

And we did just that. We got our small group together and asked what objectives we had for the blog and what our guiding design principles should be. Next, Dylan (my developer counterpart for this project) and I jumped into our separate workflows. He started on the backend and migration process (you can read about that 

), I worked through the designs, and we removed blockers for each other along the way. We had four design principles that guided us:

At Mux we spend a significant amount of effort writing blog posts. It’s one of the main ways we communicate our ideas and share new features. We’re writing deep technical posts and well thought out stories, not listicles that people skim to look for images and links. The content has to be the focus. Not the CTA’s, not the signups, not the subscribe forms. Our audience is made up of developers and video experts, people that want to read thoroughly and not be interrupted.

This might seem like an obvious goal when designing a blog but if you spend time looking around at corporate blogs it’s clear they have a lot of other competing goals. The thing about designing a good reading experience is that it’s mostly just saying no to things.


A good reading experience for us looks like:


No obnoxious CTA’s, especially ones that happen mid-article

No social sharing icons (does anyone actually trust clicking one of these?)

No thin, light gray fonts (our old visual identity loved these). Instead we’ve moved to larger text sizes and darker colors for better accessibility.

No comments or disqus, we’d rather discussions happen on places like twitter or hackernews (pro tip: you’ll want to have strategies in place to prepare for this wild beast)

Yes to subtle queues like read time and progress indicators (great for reading long posts on mobile)

Okay, sounds idyllic and all but we’re still a business and we have goals to hit with our website. So assuming people do have a good reading experience, what should be next for them? What are the ideal actions we want them to take?


 This surprisingly was a big problem with our old blog. The template didn’t allow us to design a nice/intuitive navigation experience that integrated closely with our normal website. Readers are often new to Mux and want to learn more about our company but previously they didn’t have an easy single-click way to get to mux.com.

Share it (with a colleague or on social media)

 Some of our most successful blog posts are often ones that have made the front page of hacker news or get circulated internally at companies/teams we think highly of.

Pretty straightforward. If the reader likes our writing we want them to find more of it.

 If the reader enjoyed what they read and wants to stay informed on what Mux is up to, enter the good ol’ newsletter.

Now this is where I think a lot of blogs get it wrong. They look at this list of actions as just that, a list. They figure out how to make all of these actions available to the reader at the same time but really these actions all have very different places in the reader journey and require different context. Our second design principle helped us break up these actions and figure out how to sprinkle them throughout the reader's journey.

The common occurrence of opening a blog post from twitter was reason enough to focus on a mobile-first approach but it also helped us exercise constraint when starting to design. It’s very easy just to glom all the actions together into a spacious desktop experience. So before starting any visual design I created some really simple wireframes (adding desktop as well) to help us answer the “where do you want to go from here?” question for each part of the reader journey.

Let's start at the top of an individual post: 

Arguably the most valuable section. It’s also the section that’s easiest to clutter with that extra junk we talked about. If readers don’t make it past this section and actually read the article what would they care about at this point? One common scenario is a viewer who isn’t interested in reading right at that moment–maybe they just want to see who Mux is or maybe they want to see the blog overview to see what we write about. This was where it was important to have a link to our main website as well as the blog home/overview. Another scenario is the return visit from someone who remembered the post from before and wants to verify it before copying the link to share it.

People form opinions early and share articles before they’ve finished reading. We all do it. To share something you need the URL and most developers (myself included) are going to delete those junk tracking parameters added to the end so let’s just agree to not do that. We stuck with a simple, click-to-copy button that gives you the base-only url. 

However after testing it first on mobile I realized the most common mobile browsers (Safari and Chrome) now have easy “Copy Link” options that only require only two taps. We ended up removing this from taking up coveted mobile real estate.

When you’re halfway through reading a post, it may be likely that you forgot the title of what you’re reading and when you share it, you’ll want the title for context. We figured if we added the title in a fixed nav bar there would be no need to scroll back to the top and get distracted. Again, this was not needed on mobile as you see a bit of a link preview after tapping the share icon.

Those wonderful people that made it to the bottom of the post: 

While this is likely our most engaged viewer it’s rare that someone is ready to sign up for a product trial immediately after reading a blog post. The more likely scenario is that they’ll visit our website to learn more about our products, perhaps read more of our writing, or look for a way to stay informed to get more of our writing in the future.

The nice part about nailing the mobile experience first is that it allows you to use your desktop space in more interesting ways like expanding the width of components that can really take advantage (e.g. images, code blocks, data tables). 


Because you know, it’s free real estate.

The aesthetic choices for our blog design were mostly inspired by editorial publications rather than other corporate blogs. A problem I started noticing was that a lot of the editorial and blog examples we liked relied on commissioned art and photography or an in-house illustrator to design cover graphics. As a small startup without access to any of this, I chose to lean heavily on typography to evolve the aesthetic we started with.

 to collect layouts, interactions, and type treatments that we liked


We’ve been using the Akkurat typeface from 

 since early on. Early on however we used the thin 200 weight of Akkurat and, when combined with our light grays, it became very inaccessible. Instead we’re now applying a big bold treatment which really embraces our direct and occasionally cheeky blog titles. Balancing this with the technical aptitude of Akkurat Mono for annotating details makes for a solid pairing.

Visual design: Starting with the body text

The obvious starting point for the visual design of a blog is the text body. It’s the main vehicle for the words and everything else is there only to support it. The width of the text body is usually determined by a combination of type scale and readability. I generally shoot for an average of 12 words per line on desktop and cut that in half for mobile.

What is a type scale and why do I need it? If you really want to understand the math and aesthetics behind type scales, learn from an expert like 

. My oversimplified takeaway: for visual consistency you want to limit the number headline sizes you use and why not base those choices off of a natural, mathematical scale that looks nice visually. It’s less about “this should be an H1 vs an H2” and more about here’s a multiplier to give you a list of steps you can choose from. Steps that we already know will look good and keep us consistent. Luckily there’s a handy little 

Full disclosure: while designing our type scale last year I used this tool more as a guide than as a hard set of rules. Asking my engineers to deal with arbitrary decimal places felt silly. After reading Frank Chimero’s excellent deep dive on his own 

Mux “perfect fourth” type scale (1.33x):

67 / 50 / 38 / 28 / 21 / 18* / 16 (base) / 12

*wait, 18 isn’t on your “Perfect Fourth” scale! Nope, it’s not. But I wanted the blog to be larger and distinct from the rest of the website and guess what, it just looked good after eyeballing it. As I said before I think it’s OK to break seemingly arbitrary rules as long as there’s at least some intention behind it ¯\_(ツ)_/¯

Here’s a static image of the full Mux type scale I designed (soon to be applied to the rest of mux dot com)

I want to address one quick subject on line height: somewhere along the way the generic 150%-is-the-most-readable-line-height rule has been ingrained in every developer’s head. This is merely a suggestion which applies only to body copy where you have lengthy text in generally small sizes. Larger display fonts need much less line height because you’re reading them as a single package, i.e. a headline which is not a continuous reading experience.

Mockups can only tell you so much about how well a design will work with such a wide range of content. Crazy long titles to three word titles, small gifs to wide aspect ratio cover images, code samples, multiple authors, etc. There was so much to visualize and I couldn’t predict how all of the content would respond. Our prototyping process was done more on the front end than with design tools. Because Dylan was able to migrate our old blog post content quickly, he was then able to build quick front end prototypes where I could inspect the elements and tweak things in Chrome’s dev tools to see how it felt. Sitting right next to each other* and going back and forth on nuanced details made this actually kind of fun and allowed us to perfect those small details that are often ignored. *Before you get concerned about social distancing I should add that this was clearly a pre-covid world and as much as I like to see remote work prosper, I definitely miss the ease of collaboration that the office allowed.

An early mobile prototype to test the visual design of the reading experience

I initially wanted this last design principle to be ‘Make writing enjoyable’ but let’s be honest, writing is hard. It’s not going to be enjoyable for everyone. Instead, we focused on improving all of those little inconveniences that make the process so frustrating. We figured that simplifying the workflow of getting a blog post out would be a huge win in itself.

This is always more of a struggle than it needs to be. Many blog templates have cover images as these big, beautiful full-width placeholders. This can put extra pressure on the writer because it makes the image that much more important. Instead we made them a more manageable, flexible size and put them right next to the title to help add context.

Our previous approach (and most blog templates): “Hey add a photograph of something beautiful that will take up half of the opening landing page and be the visual representation of your writing. No pressure. Oh and source it on your own and make sure it works with other elements on the page like the logo.”

^^ Our new approach: Add whatever image works for the tone of your post. From gifs of memes to technical diagrams, our new layout will make it work and keep it alongside your title for context.


How and where your post is viewed determines if it gets clicked and read. How will this look in search results? How will this look on Twitter? Is my title too long? Is my image too obscure? What will it look like if viewed in this very-specific way? All of those little unknowns can be crippling for a writer.

Not only did Dylan build a nice web preview but he also added SEO previews right in the CMS.

Because we write for developers, and many of our writers are developers, we really care about how to import and display code. Initially I thought simply having things like accessible colors, nice line heights, and monospace fonts was good enough but I learned very quickly that we had to make it easy and compatible with developer workflows. Syntax highlighting was really necessary for long blocks with specific language requirements. Gists were needed for really long code samples that synced with an actual Github Gist file. Later on we also added sandboxes like the Glitch code editor for more interactive code samples.

Very few projects are complete solo efforts. Just like it’s much easier to have teammates to help build something it’s also easier to have help writing about that something that you built.

Not everyone has access to Google Analytics or even if they do they’re not likely to login and know where to look at the performance of their post. We added some basic stats integrated right into the CMS. We thought making this look like a leaderboard also might add a nice little competitive incentive.

^^ The Mux team since launching the new process + design

At Mux we spend a significant amount of effort writing blog posts. We had been dissatisfied with our blog situation for far too long and we finally decided just to design and develop our own.

Let's just design our own blog

Let's just design our own corporate blog

Since launching our Real-Time Streaming Dashboard a few months ago we’ve already seen it have enormous impact. We’ve watched teams all around the globe use the dashboard to monitor their big events and live video performance. Now we’re giving it a powerful little update: seven new filter dimensions.

Different teams need different data

This is something our user research has shown from the start and is one of our guiding design principles. Large organizations often have specialized roles or even entire teams dedicated to different platforms and/or players. A large broadcast media operations team responsible for 7 million concurrent viewers obviously has very different needs than a small startup live streaming user-generated content through a single native app. They likely care about the same real-time metrics but how they slice the data is going to vary.

Now with real-time filtering you can set up to seven filters (one for each dimension) based on your prioritized content or infrastructure needs. This means being able to set conditions around the exact data you want to see and create as many unique dashboards as you need: every team, screen, or "war room" can get the view that makes the most sense for them.

Real-time filter dimensions:

Operating System

Stream Type (live or on-demand)

Video Title

ASN (Autonomous System Number) [coming soon]

CDN (Content Delivery Network) [coming soon]

Player Name [coming soon]

Country

Sub-country regions/states [coming soon]



Favorite and share filtered dashboards

Just like in our historical metrics and Mux Data API, when you add a filter it’s added to the dashboard URL as a query string. This allows you to easily save filtered dashboard views in your browser favorites and share links of these filtered views across your team.

Filtered dashboard URL example:
dashboard.mux.com/environments/[environment_id]/realtime?filters=operating_system:iOS



A hint at what’s next for Real Time

“Isolate the problem as quickly as possible” has been another guiding principle for our real-time metrics. While filters help isolate the problem, we want to help you do that much more quickly and efficiently. Stay tuned for more on that, but in the meantime contact us for a demo of the real-time dashboard with live streaming data. 📈

 a few months ago we’ve already seen it have enormous impact. We’ve watched teams all around the globe use the dashboard to monitor their big events and live video performance. Now we’re giving it a powerful little update: seven new filter dimensions.

This is something our user research has shown from the start and is one of our guiding design principles. Large organizations often have specialized roles or even entire teams dedicated to different platforms and/or players. A large broadcast media operations team responsible for 7 million concurrent viewers obviously has very different needs than a small startup live streaming user-generated content through a single native app. They likely care about the same real-time metrics but how they slice the data is going to vary.

Now with real-time filtering you can set up to seven filters (one for each dimension) based on your prioritized content or infrastructure needs. This means being able to set conditions around the exact data you want to see and create as many unique dashboards as you need: every team, screen, or "war room" can get the view that makes the most sense for them.

Just like in our historical metrics and Mux Data API, when you add a filter it’s added to the dashboard URL as a query string. This allows you to easily save filtered dashboard views in your browser favorites and share links of these filtered views across your team.

dashboard.mux.com/environments/[environment_id]/realtime?filters=operating_system:iOS

“Isolate the problem as quickly as possible” has been another guiding principle for our real-time metrics. While filters help isolate the problem, we want to help you do that much more quickly and efficiently. Stay tuned for more on that, but in the meantime 

 for a demo of the real-time dashboard with live streaming data. 📈

Introducing filters for the Real-Time Dashboard

Since launching our real-time dashboard a few months ago we’ve seen it have enormous impact. Now it gets a powerful little update: 7 new filter dimensions.

Introducing filters for the real-time dashboard

This is part one in a two part series about how we revamped the charts in our video analytics product. If acronyms like D3, obscure javascript references, and absurdly-named dev tools are your thing, you'll have to wait for part two (subscribe). Otherwise, read on for a look at our design process behind the new charts.

We work with some large datasets at Mux (I refuse to describe data as big). Data visualization and aggregation happen to be great tools to tell a story about a lot of data, yet they can be contentious topics around the web. I think what makes data visualization so interesting is that it's this rare intersection of two different worlds: the world of objective, "cold hard math" and the world of aesthetics and visual communication.

When we wanted to revisit our charts, we looked at them from both of these perspectives and asked ourselves: Are we being truthful to our calculations? And, are we presenting the data in a beautiful and sensible manner?

Problems with our old charts

After looking through these two lenses, we had all sorts of grandiose ideas about how we could improve our charts. But before jumping headfirst into a new charting library to play around, we knew it was important to define the problems we wanted to solve that our existing charts couldn’t. We ended up defining five specific problems:

Aggregation + line charts can be misleading.

Data spikes needed context.

Breaks in low-volume data resulted in ugly, unhelpful visualizations.

Comparing dimensions got unwieldy, especially for the color blind.

Gridlines, axis labels, and tooltips were causing visual clutter.

1. Aggregation + line charts can be misleading.

Line charts are great at showing data trends over time, but they imply a continuous, sequential data series. Each data point in our platform is actually an hour of aggregated video view data. Was this clear to our users? How might we better communicate where the aggregation is happening? Were we just connecting dots to make pretty lines and not being truthful to the data?



2. Data spikes needed context.

Product designers often talk about how good data visualization shouldn’t just answer questions about data but also surface new questions. Completely agree. But, if you’re getting the same question every time, why not help answer that question early on in the user’s data discovery process? We realized almost every time a customer had a spike in their data we’d get the same question...

“What was my volume during that time?”

Even after they asked this question, we had no good way in our UI to provide them with an answer.

3. Breaks in low-volume data resulted in ugly, unhelpful visualizations.

Not all of our customers have large, steady volumes of video views and we needed to make sure our charts provided value no matter the volume. Our mission is to help everyone build better video. That solo developer doing video for the first time is going to need our metrics more than anyone, but they’re not likely to have much volume right away.



With our old charts, users might not even see the tiny pink specks of data because the specks aren’t connected to another data point. In other words, our users couldn’t even tell where they had data in the first place if their volume was low.

4. Comparing dimensions got unwieldy, especially for the color blind.

Quickly comparing different dimension values helps our users get context to issues as well as assess their relative severity. While our tabular UI was great at this, our multi-line chart was messy and difficult to interpret. Trying to hover for details of a specific time period was even more problematic.



On top of all that, I ran a color blindness tool and realized we had some accessibility issues with Deuteranopia, the most common form of color blindness.

5. Gridlines, axis labels, and tooltips were causing visual clutter.

Sadly, these elements are often overlooked details in chart design. Does anyone actually use gridlines and axis labels or do they simply read the tooltip? Can we get away with just horizontal gridlines? Or would vertical lines be better? What about both? Should they be dotted or have transparency?

Designers and developers are often lazy with gridlines and axis labels because customizing them requires a lot of small decisions about something that’s not directly representing data. Even though these decisions don’t affect the data itself, how you frame lines around your data will affect how the user perceives it. For example, using very few vertical-only gridlines and few axis labels gives the data a lot of beautiful whitespace, but it feels more like an estimate rather than a precise representation.

The old tooltips didn’t snap to data points and were clearly not written for humans to read.

Designing a solution

Once we had these problems mapped out we added the high level questions we wanted to answer for our users:

Where are my viewers experiencing problems?

How has METRIC been trending?

Where have we had spikes or issues over TIMEFRAME ? And for METRIC ?

Are we spiking during certain times of day?

Is there a relationship between METRIC and my volume?

I also set three guidelines for myself as I mocked up different solutions:

The charts should always be answering a user question (above) as quickly as possible.

Use as much real data as possible. (InVision’s Craft plugin for Sketch is super helpful)

Any given chart type should scale to different amounts of data points, including broken/ low-volume data.

I tried A LOT of chart variations, always testing scale of timeframes and granularity.

What about the classic bar chart? 📊

Looking at problem #1 (accuracy in aggregation) and #3 (breaks in low volume) I asked myself if bar charts would be more appropriate because each bar represents a 1 hour window of aggregation. There’s no false connection implying data that isn’t there. Yes… YES. I was getting somewhere and excited about the bars as I mocked up different amounts of data points. I even started playing around with different styling.



And then I had to think about comparing multiple dimension values (e.g. browser types)… and the wind left my sails, or maybe I just let out an audible sigh. How would we use bars for multiple dimension values? Side-by-side bars were not going to work with four or more dimension values. Stacked bar charts would not make for good comparisons of each individual trend either (and let’s be honest, stacked bar charts are almost never a good idea).

I even tried dumb things like the image above. Then we thought about going back to a line chart for comparisons, but we didn’t want to switch visualization types when a user went from the main metric chart to comparing dimensions; it would be too disruptive to an important user flow.

Let's make a decision

After flip-flopping seventeen more times (according to my engineering counterparts), I came back to a modified version of the original line chart with three seemingly small yet significant changes:

Filling in the area below the line (not necessarily a true area chart... we weren’t doing any of that stacking/overlapping nonsense).

Adding big ol’ dots for every data point (where aggregation was happening).

Adding a new secondary bar chart below to show volume impact over time.


Friendlier visualizations for our low-volume friends.

By filling the area below the line we added a tangible aspect to the data, making gaps in data obvious. The vertical wall of the fill made it easier to tell where the data stopped and started. The large dots for every data point helped this even further.



Better comparisons for all.

Another perk of the large data points was that they made for better comparisons by allowing users to see where different values line up vertically. You’ll notice we dropped the area below the lines when comparing two or more values to help users see what is above and below. We also capped the comparison limit to four values based on usage stats and sheer intelligibility.

Oh, and the new charts are now color blind accessible for Deuteranopia, Protanopia, and Tritanopia. 😀



Making interactions, tooltips, grids, and guides feel precise.

At Mux we pride ourselves on the accuracy of our data, it’s a differentiator for us. We wanted our charts to represent this accuracy and even feel precise. To do this we chose to use both horizontal and vertical gridlines. We added a vertical guide to show exactly what timeframe a user is hovering within. We cut out any delay in the tooltip. And we chose dashed lines for the grid to further help the user delineate between a line that is representing data and a line that is just there as a visual reference.


Fancy new tooltips 💅

Improved responsiveness of charts. More to come.

Charting ahead

(Sorry, I couldn't help myself)

By the time this blog post goes out, we’ll probably have at least 3 more changes made to our charts. In fact, I feared this post might never go out. Every time I sat down to write about our thought process or grab a screenshot of real data, I found more areas we needed to reexamine. Then I ended up waiting around for those new changes to be implemented to finish writing. It’s a vicious cycle. But the beauty of being a bumbling solo product designer in a sea of super efficient engineers is that they push you to get stuff out before you’re comfortable with it. Well “push” is being generous; they just launch the stuff.

Anyways, the feedback from our customers has been great so far and we always want more. I'd love to hear from you on Twitter @MuxHQ, even if it's just to pick a fight about things I despise like spline interpolation, stacked bar charts, or bashing the innocent pie chart. Yes, contrary to all the trendy tweets, I believe pie charts still have a small place in this world.

Stay tuned for part two where Matt McClure talks about how we actually built these charts.

Shameless plug: If you’d like to see your video performance data visualized with our new charts, head on over to our self-serve sign-up page and integrate in minutes.

This is part one in a two part series about how we revamped the charts in our video analytics product. If acronyms like D3, obscure javascript references, and absurdly-named dev tools are your thing, you'll have to wait for part two (

). Otherwise, read on for a look at our design process behind the new charts.

We work with some large datasets at Mux (I refuse to describe data as big). Data visualization and aggregation happen to be great tools to tell a story about a lot of data, yet they can be contentious topics around the web. I think what makes data visualization so interesting is that it's this rare intersection of two different worlds: the world of objective, "cold hard math" and the world of aesthetics and visual communication.

When we wanted to revisit our charts, we looked at them from both of these perspectives and asked ourselves: Are we being truthful to our calculations? And, are we presenting the data in a beautiful and sensible manner?

After looking through these two lenses, we had all sorts of grandiose ideas about how we could improve our charts. But before jumping headfirst into a new charting library to play around, we knew it was important to define the problems we wanted to solve that our existing charts couldn’t. We ended up defining five specific problems:

Aggregation + line charts can be misleading.

Breaks in low-volume data resulted in ugly, unhelpful visualizations.

Comparing dimensions got unwieldy, especially for the color blind.

Gridlines, axis labels, and tooltips were causing visual clutter.

1. Aggregation + line charts can be misleading.

Line charts are great at showing data trends over time, but they imply a continuous, sequential data series. Each data point in our platform is actually an hour of aggregated video view data. Was this clear to our users? How might we better communicate where the aggregation is happening? Were we just connecting dots to make pretty lines and not being truthful to the data?

Product designers often talk about how good data visualization shouldn’t just answer questions about data but also surface new questions. Completely agree. But, if you’re getting the same question every time, why not help answer that question early on in the user’s data discovery process? We realized almost every time a customer had a spike in their data we’d get the same question...

“What was my volume during that time?”

Even after they asked this question, we had no good way in our UI to provide them with an answer.

3. Breaks in low-volume data resulted in ugly, unhelpful visualizations.

Not all of our customers have large, steady volumes of video views and we needed to make sure our charts provided value no matter the volume. Our mission is to help 

 build better video. That solo developer doing video for the first time is going to need our metrics more than anyone, but they’re not likely to have much volume right away.

With our old charts, users might not even see the tiny pink specks of data because the specks aren’t connected to another data point. In other words, our users couldn’t even tell where they had data in the first place if their volume was low.

4. Comparing dimensions got unwieldy, especially for the color blind.

Quickly comparing different dimension values helps our users get context to issues as well as assess their relative severity. While our tabular UI was great at this, our multi-line chart was messy and difficult to interpret. Trying to hover for details of a specific time period was even more problematic.

On top of all that, I ran a color blindness 

 and realized we had some accessibility issues with Deuteranopia, the most common form of color blindness.

5. Gridlines, axis labels, and tooltips were causing visual clutter.

Sadly, these elements are often overlooked details in chart design. Does anyone actually use gridlines and axis labels or do they simply read the tooltip? Can we get away with just horizontal gridlines? Or would vertical lines be better? What about both? Should they be dotted or have transparency?

Designers and developers are often lazy with gridlines and axis labels because customizing them requires a lot of small decisions about something that’s not directly representing data. Even though these decisions don’t affect the data itself, how you frame lines around your data will affect how the user perceives it. For example, using very few vertical-only gridlines and few axis labels gives the data a lot of beautiful whitespace, but it feels more like an estimate rather than a precise representation.

The old tooltips didn’t snap to data points and were clearly not written for humans to read.

Once we had these problems mapped out we added the high level questions we wanted to answer for our users:

Where are my viewers experiencing problems?

Are we spiking during certain times of day?

I also set three guidelines for myself as I mocked up different solutions:

The charts should always be answering a user question (above) as quickly as possible.

Use as much real data as possible. (InVision’s 

Any given chart type should scale to different amounts of data points, including broken/ low-volume data.

I tried A LOT of chart variations, always testing scale of timeframes and granularity.

Looking at problem #1 (accuracy in aggregation) and #3 (breaks in low volume) I asked myself if bar charts would be more appropriate because each bar represents a 1 hour window of aggregation. There’s no false connection implying data that isn’t there. Yes… YES. I was getting somewhere and excited about the bars as I mocked up different amounts of data points. I even started playing around with different styling.

And then I had to think about comparing multiple dimension values (e.g. browser types)… and the wind left my sails, or maybe I just let out an audible sigh. How would we use bars for multiple dimension values? Side-by-side bars were not going to work with four or more dimension values. Stacked bar charts would not make for good comparisons of each individual trend either (and let’s be honest, stacked bar charts are almost never a good idea).

I even tried dumb things like the image above. Then we thought about going back to a line chart for comparisons, but we didn’t want to switch visualization types when a user went from the main metric chart to comparing dimensions; it would be too disruptive to an important user flow.

After flip-flopping seventeen more times (according to my engineering counterparts), I came back to a modified version of the original line chart with three seemingly small yet significant changes:

Filling in the area below the line (not necessarily a true area chart... we weren’t doing any of that stacking/overlapping nonsense).

Adding big ol’ dots for every data point (where aggregation was happening).

Adding a new secondary bar chart below to show volume impact over time.

Friendlier visualizations for our low-volume friends.

By filling the area below the line we added a tangible aspect to the data, making gaps in data obvious. The vertical wall of the fill made it easier to tell where the data stopped and started. The large dots for every data point helped this even further.

Another perk of the large data points was that they made for better comparisons by allowing users to see where different values line up vertically. You’ll notice we dropped the area below the lines when comparing two or more values to help users see what is above and below. We also capped the comparison limit to four values based on usage stats and sheer intelligibility.

Oh, and the new charts are now color blind accessible for Deuteranopia, Protanopia, and Tritanopia. 😀

Making interactions, tooltips, grids, and guides feel precise.

At Mux we pride ourselves on the accuracy of our data, it’s a differentiator for us. We wanted our charts to represent this accuracy and even 

 precise. To do this we chose to use both horizontal and vertical gridlines. We added a vertical guide to show exactly what timeframe a user is hovering within. We cut out any delay in the tooltip. And we chose dashed lines for the grid to further help the user delineate between a line that is representing data and a line that is just there as a visual reference.

Improved responsiveness of charts. More to come.

By the time this blog post goes out, we’ll probably have at least 3 more changes made to our charts. In fact, I feared this post might 

 go out. Every time I sat down to write about our thought process or grab a screenshot of real data, I found more areas we needed to reexamine. Then I ended up waiting around for those new changes to be implemented to finish writing. It’s a vicious cycle. But the beauty of being a bumbling solo product designer in a sea of super efficient engineers is that they push you to get stuff out before you’re comfortable with it. Well “push” is being generous; they just launch the stuff.

Anyways, the feedback from our customers has been great so far and we always want more. I'd love to hear from you on Twitter 

, even if it's just to pick a fight about things I despise like 

, stacked bar charts, or bashing the innocent pie chart. Yes, contrary to all the trendy 

, I believe pie charts still have a small place in this world.

Stay tuned for part two where Matt McClure talks about how we actually built these charts.

Shameless plug: If you’d like to see your video performance data visualized with our new charts, head on over to our self-serve sign-up 

So we redid our charts... (Part I: designs and such)

Part one in a two part series about how we revamped the charts in our video analytics product. Part two covers the technical implementation.

Steven Striegel

Let's just design our own corporate blog

Introducing filters for the Real-Time Dashboard

So we redid our charts... (Part I: designs and such)

United States

United Kingdom

Products

Mux Video

Mux Data

Docs & Tools

API SDKs

Company

Learn about video