Elemental Conductor Live

<< Return to My Work


User testing for Elemental Conductor Live
User testing for Elemental Conductor Live

Case Study 1     |    Case Study 2     |     Case Study 3

Overview

Company: Elemental Technologies

Product: Elemental Conductor Live is a software management system to configure and operate clusters of multiple video encoder systems (the ‘Elemental Live’ product), designed for 1000s of channels

User Info: Conductor Live was designed to serve two personas:

  • Operators run channels and systems. They care about stability, getting clear feedback and information.
  • Engineers refine video encoder settings. They care about precision, predictable outcomes and performance.

History: A legacy version of Elemental Conductor Live had massive challenges on the topics of scale, complexity, and stability. Upgrading clusters was very time consuming, resource heavy, and risky.

Conductor Live 2 (a.k.a ‘Conductor Classic’)
The Legacy Product: Conductor Live 2 (a.k.a ‘Conductor Classic’) had a very limited ability to scale, cumbersome operation features, and unclear redundancy management.

Mission: Design the UX for an entirely new product version with improved workflows, the ability to scale smoothly, reduced information complexity, and overall stability. Align consensus on scope and timing. Program manage the development and test teams through the initial release, and 15 subsequent version releases.

Conductor Live 3 (a.k.a ‘Superconductor’)
The New Product: Conductor Live 3 (a.k.a ‘Superconductor’) included wide open scaling, designed for 1000s of channels spanning 100s of systems. It also brought efficient operations tools and clear redundancy management.

Roles: UX Designer, UX Researcher, Information Architect, Business Analyst, Program Manager, Release Manager

UX Design Process: I met with target users (representing both Engineer and Operator personas), and team service engineers tasked with cluster setup and maintenance to identify the top needs and priorities. I worked with developers to identify technical constraints and drove consensus for the technical architectural decisions. I then developed low fidelity wireframes, information architecture docs, workflow stories, and use case stories, performing multiple review and iteration cycles with users, stakeholders, developers, and testers.

Program Management: I formed the product requirements, higher detailed mockups, and use case stories for the development team. Before my involvement, the project was poorly defined and had unrealistic targets, taking a toll on morale. Through user research, wireframe and story review, and thoughtful team planning, I helped the team and stakeholders find consensus on a challenging yet attainable MVP target. I then led the development and test teams through an Agile process in the path to our beta release and beyond. My process involved business requirement documentation, filtering down to feature development epics and stories in Jira. I supported and led discovery of testing plans and results, driving scope and priority for subsequent development iterations. I continued to manage user and stakeholder reviews, aligning expectations and keeping the focus on our users through the initial product release and beyond.

Key Results: The user driven approach to feature planning and prioritization, along with thoughtful and consensus based time and scope planning, led to better team morale, as praised by our CEO at the quarterly business review following our first production ready release. The product team reported that in one year, the new version of Conductor Live helped facilitate $17m in sales of Elemental Live (the flagship product that it managed), with key strategic customers attesting to its “great user interface” and “ease of use”.



Case Study 1: Redundancy Design for Conductor Live

Context: Uptime is critical for the encoding and delivery of live streaming video, particularly in a linear (TV channel) offering. Encoder systems, and the networks that connect them, can go down for various reasons. Customers wanted an easily configurable management system capable of automatically backing up systems, keeping video channels running with minimal downtime.

Problem: In the legacy offering, each channel had its own redundancy setting, even though an encoder system could support 1-10 channel streams. While this offered flexibility, it added a high degree of complexity and chance for error. Users wrangled spreadsheets to track redundancy settings. We needed to make redundancy easy to manage through clear configuration settings and useful system state awareness.

Process: I performed multiple context interviews, led brainstorm sessions with developers, and iterated through wireframe stories and use case stories. Using that documentation, I performed multiple stakeholder, developer, tester, and user reviews, in order to refine and develop feature requirements. I then led the team through an Agile iterative development process, finding MVP for an on target release.

Wireflows - encodes run while grouped by systems, and can recover while grouped by systems.
Wireframes – encodes run while grouped by systems, and can recover while grouped by systems.

Use case stories inform granular feature scope, development, and test planning
Use case stories inform granular feature scope, development, and test planning.

Key User Learnings: In the legacy system, users manually organized their channel redundancy planning per the encoder systems (through spreadsheets). Those systems had a physical presence, and the operators named them, and focused on the channels generated from each of them.

Solution: I led the team through the workflow design and technical implementation of a system based redundancy model, in contrast to the channel based system of the legacy product. So redundancy would be managed ‘per system’, with every channel on a system backed up as a set.

Outcomes: Besides the positive feedback we received from users on the new redundancy design, we learned that the model provided a huge improvement to the workflow for system cluster upgrades. What had taken days of awkward, high risk shuffling became a several hour process encompassing predictability, stability, and clear system status.

top of page



Case Study 2: Bulk Updates for Conductor Live

Context: With 1000’s of video channels being encoded across 100s of encoder systems, users needed the ability to make operational updates to a wide array of channels.

Problem: Through the legacy system, users reported the need to manually stop the encoding of 300 channels with 600 clicks! Any multi-channel change encompassed a lot of effort, with lots of risk for error. We needed to make large scale changes easy and manageable for users.

Process: I performed context interviews with users and service engineers, learning the pain points of manual updates at scale. Early on, I identified bulk updates as a key system need, and advocated for its top prioritization within the overall product design. I studied existing models of bulk updates from Gmail, Jira, and other large scale systems. Ultimately, I designed a bulk update workflow through wireframe documents and use case stories, with multiple iterations based on user and developer feedback.

Wireframe describing bulk task workflows
Wireframe describing bulk task workflows.

Key Challenges: A major challenge was to design a consistent bulk workflow that adequately and clearly handled divergent channel workflow needs (changing settings, starting, stopping, deleting).  

Solution: Through multiple iterations and regular user and developer feedback, I designed an experience that navigated technical constraints smoothly and efficiently for a variety of workflow needs. I identified the need for enhanced list search and sort capabilities, so that users could manage what they would be updating, incorporating those sub-features into the overall design.

Wireframe describing sort and search improvements
Wireframe describing sort and search improvements.

Outcomes: Bulk operations allowed users to manage operational tasks with clarity and confidence. The feature also supported other UX flows, including common profile management, allowing users to track configuration consistencies and differences across 1000s of channels.

top of page



Case Study 3: Common Profile Design for Conductor Live

Context: Our live video encoding software involved over 500 unique, interconnected and often interdependent settings. User observations showed us that in common practice, some settings always vary per user (input and output locations/destinations) and others occasionally vary (quality, color, sharpness, bandwidth, etc.)

Encoder configurations include over 500 unique, interconnected settings. Some settings always vary, many settings vary only occasionally per user.

Problem: For users managing 100s or even 1000s of channels on the legacy system, their process involved duplication/cloning, making a change, and saving the configuration, with no connection between channels of common origin. Changing settings globally (ex: “increase buffer size to 3mb for all channels”) was very cumbersome, and rife with error.

stack of profiles
When a common change was needed, users had to duplicate and edit each channel individually, leading to more work, more chance for error, and frustration.

Key Challenges:  The team inherited long standing, stubborn beliefs about the challenge. They knew that linking configuration details across multiple channels would allow for more efficiency. But they correctly anticipated that the power of linked configurations could lead to unintended consequences. For example, the assumption that all channels using setting X should change to setting Y would fail to identify important exceptions, leading to unintended surprises. People frustrated by multiple changes wanted fast, powerful actions. People experienced with unintended configuration surprises were skeptical that any solution could avoid risking such negative outcomes.

Process: I observed and documented current legacy workflows, testing and iterating on findings. I brainstormed with developers and stakeholders on ways to combine fixed with unfixed (variable) settings. I ideated and sketched out wireframes on various configuration processes that users would likely want to take, leveraging the Bulk Updates feature described in an earlier use case example. I reviewed wireframes and prototypes with end users familiar with the challenge, validating assumptions and improving our understanding of real world scenarios. I stayed in constant contact with developers iterating on implementation, and ensured that the outcomes supported these user scenarios.

Solution: I led the team through the development of static profiles, using a process of named and referenced variables to manage settings that should remain unfixed. I proved through wireframes documentation that changing a setting on 1000 channels didn’t have to involve manually editing 1000 channels. And although it was not safe or practical to make such a change through a ‘one click’ transaction, a middle ground of a careful 7-click bulk change process provided the flexibility and clarity needed to perform informed, careful, and easy updates for dozens or hundreds of channels.

At the profile, users defined which controls used variables.
At the profile, users defined which controls used variables.

At the encode, users specify values for controls leveraging variables.
At the encode, users specify values for controls leveraging variables.

profile example
Profiles could then be duplicated with custom edits.

Users could leverage a bulk change tool to update all encode configs to leverage the new, updated profile.
Users could leverage a bulk change tool to update all encode configs to leverage the new, updated profile.

Outcome: Our solutions engineers quickly saw the high value of this new workflow, and led adoption by hands on practice and advocacy. The feature became a core selling point for the software, and entrenched its emerging reputation for “ease of use” among customers.

top of page