Objectives

• Improve the speed and performance of content management workflows through optimized controls and access to key information.

• Deliver a scalable solution for artists with few releases through to distributors with large complex catalogs.
• Establish a blueprint for future design sprints conducted within the organization

Background

The catalog section of Workstation (The Orchard’s client facing suite for setting up and managing music releases) is a core component of a label product managers workflow in co-ordinating releases from setup through to delivery and release at music stores and services.

As the existing catalog management page was built upon legacy technology, the performance was incredibly slow and especially frustrating for labels and distributors managing and organizing catalogs with thousands of releases each year.

Addressing the performance issue became a high priority following strong feedback received from a number of high profile clients, including:

❗️Extremely slow page performance (average 20s page load)

❗️Missing critical product information and metadata (product codes, projects, storefront links) 

❗️Inconsistent releases statuses across product types (digital audio, physical and video)

Design Strategy

While engineering focused on rebuilding the front-end and backend technology to serve the page faster, as the product design lead, my objective was to ensure users experienced the perception of speed across their workflows. Providing more effective and efficient ways of filtering, sorting and accessing the information users needed to perform daily tasks was equally important as page-load speed.

There was a short time-frame before engineering was due to commence work and we needed to ensure we had an effective solution that would solve the immediate speed and performance concerns, while establishing a scalable long-term vision for the catalog management that anticipated the needs of new user types (such as artists) and functionality out of scope for the initial rebuild.

Working with a new product manager, I floated this as a potential candidate for a one-week design sprint – a design process periodically discussed amongst the organization but seldom acted upon. We treated this as an opportunity to both define and validation solutions in an expedited manner, while also documenting our learnings and artifacts as a resource for other teams in future design sprints.

Designing a product entirely from scratch is often a luxury position, whereas redesign projects require a balance of long-term vision setting and prioritizing practical steps to get there, while maintaining core functionality. With those thoughts in mind, I worked with Mike, a Product Manager, to coordinate our approach and set some high-level objectives for the design sprint:

Share sprint learnings with the wider product and design teams and provide a framework for future sprints

Planning

I set out by drafting a sprint planning document, working with the PM to outline our goals and deliverables for the sprint, identify team members and stakeholders involved and schedule sprint activities. This would act as a grounding source of truth throughout the sprint, continually updated and referenced as we went. Our core team comprised of a Product Designer (me), a Product Manager and a Product insights researcher.

“By the end of this design sprint we expect to have gathered interviews with Workstation users, produced a workable prototype for a redesign, present back to stakeholders with the workable prototype for final approval and hand off to Engineering. 

Success in this design sprint means delivering a prototype that allows clients to get a high-level overview of their catalog and take meaningful action from the catalog page.”

With a tight window to deliver a workable solution, along with limited stakeholder availability, we opted for a modified version of the traditional Google Ventures Design Sprint. The discovery and ideation phases where stakeholders were involved was limited to two days, while we allowed additional days for the design team to develop our prototype amidst balancing regular workload.  In hindsight, delaying the sprint to accommodate more stakeholder input would have been ideal.

PHASE ONE

Discovery

Background Research 

Prior to the sprint kickoff, we compiled a set of assumptions, based on existing insights and research.  Previous annual client surveys had surfaced wide-spread frustration regarding slow performance across workstation which we were well aware of.  On the catalog page specifically, respondents also expressed frustration by the lack of consolidated product information and actions available to them.

We lined up a set of 30-minute contextual interviews with range of users, from individual artists managing their few releases, to large third-party distribution labels managing thousands of releases.  In addition to the pain-points described and uncovered in previous research, we wanted to better understand their mental model around managing their catalogs, what catalog information and tasks they needed access to in their core workflows, and how that differed across user types.

Across interviewees, we found: 

❗️ Most labels relied on separate spreadsheets and google docs to manage their catalog metadata and upcoming releases

❗️ Unhelpful filters for users when wanting to search across projects/products/releases. Users instead, navigated to the homepage to search for specific items due to speed and clearer organization of search results (over the catalog page filters)

❗️Accessing metadata and status information integral to managing a release (Product Codes, parent projects, delivery status, release format) often requires navigating to other pages multiple clicks away

Synthesis: Reframing the problems 

To synthesize the insights uncovered in research and interviews, the core sprint team regrouped to review the interview findings and conducted a ‘How Might We…?’ brainstorming exercise to reframe these problems as opportunities.

Based on these opportunities, we followed this up with a similar activity, using the prompt ‘In two years time the catalog page will be..’ to establish ambitious principles for a long-term vision for the catalog page.

Combining these goals into high-level guiding principles would help focus us throughout the remainder of the sprint,  as we looked to include additional sprint participants from the engineering and product organization during the ideation phase.

IN TWO YEARS TIME THE CATALOG PAGE WILL BE…

The catalog tool should provide access to metadata and releases across projects, products, tracks, artists and rights.

I can customize how I organize and view my catalog to match the mental model and primary workflows.

The catalog tool will allow me to answer any questions about my catalog. Given a specific piece metadata, I can find any product in my catalog.

I can manage and access releases from a centralized tool. I am no longer reliant on external spreadsheets to manage my release schedule workflow.

The catalog tool is fastest way to access information about my content.  I can perform complex actions and queries with the expectation of receiving results quickly.

PHASE TWO

Ideation

With a solidified understanding of the problem space, we wanted to involve more perspectives to generate ideas before narrowing on a single direction to prototype and test. I facilitated a two-part sketch workshop involving engineers, product managers alongside the core sprint team to get there.

 Idea Generation – Crazy 8’s

After walking through research findings and using the visionary principles as a prompt, we started with a Crazy 8’s exercise, prompting participants to sketch eight rough ideas in 8 minutes. Each participant then presented their sketches, before we dot-voted on the strongest ideas to develop further in the next phase.

 Unifying the strongest ideas – Solution Sketch

In, the second round of sketching, we provided more time to focus on developing the strongest ideas from the previous round into a more unified sketch.

Flexibility and Comprehensiveness were two themes that came up frequently across solution sketches, with most sketches including grid/toggle views along with access to additional metadata

PHASE THREE

Prototyping a testable solution

As we ran out of time to include all participants in a voting exercise following the sketch workshop, the core sprint team evaluated the solution sketches and identified core functionality that met our guiding principles, to include in our testable prototype.

Before we jumped into prototyping, Mike and I also prioritized a set of user stories to focus on for the MVP.  This allowed us to separate more ambitious longterm ideas from the critical functionality we wanted to prototype and validate before development commenced.

I worked with two remote product designers to produce a testable prototype incorporating the priority functionality, while also capturing long-term concepts for later reference.

Key design improvements

PHASE FOUR

Validating our sprint solution

To test and validate our prototype, we reached out to a mix of participants we interviewed with earlier, along with users we hadn’t yet spoken to.  Since we had included a lot of new functionality in our prototype, I wrote out a list of design assumptions, accompanied by a task or question for the user test script to ensure these were covered in our final prototype:

Sprint Prototype Demo

Findings

Our proposed solution tested well with users and addressed many of their prior pain-points. Where some new functionality was missed (such as customizing columns and store links) we increased visibility of these UI controls to include labels and icons.

Following testing, we wrapped up the sprint by reviewing our findings and proposed solution with stakeholders for sign off, before iterating the designs and breaking down stories with product and engineering leads prior to development.