ProLog
Staffing software for Hollywood writers
“Hollywood can be a weird space where much time is lost in finding writers to staff shows. We want to bridge that gap and help solve the problem of time wasted finding talent.”
Quote from CEO - John Stahl
Duration :
1 month
Project Description :
Group internship project through springboard with 2 other students. As a team, we performed an incremental iterative agile cycle on a new feature for a SAAS product about to release.
Tools :
Figma, Miro, Slack, Google drive
Methodologies :
Interviews, Empathy maps, Affinity mapping, Personas
Our Team
My Role :
Researcher, site mapping,
user flows, lo-fi mockups
Jongs Role :
Team leader, manager, researcher, writer
Crystals Role :
Researcher, writer, lo-fi mockups, interaction design
Introduction :
ProLog is a new staffing software for professional creatives in the Hollywood entertainment industry. ProLog allows for agencies, production studios, and showrunners to help list and find talent for shows and movies. ProLog Version 1 has already been released and we worked on a feature called “team builder” for the second version set to release Q3 of 2024.
Problem :
Writers, Agencies, Studios, and Show runners are wasting time narrowing down candidates for team writing roles on shows. The final phase of selecting the actual candidates who will write a show is tedious and software is needed to identify the best candidates for teams when writing a television show or movie.
Solution :
Create a feature that will allow users to create multiple teams for a show. This feature will save time for people in the entertainment industry in selecting candidates for assignments. Create the ability for the user to filter candidates from a list of writers and make up to 3 different teams based on their preferences for a specific show.
I/ RESEARCH
Secondary Research
A large amount of research had already been done by the Prolog team in the form of recorded video interviews, schemas, and high fidelity designs for ProLog version 1. Our team used this research to gain a greater understanding of how we would address the new feature to be worked on: Team builder.
Green - Identified as important for solution Red - identified as not needed for solution/deliverable“Because ProLog V1 is set to launch, it already has a Hi Fidelity mock-up and a design system in place — only low fidelity mockups for the new “Team Builder” feature are needed as a deliverable.” - client
Insights from video interviews
We watched over a dozen interviews with show runners in the Hollywood industry. Our team helped define the problem space from the research that was presented by the stakeholder.
Initial client meetings
In our initial meetings, the client explained to us how Hollywood works. Hollywood is a weird and complex world and understanding the intricacies of how writers get hired and put onto teams for shows proved difficult. By sifting through the primary and secondary research, I came to understand how the process for selecting writers to staff for a show is made.
Infographic I created for how Hollywood writers are selected for shows
What was being asked of our team?
In our initial meetings our stakeholder/client asked us to do research and come up with Lo-Fi designs for the new feature “Team Builder” for ProLog V2. Our client mentioned that the “team builder” feature for ProLog V2 would be designed with the showrunner as the main user.
What is a showrunner?
Showrunner is described as “the person responsible for all creative aspects of the show and responsible only to the network (and the production company if it's not “their” production company). They are the boss. Usually a writer.
II/ IDEATION
Potential Solutions
Asking the right question and adding to the UX project - we were able to make the project evolve and make the stakeholder ask bigger questions about their own project.
Speed bumps along the way
Our understanding of the complexities of how writers get hired for writing a show needed some work. Also, the client was having difficulty explaining this process. We had agreed to do some sketching as a team, but without a firm understanding of the process for team builder I had trouble focusing on what the low fidelity product might look like just yet.
Below, you can see that I am more interested in information architecture and not creating a user interface. The client had informed us that low fidelity was the only deliverable needed.
Missing site map
Although there was a lot research already for ProLog V1, our team was having trouble understanding how the SAS product would function. I searched for a sitemap in the research provided but there was not one in place.
“Because ProLog V1 is so simple, we did not need a site map” - client
Without a proper sitemap for ProLog Version 1, it was difficult to imagine how the product functioned from an information architecture standpoint. I had a special meeting one-on-one with the client where I explained the value of creating a site map for team builder.
I created this site map to allow the team to deepen the understanding needed surrounding goals for creating the team builder feature and document the information hierarchy missing from ProLog version 1.
Creating user flows with my team
I helped my team better understand what the process would be for someone using the new team builder feature for the first time by making these flows. The user flows made in miro helped us understand the most logical ways this new feature could operate.
What I learned from creating initial site map and user flows
Through careful evaluation of quantitative and qualitative data that was presented, I realized that there was some miscommunication and understanding between my team and the client. This was evident in our review of the user flows with the client during our weekly meetings.
Why was there a miscommunication?
3 weeks into the project, my knowledge of how ProLog V1 was to interact with the new Team Builder feature did not make sense. Our team was focusing on screens and filters that seemed arbitrary without a more firm understanding of Hollywood. Because there was not an initial site map for ProLog Version 1, I had to take a close look at the original flows and screens created in ProLog Version 1.
“We knew the gist of team builder but we did not know the nitty gritty of what makes it operate.”
- my quote from internal group reflection document.
Helping my team and client understand what needed to be done
We needed to come to terms with how ProLog Version 1’s information hierarchy was operating. I explained ProLog Version 1 as an advanced phone book for Hollywood talent. Agencies and writers can create a profile that includes samples of their work. Production studios and Showrunners can then look through the phone book and make selections for candidates when staffing for future shows.
What I came to understand is that team builder is for shows that are yet to be written and will be created in the future.
Insight
ProLog version 1 was designed to document what was created in the past.
Seen here is a screen from ProLog version 1 where the user enters in information about shows already created.
Using Agile - an agile approach
I wanted to help my team the best way I could with the week of time we had left to work on the project. We needed to correct some of the miscommunication with our own team and the client in regards to what was to be done. I studied the agile practice guide and determined the best solution was to omit screens that were not necessary at this point. These screens focused on entering in filter criteria for future show creation.
Correcting incongruences of ProLog version 1 & 2
In our last meeting, I forced a deeper discussion surrounding how ProLog version 2 works and how the next iteration of the product would incorporate our “Team Builder” Feature. I wanted to know if all the new filters for the team builder “future show creation” page user flow would be needed to create in our Lo-Fi mockups.
Quotes from meeting with client February 5, 2024 - Discussing user flows for ProLog Version 2
Me to client
“How do we get from point A to point B here - in word terms ? So step one - when the user arrives on the page (team builder page) does it say “create a team” or “select a show ?”
Client to me
“you know what - yeah that's where we are at right now, were deciding, were deciding how this operates”
“You do not have to worry about creating Lo-Fi Mockups for show creation - we will”
III/ DESIGN
Sketching & Wireframing
Our team kept the ball rolling on wireframes and I helped by creating new versions in figma that incorporated autolayout. Our team ensured that we did produce the deliverable : a lo-fi design of the new feature team builder.
Seen here is the intro screen for the team builder feature. Notice that it has a CTA button titled “select show”. This might have said “create new team” instead if we had not focused on hierarchy there would have been more screens after which would have been about show creation for the future. This was not needed as we had influenced the the missing site map for the larger ProLog version 1 product.
IV/ DELIVERABLES
What did we end up delivering?
This project addressed difficulties of efficiently staffing a team of writers. While various aspects might make this industry difficult to navigate, the steps a showrunner takes on their way to creating a show, doesn’t have to be. As such, after taking into account their needs and frustrations, it was clear that what users wanted was a way to actively organize and visualize their prospective writers room, in order to seamlessly build their ideal writing team. Our team addressed the most logical processes for user flows and these were then reflected in our final lo-fi mockups that we delivered to the client. Our team also forced larger discussions with our client about what the personas were and how this feature would force changes on screens and user flows for the original version 1 of ProLog.
Hand off for deliverables
What was the lesson learned during the project? We had both a limitation on time and the importance of having a good and clear brief from the start. The learning curve - this is almost as much the responsibility of the ux team as the client. Identify issues in the brief earlier on in the project. Our team completed a small portion of the iterative agile cycle for software development, it was a pleasure to explore the challenges in user experience design as part of this industry design project.