Simplifying Screen Signage
How we redesigned Mira’s dashboard around the most common use-cases
At Mira, we’re making it dead simple to manage content on all of your screens.
In 2016, we built the first version of our web dashboard, which lets you create content from a variety of apps and publish to any connected screen.
When we designed Dashboard v1, we didn’t have a clear vision of who or what use-cases we were building for; We built it primarily to validate Mira’s core hypothesis — that screen signage was too complicated, and that we could do better.
After a year in business, we were confident that we were on the right track, but knew we could still improve significantly. By that time, we’d learned enough about our customers to redesign the dashboard around their most common needs:
- The ability to quickly publish text and image-based content
- Confidence that it will look and behave as expected on their screens
- A more direct, self-explanatory user experience
…So, we built Dashboard v2 (our current version).
Now, we’re approaching one year since we released v2, so I wanted to write a post revisiting the redesign and sharing how it’s been received so far.
Dashboard v1: How it Used to Be
From our initial conversations, we understood that customers wanted to display a wide variety of content types on their screens— from weather, to announcements, to music videos.
They wanted control over what times and days of the week content would play, and to reuse schedules across any number of screens.
We took this information and built a platform that could meet those scheduling needs and a structure to allow our team and third-party developers to build apps for creating new kinds of content.
How it Worked
Dashboard v1 was designed for a linear, content-first workflow. It had four tabbed steps, which were given equal prominence in the dashboard’s hierarchy:
Step 1) Select an app and create a presentation (single instance of an app’s related content type, such as an image or menu)
Step 2) Add that presentation to a playlist
Step 3) Add the playlist to a repeating weekly schedule
Step 4) Assign the schedule to a screen, and publish
What we Learned
We spent the next year building apps, fixing bugs, and talking to our users. Here were some of the key takeways:
Too many steps. We commonly heard users complain that they just wanted to put one picture/video on a screen, but were being funneled through what felt like 2–3 irrelevant steps first.
This was mirrored by our usage data:
- 3 in 5 playlists contained only 1 presentation
- 7 in 10 schedules contained only 1 playlist, scheduled for 24/7 coverage
The majority of users just wanted to put one or two things on a screen and let them play indefinitely.
The content-first approach wasn’t intuitive. When users logged in, they landed on the tab labeled “Apps.” In at least half of our onboarding sessions, users immediately navigated to the “Screens” tab — the very last of the four.
This told us that our flow was upside-down. Users looked for their screens before their content…and what the heck was an “app” in this context anyway?
It was still easier than whatever they were using before. User-interviews informed us that even our sub-optimal dashboard was easier to use than their previous signage solutions (digital or otherwise). This was encouraging, but there was obviously a lot of room for improvement.
Dashboard v2: How it is Now
Based on what we had learned from Dashboard v1, we defined three high-level goals for v2:
- Reduce idea-to-screen turnaround
- Surface relevant information
- Clarify user expectations
1. Reducing Idea-to-Screen Turnaround
In order to reduce the number of steps between your brain and TV, we made an effort to better prioritize common workflows in the dashboard. This meant making the “just put something on a screen indefinitely” use-case really obvious, and more advanced features, like time-specific scheduling, less obtrusive.
We created a new flow that, from the home screen, lets you add an image to a screen in just four clicks (down from around 13).
This involved turning the old process on its head and forking it. The new dashboard is screen, rather than content-first.
It ditches the linear playlist-to-schedule flow, instead giving each screen (or group of screens) its own default and scheduled content. Default content loops indefinitely, while scheduled content takes over the screen for a discrete period of time.
2. Surfacing Relevant Information
Dashboard v1 displayed most of the available interactions on a page at the same time. This static layout meant that user paths weren’t particularly clear.
In v2, we wanted to do a better job of guiding the user toward their objective, so we reduced the amount of information per view and removed steps that didn’t contribute to them achieving it.
Our approach included putting content creation flows in modal windows, sorting the library by recency, rather than apps, and removing the need to select an app before creating content — instead, simply asking the user what kind of content they’d like to add to their screens.
Dashboard v2 is intentionally more conversational than its predecessor, always suggesting what to do next, rather than just presenting a static slate of menus and controls. We always followed the doctrine of “no empty empty-states.”
3. Clarifying User Expectations
Our last major goal was to set clearer user expectations around how content would appear on their screens; This is critical, since people are often physically remote from the screens that they’re managing.
To accomplish this, we created a “builder” view with a WYSIWYG editor that updates dynamically as fields are edited. It allows users to preview their content exactly as it will appear on their screens (just scaled down a bit…), even letting them toggle between horizontal and vertical screen orientations.
You can try it out yourself in our handy-dandy builder simulator.
Process
Testing & Iterating
We wanted to start collecting user feedback as quickly as possible, so after testing some hand-sketches with our CEO and Engineering team, we put together simple wireframes in Sketch, threw them in InVision, and started testing with our “friendliest” customers (ones with whom we had personal, or just really cordial relationships, and felt comfortable sharing rougher prototypes).
These initial tests were sanity checks — aimed at making sure we weren’t heading in completely the wrong direction. Our biggest unknown was whether users would easily grasp the concept of Default vs. Scheduled Content (they did!).
We scheduled 3–4 tests at a time, giving ourselves a few days in between each wave to make adjustments.
As we grew more confident in the evolving workflow, we put some design time toward making the prototype feel a little closer to the real thing. We cleaned up the styles and added some color and icons.
At this point, we expanded our testing to a group of our more active users, spanning each of our major customer verticals. We asked them to accomplish sets of tasks, encouraged them to think out-loud, and followed up with questions about what had worked well and where they’d gotten confused or stuck.
With each iteration, feedback was getting more specific, which seemed like a good sign — The basic concepts made sense and we were now talking details.
Nuts & Bolts
Now, we could start designing to build. Working with our Engineering team, we created a library of styled React elements that would make it easy to build, iterate and expand dashboard functionality while maintaining a consistent user experience.
The final dashboard designs were composed entirely of standardized, responsive elements from this library, which we dubbed “Mira Elements.”
Mira Elements were designed and edited in a Sketch file, uploaded to a shared Craft library, and exported to a Zeplin project where our engineers could easily reference styles and instructions.
Building Mira Elements was an early investment that has already paid off. Designing new features has been a breeze, since almost all of the components and behaviors have already been defined.
So, how do they like it?
User feedback has been overwhelmingly positive in terms of dashboard usability.
We still field a lot of requests and feedback, but most now revolve around the need for specific features and apps — most of which are already on our roadmap and coming out as quickly as we can code.
Here are some of my favorite customer testimonials:
Using Mira is simple. Exploring how to add content to the Mira library was fun and we use photos just by uploading, typing a few lines, and publishing. That easy.
Denise, Ramada Spokane Airport
Mira give us the total control over an easy to operate GUI and almost idiot proof hardware.
Ian, Track 21 Indoor Karting
The simplicity of the user interface and reliability of the platform make Mira truly set-and-forget.
Mike, Kidworks
Amazing, simple to use, and has easily broadcast our food pictures and videos to our customers! Love it.
Angelo, The Baked Apple Breakfast Co.
Within 10 minutes of opening the box we were viewing our custom content on screen. Ease of use and intuitive interface insures accurate content delivery
Michael, Dogleg Left TV
There’s still endless opportunity for improvement when it comes to simplifying signage, but I’m excited to see our hard work on this project paying off every day, and couldn’t be prouder of what our small team has managed to accomplish already.
Shouts-out to our fantastic Product & Engineering teams, who put in hundreds of hours to bring Dashboard v2 to our customers—
Patrick Perini, craig huff, Kia Fathi, Eli Fisher, Aric Huang, Jordan Schroter, Ryan Oriecuia
— and to Tuan Ho and the rest of the Mira team, for providing critical feedback at every step.
