re:Inventing MSAM
Corrivium is an Australian company that specialises in video production and live streaming event technology. One of their core tools is the AWS Media Services Application Mapper (MSAM), which they use to monitor program workflows during live events.
Summary
Corrivium had been hired to handle streaming for Amazon's AWS re:Invent conference in Las Vegas. They saw this as the perfect opportunity to strengthen their relationship with Amazon, but felt that MSAM's current design didn't best represent their capabilities.
They asked Hidden Innovation to redesign it to be both practical for their broadcast team at the event and impressive enough for potential new clients.
My role
Over three months, I worked with a cross-functional team of three front-end engineers, one back-end engineer, one project manager, and one product owner (who had final design approval). With guidance from the company design lead, I independently executed all research, UI design, prototyping, and pre-release testing for the conference launch.
My role
Over three months, I worked with a cross-functional team of three front-end engineers, one back-end engineer, one project manager, and one product owner (who had final design approval). With guidance from the company design lead, I independently executed all research, UI design, prototyping, and pre-release testing for the conference launch.
My role
Over three months, I worked with a cross-functional team of three front-end engineers, one back-end engineer, one project manager, and one product owner (who had final design approval). With guidance from the company design lead, I independently executed all research, UI design, prototyping, and pre-release testing for the conference launch.
Results
I redesigned MSAM as a dashboard with only the most critical information necessary for workflow monitoring, and for Corrivium to attract new customers. The dashboard was on display during the AWS re:Invent conference.
Results
I redesigned MSAM as a dashboard with only the most critical information necessary for workflow monitoring, and for Corrivium to attract new customers. The dashboard was on display during the AWS re:Invent conference.
Results
I redesigned MSAM as a dashboard with only the most critical information necessary for workflow monitoring, and for Corrivium to attract new customers. The dashboard was on display during the AWS re:Invent conference.
A need for real-time monitoring
Recent advances in broadband and TV technology have raised consumer expectations for live streaming quality— expectations that only grew during the pandemic as more events moved online. Professional live stream providers now need robust infrastructure that lets them monitor and adjust streams in real-time to maintain viewing quality.
That's where MSAM comes in. This open-source tool allows users to configure Amazon AWS video production resources as 'program workflows' and monitor all the connections within their infrastructure. The MSAM interface provides a complete visualisation of these connections along with a customisable console for warnings, alerts, and messages. However, as you'll soon see, these complex workflows generate numerous messages that may or may not require immediate attention.
The explanation of MSAM above is a bit of an oversimplification, but is at the core of the project and our end goal: to condense a large amount of data into a single dashboard.
A need for real-time monitoring
Recent advances in broadband and TV technology have raised consumer expectations for live streaming quality— expectations that only grew during the pandemic as more events moved online. Professional live stream providers now need robust infrastructure that lets them monitor and adjust streams in real-time to maintain viewing quality.
That's where MSAM comes in. This open-source tool allows users to configure Amazon AWS video production resources as 'program workflows' and monitor all the connections within their infrastructure. The MSAM interface provides a complete visualisation of these connections along with a customisable console for warnings, alerts, and messages. However, as you'll soon see, these complex workflows generate numerous messages that may or may not require immediate attention.
The explanation of MSAM above is a bit of an oversimplification, but is at the core of the project and our end goal: to condense a large amount of data into a single dashboard.
A need for real-time monitoring
Recent advances in broadband and TV technology have raised consumer expectations for live streaming quality— expectations that only grew during the pandemic as more events moved online. Professional live stream providers now need robust infrastructure that lets them monitor and adjust streams in real-time to maintain viewing quality.
That's where MSAM comes in. This open-source tool allows users to configure Amazon AWS video production resources as 'program workflows' and monitor all the connections within their infrastructure. The MSAM interface provides a complete visualisation of these connections along with a customisable console for warnings, alerts, and messages. However, as you'll soon see, these complex workflows generate numerous messages that may or may not require immediate attention.
The explanation of MSAM above is a bit of an oversimplification, but is at the core of the project and our end goal: to condense a large amount of data into a single dashboard.
Below. MSAM's Diagram and Tile views. (Source)
Working with limited resources
Our client needed the dashboard displayed on TV screens for impressing conference attendees while technicians used it on laptops to configure and monitor up to three live events. However, we faced significant constraints that shaped our approach.
With only six weeks until the conference and everyone busy with event prep, we had access to just one broadcast technician—fortunately, the same person who'd be using the tool at the event. We also lacked resources to contact other technicians or potential conference attendees.
Given the time crunch, we made a crucial early decision: MSAM has two different views, including a complex flow chart that would require significant development effort. We chose to build on the simpler tile view instead, knowing I'd need to work closely with our technician to identify which components were essential for his workflow, what would impress potential clients, and what could be eliminated from the build.
Working with limited resources
Our client needed the dashboard displayed on TV screens for impressing conference attendees while technicians used it on laptops to configure and monitor up to three live events. However, we faced significant constraints that shaped our approach.
With only six weeks until the conference and everyone busy with event prep, we had access to just one broadcast technician—fortunately, the same person who'd be using the tool at the event. We also lacked resources to contact other technicians or potential conference attendees.
Given the time crunch, we made a crucial early decision: MSAM has two different views, including a complex flow chart that would require significant development effort. We chose to build on the simpler tile view instead, knowing I'd need to work closely with our technician to identify which components were essential for his workflow, what would impress potential clients, and what could be eliminated from the build.
Working with limited resources
Our client needed the dashboard displayed on TV screens for impressing conference attendees while technicians used it on laptops to configure and monitor up to three live events. However, we faced significant constraints that shaped our approach.
With only six weeks until the conference and everyone busy with event prep, we had access to just one broadcast technician—fortunately, the same person who'd be using the tool at the event. We also lacked resources to contact other technicians or potential conference attendees.
Given the time crunch, we made a crucial early decision: MSAM has two different views, including a complex flow chart that would require significant development effort. We chose to build on the simpler tile view instead, knowing I'd need to work closely with our technician to identify which components were essential for his workflow, what would impress potential clients, and what could be eliminated from the build.
Determining what stays and goes
Our broadcast technician provided crucial insights into MSAM's current usage and pain points:
Data overload: Online production services generate hundreds of warning messages every few seconds unless manually filtered
Workaround behaviour: Technicians use a second screen for CloudWatch data because it's less complicated than MSAM's filtering
Unclear visual hierarchy: MSAM's program tiles don't clearly indicate that they represent multiple channels
Given our tight timeline, I skipped creating personas and instead used these insights to map out the technician's expected user journey. After sharing this with the team, we moved into information architecture planning.
Our broadcast technician provided crucial insights into MSAM's current usage and pain points:
Data overload: Online production services generate hundreds of warning messages every few seconds unless manually filtered
Workaround behaviour: Technicians use a second screen for CloudWatch data because it's less complicated than MSAM's filtering
Unclear visual hierarchy: MSAM's program tiles don't clearly indicate that they represent multiple channels
Given our tight timeline, I skipped creating personas and instead used these insights to map out the technician's expected user journey. After sharing this with the team, we moved into information architecture planning.
Our broadcast technician provided crucial insights into MSAM's current usage and pain points:
Data overload: Online production services generate hundreds of warning messages every few seconds unless manually filtered
Workaround behaviour: Technicians use a second screen for CloudWatch data because it's less complicated than MSAM's filtering
Unclear visual hierarchy: MSAM's program tiles don't clearly indicate that they represent multiple channels
Given our tight timeline, I skipped creating personas and instead used these insights to map out the technician's expected user journey. After sharing this with the team, we moved into information architecture planning.
Only the essentials
Given the high stakes with a major stakeholder at a major event, we couldn't risk straying too far from MSAM's current implementation. I kept familiar elements from the existing project configuration tiles: project status (online, offline, error), number of connected cloud services, and number of open alerts and alarms.
Based on my discussion with the technician, I identified three key additions that would improve functionality:
Primary and secondary channel status would eliminate the need to open the Diagram view when alerts occurred.
CloudWatch status events would be displayed directly in the dashboard, removing the need to switch between programs.
A 'recent activity' feed would show only critical alerts and alarms, preventing important errors from being buried under routine service warnings.
For simplicity, and because potential customers might be viewing the dashboard on a TV screen during the conference, all other elements in the current UI would be removed.
Only the essentials
Given the high stakes with a major stakeholder at a major event, we couldn't risk straying too far from MSAM's current implementation. I kept familiar elements from the existing project configuration tiles: project status (online, offline, error), number of connected cloud services, and number of open alerts and alarms.
Based on my discussion with the technician, I identified three key additions that would improve functionality:
Primary and secondary channel status would eliminate the need to open the Diagram view when alerts occurred.
CloudWatch status events would be displayed directly in the dashboard, removing the need to switch between programs.
A 'recent activity' feed would show only critical alerts and alarms, preventing important errors from being buried under routine service warnings.
For simplicity, and because potential customers might be viewing the dashboard on a TV screen during the conference, all other elements in the current UI would be removed.
Only the essentials
Given the high stakes with a major stakeholder at a major event, we couldn't risk straying too far from MSAM's current implementation. I kept familiar elements from the existing project configuration tiles: project status (online, offline, error), number of connected cloud services, and number of open alerts and alarms.
Based on my discussion with the technician, I identified three key additions that would improve functionality:
Primary and secondary channel status would eliminate the need to open the Diagram view when alerts occurred.
CloudWatch status events would be displayed directly in the dashboard, removing the need to switch between programs.
A 'recent activity' feed would show only critical alerts and alarms, preventing important errors from being buried under routine service warnings.
For simplicity, and because potential customers might be viewing the dashboard on a TV screen during the conference, all other elements in the current UI would be removed.
Prioritising program status
The main priority was clarity—any user should immediately understand each program's status and whether action was needed. I sketched layouts with the Activity Feed and CloudWatch list in different positions but kept both at the bottom to avoid distracting from the tiles, maintaining the familiar positioning technicians expected.
I also replaced the CloudWatch event list with a line graph to provide a visual timeline of program status changes, making it easier for users to track patterns over time.
Prioritising program status
The main priority was clarity—any user should immediately understand each program's status and whether action was needed. I sketched layouts with the Activity Feed and CloudWatch list in different positions but kept both at the bottom to avoid distracting from the tiles, maintaining the familiar positioning technicians expected.
I also replaced the CloudWatch event list with a line graph to provide a visual timeline of program status changes, making it easier for users to track patterns over time.
Prioritising program status
The main priority was clarity—any user should immediately understand each program's status and whether action was needed. I sketched layouts with the Activity Feed and CloudWatch list in different positions but kept both at the bottom to avoid distracting from the tiles, maintaining the familiar positioning technicians expected.
I also replaced the CloudWatch event list with a line graph to provide a visual timeline of program status changes, making it easier for users to track patterns over time.
Feedback & adjustments
I tested my wireframes with the broadcast technician to ensure I was displaying the right amount of information for live event monitoring during the conference.
Based on observations and feedback, I made several key updates: removed alert/alarm descriptions from the Activity Feed (error codes and service names were sufficient), emphasised alerts/alarms over less critical channel thumbnails, and incorporated the CloudWatch graphs into each program tile after realising a single graph for all programs would become crowded.
Feedback & adjustments
I tested my wireframes with the broadcast technician to ensure I was displaying the right amount of information for live event monitoring during the conference.
Based on observations and feedback, I made several key updates: removed alert/alarm descriptions from the Activity Feed (error codes and service names were sufficient), emphasised alerts/alarms over less critical channel thumbnails, and incorporated the CloudWatch graphs into each program tile after realising a single graph for all programs would become crowded.
Feedback & adjustments
I tested my wireframes with the broadcast technician to ensure I was displaying the right amount of information for live event monitoring during the conference.
Based on observations and feedback, I made several key updates: removed alert/alarm descriptions from the Activity Feed (error codes and service names were sufficient), emphasised alerts/alarms over less critical channel thumbnails, and incorporated the CloudWatch graphs into each program tile after realising a single graph for all programs would become crowded.
And then there were... six
After updating the client on our progress, we learned the dashboard needed to display six program configurations, not three. This required smaller tiles, but the activity feed and graphs remained essential. I compromised by using smaller graphs and adding a 'status' indicator showing only the most recent alert or alarm per tile.
While this meant more information per tile, it was a necessary trade-off for efficiency and to get developers started while I continued iterating on the design.
And then there were... six
After updating the client on our progress, we learned the dashboard needed to display six program configurations, not three. This required smaller tiles, but the activity feed and graphs remained essential. I compromised by using smaller graphs and adding a 'status' indicator showing only the most recent alert or alarm per tile.
While this meant more information per tile, it was a necessary trade-off for efficiency and to get developers started while I continued iterating on the design.
And then there were... six
After updating the client on our progress, we learned the dashboard needed to display six program configurations, not three. This required smaller tiles, but the activity feed and graphs remained essential. I compromised by using smaller graphs and adding a 'status' indicator showing only the most recent alert or alarm per tile.
While this meant more information per tile, it was a necessary trade-off for efficiency and to get developers started while I continued iterating on the design.
Hi-fidelity designs
After making the necessary changes to the tiles, I moved on to high-fidelity design and began preparing for developer handoff. To save time, I repurposed an existing UI kit that the company had used for Corrivium's other products, ensuring consistency across their ecosystem while reducing development time.
Based on the client's brand colour palette, I went with a dark theme with blues and greens based on the client’s brand palette, choosing colours that conveyed the reliability and professionalism they wanted the dashboard to embody.
I initially explored using the re:Invent colour palette to maintain visual cohesion with the event branding. However, usability testing revealed that the conference's pink and orange backgrounds created poor contrast ratios with our red alert indicators, making critical warning states difficult to distinguish.
Throughout this phase, I documented design specs and component guidelines while working closely with the engineering team to ensure smooth implementation and maintain design integrity.
Hi-fidelity designs
After making the necessary changes to the tiles, I moved on to high-fidelity design and began preparing for developer handoff. To save time, I repurposed an existing UI kit that the company had used for Corrivium's other products, ensuring consistency across their ecosystem while reducing development time.
Based on the client's brand colour palette, I went with a dark theme with blues and greens based on the client’s brand palette, choosing colours that conveyed the reliability and professionalism they wanted the dashboard to embody.
I initially explored using the re:Invent colour palette to maintain visual cohesion with the event branding. However, usability testing revealed that the conference's pink and orange backgrounds created poor contrast ratios with our red alert indicators, making critical warning states difficult to distinguish.
Throughout this phase, I documented design specs and component guidelines while working closely with the engineering team to ensure smooth implementation and maintain design integrity.
Hi-fidelity designs
After making the necessary changes to the tiles, I moved on to high-fidelity design and began preparing for developer handoff. To save time, I repurposed an existing UI kit that the company had used for Corrivium's other products, ensuring consistency across their ecosystem while reducing development time.
Based on the client's brand colour palette, I went with a dark theme with blues and greens based on the client’s brand palette, choosing colours that conveyed the reliability and professionalism they wanted the dashboard to embody.
I initially explored using the re:Invent colour palette to maintain visual cohesion with the event branding. However, usability testing revealed that the conference's pink and orange backgrounds created poor contrast ratios with our red alert indicators, making critical warning states difficult to distinguish.
Throughout this phase, I documented design specs and component guidelines while working closely with the engineering team to ensure smooth implementation and maintain design integrity.
Outcomes
The conference was a success. Corrivium received positive feedback from attendees and, notably, from MSAM's creator. They're now in discussions about extending the redesign to incorporate additional data streams for other companies and potentially integrating the Diagram view nodes.
Outcomes
The conference was a success. Corrivium received positive feedback from attendees and, notably, from MSAM's creator. They're now in discussions about extending the redesign to incorporate additional data streams for other companies and potentially integrating the Diagram view nodes.
Outcomes
The conference was a success. Corrivium received positive feedback from attendees and, notably, from MSAM's creator. They're now in discussions about extending the redesign to incorporate additional data streams for other companies and potentially integrating the Diagram view nodes.
Key takeaway: Making the most of what you’ve got
This project was a great reminder that good design thrives within real-world constraints. Would I have loved endless user interviews and a massive research budget? Absolutely. But I learned you can still make smart design decisions by being strategic with the data you have.
The trick is backing every choice with actual user insights (even if they're limited) rather than just winging it. As it turns out, tight constraints often spark more creativity and focus than having all the resources in the world.