Project Overview
This project was created over a 9 month period to address the changes to how the Casting Industry handles day to day business in response to COVID 19. Virtual Casting Rooms allow a Casting Director to book talent, share information about the role, directions, and virtual audition link with talent as well as collect information from talent before the audition. The day of the audition Production can host an audition 100% remotely and share all of the recordings and actor materials instantly with their production team using Casting Workbook.
My role in this project was design lead. I was also the sole designer on this project, working directly with the development team, users (Casting Directors, Agents, and Actors), and stakeholders to deliver a solution to address the changing industry under tight timelines. In addition to the design roles, I also project managed this initiative, tracking all tasks in Asana and ensuring the team stayed on track through the project Slack channel and weekly check in meetings.
This project received national media attention and was even picked up by the financial post.
This project is a continuing piece that has been broken down into phases for release. Below I will discuss Phases 1-4, with Phase 4 currently underway and expected completion in May 2021.
Tools Used
Figma, Lookback, Asana, HotJar
Table of Contents
Phase 1: Bringing the Audition Room to Virtual
Phase 2: Implementing User Feedback and Video Matching System
Phase 3: Integrating with iSAM & Actor App
Phase 4: VCR-The Next Generation
Phase 1: Bringing the Audition Room to Virtual
Overview and Timeline
Phase 1 of the project was created over a 3 week design sprint and a 6 week development sprint to get a working concept delivered for beta testing at the end of May 2020. The goals of phase 1 were to identify the user groups and user stories associated with those groups and define and design an MVP to get the industry back to work in the minimum possible time during the shutdown.
Defining Groups and Gathering User Stories
Auditions are complex and require multiple parties to complete. Each one of the parties have very specific actions that need to take place. Therefore it was important to define the user groups and identify their needs and goals. To do this I got a team together consisting of our CEO, CTO, and Head of Customer Success. We pooled the combined data and knowledge of our customer base and how these sessions are run in person to define the groups and write out user stories for each group.
Project Owners (Casting Directors, Associate Casting Directors, etc.)
These types of users have the highest level of permission and can also assume the roles of session runner, camera operator, viewer or reader at any time.
Session Runner
The Session Runner runs the remote session. Prior to virtual sessions this would be the person in charge of managing the check in process and ensuring that all paperwork is filled out and headshots and resumes are properly organized. The session runner can also assume the roles of project owner, camera operator, or viewer at any time.
Camera Operator
A camera operator tapes the session. They are in charge of handling the taping, editing the takes and ensuring the session clips get uploaded to the appropriate project in Casting Workbook. Prior to virtual sessions, Casting Workbook had Mac OS software called SAM that was used in combination with a Camera, Black Magic Device, and Macbook to handle in person sessions. The challenge with the new landscape was giving the Camera Operator all of the robust functionality and capabilities of this set up for in person sessions run virtually.
The Viewer
Viewers include members of the production team who are not running the session such as Producers, Directors, etc. The Viewer needs to be able to communicate with the other members of the production team above, view actor materials and take notes. The Viewer does not need to interact with the session.
The Reader
A reader is someone who reads lines with the Actor. The readers voice appears on camera but not their video. The reader can sometimes be a member of the production team but may also be a party that has been invited to the session externally.
The Actor
The actor is the person or persons who are auditioning for the role. Actors may audition individually or in groups for chemistry reads (when the production team wants to see the chemistry between two or more actors who are auditioning for roles in the same scene). I will touch briefly on how we have solved for actors in this case study, however for a more comprehensive and detailed breakdown of the solution for actors please refer to my case study on Virtual Auditions in the Actor App.
The MVP
Taking into consideration business needs combined with user needs and the rapidly changing industry in response to COVID 19 shutdowns the team determined that our number 1 priority was speed to market.
Problem
How can we utilize pieces of our existing software combined with existing video conferencing platforms on the market to deliver a solution to our customers in the next 60 days?
Potential Solution
Building additional functionality in Casting Workbook, Actor Workbook, Actor App, and SAM combined with building off of the Zoom SDK to deliver a solution which would talk to each other and solve for the high level needs of our users.
MVP feature requirements
For the MVP the team decided that our primary focus would be focusing on delivering on a skimmed down solution which would solve for the Project Owner, Session Runner, and Actor. Viewers and Readers can still join and participate in a session but full functionality for these groups would be introduced in Phase 4.
In order to get full Camera Operator functionality the team would need 3 months to build the functionality onto the existing Mac OS software therefore we determined to build this as part of Phase 2. This was later determined to move to Phase 3 after we gathered feedback from the initial beta testing of phase 1. For Phase 1 we decided to employ members of our CS team to assist on Virtual Audition Sessions as part of a white glove service we called "Concierge" which allowed us to use back end software to handle the camera controls while the updates were being made to the client existing software.
Session Runner/Project Owner
-Upload Video Directions to a session
-Push Schedule from Casting Workbook
-Host a remote audition
-Add Info-sheets to a session
-Add Sides/Materials to a session
-Communicate with the production team non-verbally
Session Runner
-Check in/out attendees
-Bring Attendees into/out of the room
-Communicate non verbally with the production team
-Fill out info-sheet if actor has not
-Communicate with the production team non verbally
-Communicate with Actors non-verbally
-Control Camera and Audio functionality of attendees
Actor
-Access the session from a mobile or desktop device
-Fill out the Info-sheet
-Receive notification of the upcoming session
-Access Video Directions and Sides prior to the session
Solution
Build an Audition Kiosk onto the existing Casting Workbook software to handle the needs of the Session Runner and Project Owners and utilize the Zoom SDK to host the session and record the takes to upload to the session. For Phase 1 the Actors would be notified about the session and provided the details via email or via Actor Workbook. Both of these avenues would allow the actor to access all materials and attend the session via the provided links.
Project Owner
The full flows and functionality for phase 1 can be found in this Figma File. Keep in mind that this is a copy of the original file so components are not linked from original shared team library that I built. For the purpose of this case study I will discuss creating a room from the Breakdown and adding Video Directions from the Virtual Casting Kiosk.
Creating a Virtual Session
After the Project Owner has created a breakdown (job posting), handled selecting submissions, and created a schedule for the session they can then choose to use the Virtual Casting Room to host the audition. Once they choose to do this a unique zoom link is created for the Session and sent out to all the attendees. The user is pushed into the kiosk after the session has been created.
Adding Video Directions
Direction is something that is given to a group of actors auditioning for the same role or scene. In an in person session the actor(s) would be brought into a room and be given the direction prior to the audition (how the scene is set up, how the characters interact with each other, etc). The new system allows the user to upload pre-recorded direction(s) and attach them to corresponding role(s). The directions are then distributed to the actors auditioning for those roles so they have the chance to review prior to their session.
Session Runner
Full functionality for phase 1 for the Session runner can be found in this Figma File. For the purposes of this case study I will focus on running the Session.
Running a Session
To run the virtual audition session the Session Runner would click on the Session in the Kiosk. This would open the session details page. From there the user would click on the virtual session link. Phase 1 requires that the session runner use the kiosk and zoom in split screen, checking users in(which happens as soon as they get into the waiting room for union purposes) and out, as well as letting them in and out of the zoom room from the waiting room. The session runner also reviews their info-sheet to ensure that it is complete and that their lighting, sound and framing are correct before the camera operator begins recording.
Actor
Full functionality and process for the actor will be addressed in the Actor App: Virtual Auditions Case Study. For the purposes of phase 1 we determined to notify the actor of the audition and provide them with links to their info-sheet and all materials via email. For the purposes of this case study I will examine how a brand new actor is handled (doesn't currently exist in the Casting Workbook system).
Virtual Audition email: new actor
Sometimes Casting Directors will add an actor to a schedule who does not currently exist in our system if they have a relationship with the Actor or their Agent outside of Casting Workbook. If the actor does not currently exist in our system they will be given a free limited account. The actor will receive the email and as part of the email they will be invited to complete their profile. The actor can attend the audition an access the materials without completing their profile, however completing it gives us the ability to get them into the funnel and start up-selling them on additional Casting Workbook functionality.
User Testing
Prior to launching Phase 1 of the project we went through 2 weeks of internal user testing with our CS team, addressing bugs and flow issues prior to moving into Beta Testing. We then launched phase 1 into beta, conducting a month of beta testing and gathering feedback for iterations in phase 2.
Early learnings
One of the early major problems that we ran into was limitations with the zoom cloud recording on large scale sessions. Zoom will stop uploading to the cloud at 80 recordings. One large session can hold upwards of 500+ recordings. This was missed in the user testing and was not discovered until we ran our first large scale session and beta and lost upwards of 200 recordings that took the zoom team over a week to recover. We therefore had to quickly pivot and find a short term solution for handling these recordings for larger sessions which I will discuss in phase 2 while we worked on building out the long term solution that was not zoom dependant (phase 4).
Other learnings were related to minor functionality and UI fixes which included the ability to confirm your schedule prior to sending out the virtual audition link, the ability to resend links and the ability to send links to specific individuals. Along with this a new feature was requested-the ability to send the actors portfolios to members of your productions team outside of Casting Workbook which was also addressed in phase 2.
Phase 2: Implementing User Feedback and Video Matching System
Video Matching System
As discussed in the early learnings section above one of the major issues we encountered was the Zoom cloud recording limitations. I had worked with our Head of Development to come up with an initial solution for phase 1 which used the Zoom SDK to automatically match the recordings based of the schedule in Casting Workbook and upload them to our system for storing and review on the Project that the Session was related to. We quickly discovered that this solution was not going to work for larger sessions.
After some investigation and talking with the CS and development teams we determined that the best path forward for the short term would be to use a "Concierge" provided for the white glove Camera Operating service to start/stop recording on these sessions and store them locally to be uploaded after the session was completed. We were able to create a naming convention using the SDK for the locally stored recordings but needed to build a video matching system for the Concierge team which would allow them to bulk upload the recordings, have them matched with the actors in the room at that time, and confirm those matches. This could be used by a tech savvy Session Runner but was primarily built for our internal team only.
Implementing User Feedback
After our initial round of beta testing several new feature requests and updates were requested to make the kiosk more user friendly and intuitive to use. These included:
-Ability to add an actor to a session from the Audition Kiosk instead of having to go to schedule and then sync
-Ability to change the order in which actors appear directly from the Audition Kiosk
-Ability to resend the audition link
-Ability to send a link to individuals not on schedule
-Ability to confirm the schedule prior to sending out the Virtual Audition link
-Minor UX/UI updates
For the purposes of this case study I will review the process for adding an actor to a session. If you wish to review the additional functionality please reach out to me and I am happy to walk you through the figma files and dev handoff docs.
Adding an Actor to a Session
The current process for adding an actor to a session was to go to the schedule and add them to the schedule, then confirm them to the schedule, then come back to the session in the Kiosk. All together this was about a 6 step process and not very user friendly. Users needed a way to easily add an actor to the session ad hoc and have it sync back to the schedule, along with the option to choose whether or not to send the updates out to the attendee(s).
My original thoughts with sending out the updates were that it would be an automatic send, however after running this by Casting Directors it was determined that they would like to have control over this. So after changes are made to the schedule a warning will appear asking the user if they want to send updates. If they attempt to navigate away from this page without sending updates the user would again be prompted with a pop-up modal warning them before leaving the page.
Phase 3: Integrating with iSAM & Actor App
Bringing Virtual Casting Room functionality to iSAM
iSAM is Casting Workbooks Mac OS software used for Camera Operators to record sessions, encode and edit video, and sync final files to the Casting Workbook Software. iSAM has a bi-directional sync set up with Casting Workbook, therefore changes made to the session such as adding an actor or changing the times around are automatically synced to the project in iSAM.
As I had mentioned previously because we were unable to get the Virtual Casting Room functionality into this software for phase 1 we set up a service which would have our CS team assigned to sessions, handling all of the Camera Operating functionality until we could bring the Virtual Room into this software.
Phase 3 included adding the following features to iSAM:
-Integration with the Zoom SDK to bring in the Camera Feed
-Adding sections on the actor side panel for actor states (in the room, in the waiting room, not signed in)
-Ability to bring participants into and out of the room
-Ability to chat with participants in the room.
This functionality was broken down into 3 smaller development sprints.
This software was created in 2012 and has not seen any updates since that time. Because we are moving away from the Mac OS software to a completely web-based solution in phase 4 we decided not to make any UI updates to this software other then the updates for MVP functionality to get the Camera Operating software usable for remote sessions.
Component updates
Along with the files I also provided a set of the updated components with the different states as these were customized components outside of the out of the box Mac OS component library. When possible, I tried to stick as close as possible to components and behaviours in the Mac OS library to cut down on development time
Integrating Virtual Casting Room with Actor App
In order to make the process more user friendly for our actors we built all of the functionality of Virtual Casting Rooms right within our IOS and Android App. This gave the actor the ability to receive their audition information, view video directions, fill out their info-sheet, conduct a tech pre-check and attend their virtual audition right from within the app. The process for implementing these features into the Actor App and user testing and iterations can be seen in detail in the Actor App: Virtual Auditions case study.
Phase 4: Virtual Auditions-The Next Generation
Overview
In Phase 4 we take all of the desired functionality described in the user stories in phase 1 into one cloud-based software. The next generation of Virtual Casting Software eliminates the need for the video matching software described in phase 2. All of the Video recording and matching is done automatically and instantly. In this phase we are moving away from Zoom and using Agora for our back end video conferencing platform and Amazon AWS for cloud recording storage.
The Dashboard for the new system is user based. So different users will have access to different features dependant on their needs and permissions. Above is the view for the Project Owner and Session Runner. Both Project Owners and Session Runners have the highest level of permissions as they can also take on the role of Camera Operator for smaller sessions.
Sketching out Solutions
Prior to moving into high fidelity designs I began to sketch out the solutions. For the beginning of Phase 4 of this project we as a team decided that the development team would focus on building out the dashboard components and the flows for chat functionality and accessing materials.
Dashboards
The Dashboards have 4 distinct views dependant on the user type:
-View 1: Project Owner & Session Runner
-View 2: Camera Operator
-View 3: Viewer and Reader
-View 4: Actor
As discussed in the User Stories in Phase 1, each one of these user groups has a specific set of actions they need to take when conducting an audition, therefore for Phase 4 we handle their specific needs be creating a tailored experience for the different user types.
Views 3 & 4 are currently in design. I will be updating this case study once these views are available.
View 1: Project Owner & Session Runner
I decided to combine these views for v1 as the Project Owner can become a Session Runner and vice versa. Both of these user groups have the highest level of permissions and may need to take on the roles of Camera Operator or Reader at anytime. Therefore these user groups are in need to the most robust functionality.
This user group needs to:
-Run a session and control who is in the room
-See the statuses of actors who are "on deck" (ready, not ready, preparing)
-Communicate with actors or production team members
-Access Actor Materials
-Have access to all Camera Operator Controls incase they need to assume this role (smaller sessions only)
-Control sound/video of all participants
-Have the ability to re-assign roles to production team members (viewer, camera operator, reader, session runner, casting director)
View 2: Camera Operator
The Camera Operator's primary focus is having access to the controls which enable them to record the session, mark takes, and upload, encode, and edit them. A Camera Operator also needs to be able to bring people into and out of the room and chat with production team members only. The Camera Operator does not need access to actor materials. Camera operators also do not need to "check" actors in or out as this is not related to the recording, this is a timestamp functionality for union purposes. Therefore the checkin/checkout functionality has been replaced with Dismiss (which removes the actor from the session).
Components
This project is currently in design. At the present the primary focus is getting the dashboard and components outlined and built out. For the purposes of this case study I will be outlining a few of the components and states for the panels and actor and production team cards on the Project Manager/Session runner view
Panels
There is a panel on both the left and right side of the audition viewport. The left side panel is always open. The user can access everyone who is in the room and on deck as well as the controls associated with each card. The right side panel is collapsed by default. Expanded the user can access session materials and chat functionality.
Actor cards
Actor cards have 3 main states: In the Room, Ready, Preparing, and Unavailable. Each state has slightly different functionality and options available.
Production Team Cards
The production team cards give the user the access to see the production team members who are in the room and their assigned roles. The user also has the ability to re-assign roles, control audio/video and access additional menu items.
Next steps
The Dashboard layout has been run by several Casting Directors and internal team members with minor changes applied based on feedback. I am continuing to build out the components and flows with user testing sessions for the chat and materials functionality scheduled early in the new year.
