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.
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.
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.
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.
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.
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.
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.
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.)
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.
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.
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.