Sinclair Broadcast Group - Storyline
Description: StoryLine is Sinclair Broadcast Group’s internal content management system that launched in 2015. The product was initially created to support the news teams but has since expanded to support the over-the-top (OTT) product teams as well. Currently, Storyline supports 190 local news stations nationwide as well as the OTT teams. The user base consists of approximately 4,000 daily users who publish over 3,000 stories a day.
In 2020, 284 million articles were viewed and 12 million screens were used by 5.7 million users.
My Role: I served as the only dedicated UX/UI designer for the Storyline team. I designed all new product requests as well as revised and updated old product features.
The Team: 1 Product Manager, 1 Scrum Master, 1 UX Designers, 10 Developers
My Responsibilities: I worked on scoping projects, creating user flows and wireframes, and designing rapid prototypes for product showcasing and user testing.
Tools: Sketch, Invision
Basics
Company Overview
Sinclair Broadcast Group is a diversified media company and one of the leading providers of local sports and news. Sinclair owns 23 RSN brands and 190 television stations. Sinclair also has affiliations with all the major networks. Sinclair delivers content via multiple platforms including: over-the-air, video program distribution, and digital platforms.
Sinclair Digital is a division within Sinclair Broadcast Group. The Digital team creates the applications that house and deliver all of the parent company’s media—media that’s trafficked through a multicast network serving television, web, mobile and over-the-top applications. The team also provides advertisers and businesses efficient means and value to connect with a mass audience.
The Process
The Storyline team works in 2-week sprint cycles. Each sprint, I tackled new design projects that would be implemented by the engineering team in subsequent sprints. My completed wires were reviewed and approved by the product owners before they were submitted to the engineering team. I worked closely with all team members to ensure that my designs were feasible.
Research
User Research
Storyline has a diverse set of users - there are approximately 4,000 daily users who publish over 3,000 stories each day. Users include producers, news directors, sales managers, and account executives. Depending on the design task, the work may impact all users or only a select group.
Primarily, my work revolved around two groups of users: news producers and OTT platform producers.
News producers use StoryLine to publish and manage stories. This includes:
Writing copy and attaching video/image assets to a story
Targeting the stations that will be able to view the content
Sinclair OTT platforms includes STIRR and Tennis Channel. The OTT platform producers publish and manage shows within StoryLine. Their work includes:
Managing the electronic program guide (EPG) to schedule programs throughout the week
Finding gaps between showtimes to fill
I regularly interviewed and shadowed both groups of users to understand their workflows and pain points. Once wires were completed, I did user testing with the affected groups to ensure that the designs met their needs.
Design
Wireframes & Prototyping
For each design project, I sketched out a user flow which helped me to see the entire process and remedy any potential pain points. Once the user flow was complete, I used Sketch app and Invision to wireframe and build out prototypes rapidly. My wireframe process focused on each user flow and each screen identified in the user flow. As I worked, I made sure to check in with the project managers and engineering teams regularly to ensure that designs were feasible and met our rigorous timeframes. Often times, I provided a couple solutions that allowed the team to pick and choose components that not only accomplished the user’s goals but also fit our engineering schedule.
Below, I’ve outlined a small sample of design projects that I worked on with the Storyline team. Each project was completed within two weeks unless otherwise noted.
Design Projects
Project 1: Style Guide
Storyline has an interesting history. The design has been largely managed by the engineering team and so it has many unique nuances. Before I could hit the ground running, I wanted to establish the product’s design. The team had never created a design system or style guide so each new feature had a unique look. Although most components were used in multiple places, they were not used consistently. I went through each feature in Storyline to document the components, colors and icons that were used. I then created a style guide that helped inform the design moving forward.
Throughout my time on this project, I tried to standardize the design as much as possible. If I noticed that a button was used incorrectly or multiple icons were used to convey the same thing, I worked with a developer who could quickly address the error.
Storyline’s primary color is red. This can be confusing for a user since red is primarily used to indicate an error or alert. In the future, I hope to introduce a new color scheme that is more user-friendly.
Project 2: Teaser Dayparting
Storyline was initially created to support the news teams but has since expanded to support the OTT product teams as well. Although both teams have similar goals, they also use the system quite differently. News changes quickly so news producers need a quick platform that allows them to update content regularly. In contrast, the OTT teams can typically plan their content in advance.
The previous Storyline system did not allow for scheduling. OTT platform producers would plan the teaser lists that appeared online and in the apps weeks in advance however they needed to log onto Storyline four times a day (4:00 AM, 9:00 AM, 4:00 PM and 7:00 PM) to update the teaser lists to match.
I designed a scheduling feature that allowed producers to schedule content up to two weeks in advance. This feature broke down each day into “dayparts” allowing the producers to schedule multiple teaser lists for each day. I played with various layouts of this design - organizing by daypart, by date, and by content block. In the end, I landed on the design that was the most digestible for the user.
This user flow represents the story “I want to schedule teaser lists for each daypart up to two weeks in advance.” In the old model, users were only able to schedule one set of teaser lists at a time which caused them to log into Storyline multiple times a day. Allowing the user to select days and dayparts helps them schedule content for the future.
This shows the teaser dayparting layout. OTT new producers can select the date, daypart, and teaser block that they would like to add teasers to. The content is very digestible. Since news producers don’t need to schedule, I’ve designed page editing which allows producers to edit or delete blocks.
Preview allows the user to view the teasers before they publish the content. This helps the user see any errors beforehand to avoid issues in the future. The user can still select the date and daypart to view all scheduled content.
Project 3: Search
Storyline houses all of the content for the news and OTT teams. When producers are trying to create new stories or shows, it can be quite troublesome to search through hundreds of thousands of pictures, videos, episodes and movies. Producers often complained that they were unable to find the content that they needed. They wanted filters and other advanced search features that allowed them to quickly narrow down the content.
The previous Storyline system actually had search filters however they were hidden in an unused button. When I interviewed producers, many didn’t know the button existed however recognized it’s value after it had been pointed out. Some of the filters were deemed useless and producers had thoughts about other filters that would be valuable for their searches.
I designed a new search system that allowed the producers to view the filters from the start. The content was also displayed in a new manner that prioritized the details and allowed the producers to work more efficiently. Producers could use a “quick view” option that allowed them to preview the content before opening it. This helped them make sure that they were accessing the correct package before continuing.
This user flow represents the story “I want to efficiently find the correct content in Storyline so I can build news stories or show packages.” Since users were having difficulty finding the correct content, I prioritized the filters to help narrow down the search results.
This wire shows what the user would see when they first encounter package search. You can see that the filters are clearly visible in a collapsible panel. We’ve edited the available filters to better match the user’s needs. The content displayed within the card has been re-prioritized based on the features that the users look for.
This wire shows the “quick view” The user can elect to view a shortened version of the content which helps them evaluate if the content is correct or if they need to choose something else. Users complained that they often times needed to open multiple packages before they could find the correct content. Quick view helps to alleviate this frustration.
Reflection
Next Steps
Visual Design: The visual design of Storyline was set back in 2015. The design is pretty monochromatic however the main accent color is red. Primary buttons and alerts are all red which is a color traditionally reserved for errors. Gray is used as the secondary button color which unfortunately makes most button look disabled. In the future, Storyline hopes to implement a new color palette with a more traditional color scheme.
Mobile: Many news reporters and producers publish stories from the field and doing so from a laptop is cumbersome. The Storyline team hopes to launch a mobile site allowing the news teams to quickly upload stories and livestreams as they work outside the office.
Role-based content: Since Storyline is used by different teams, much of the content doesn’t relate to every user. In the future, the team would like to role-base the content so users only see what is applicable to them.
Takeaways
Personas are everything: Since Storyline has so many user types, I really relied upon my personas to understand the users and their pain points. Most of my designs focused on a single user type, so I needed to make sure that I could design a viable feature that could be easily adapted to fit all user groups.
Options are valuable: As the only designer on the Storyline team, I often times needed to advocate for design and show the importance of an intuitive experience. Many problems were presented to me with the easiest engineering solution already attached. Instead of re-presenting the easiest solution, I often mocked-up a couple designs. I would tweak the “easy” solution and also create more intuitive designs. Providing options allowed the team to really think through the problem and pick the best solution for our users and our budget.