Beginning of Design Operations at Crunchyroll

Beginning of Design Operations at Crunchyroll

This is the first chapter of a two-part series on Design Operations at Crunchyroll.

Welcome to the waterfall world

Crunchyroll acquired Ellation, an Eastern European product company, around 2017. In my role as Head of Design in Eastern Europe, I had to evaluate how to integrate Ellation’s designers into Crunchyroll’s Design Department and how to work together. Despite the organization’s desire for maturity and scalability, most groups acted like startups. The design Department was no exception, and the collaboration model resembled that of vendor and customer.

A few themes emerged when I was halfway through the audit:

  • The “program management” comprised a Google Doc listing tasks and assignments.
  • The department did not have a Roadmap, Backlog, or shared vision for short and long-term goals.
  • It is unclear who decides what designers work on and whether that is a priority for the organization.
  • The visibility of capacity and allocation was vague.
  • Even if designers were grouped in pods, they couldn’t collaborate because files were kept on their computers. Some used GDrive, but at that time, Sketch had no real-time collaboration release.
  • Designers had essential style guides for each platform. There was no consideration of Design Systems.
  • “Definition of Design Done” wasn’t elaborated and collaboration with Development was fraught with problems.
  • Other than the Product, no other stakeholder was asked for feedback.
  • New features or improvements were crafted only for one platform at a time and without consideration for how to scale on other platforms.
  • The live applications UI differed significantly from the initial design deliverables since the designers weren’t reviewing builds.

I advocated for Crunchyroll to adopt a cross-functional scrum model since we had one at Ellation. It was decided to divide the groups into departments, use Scrum for Development, and let the Design Department use Kanban.

Design Process

Collaborating with a working group of designers, I gathered data on design challenges and options to alleviate them. The following steps were implemented after the solution was presented to the whole Department, the Product Design Director, and the Chief Product Officer:

  • We kept Sketch and added Abstract for distributed collaboration. I want to remind you that we had Designers in the United States and Eastern Europe.
  • Invision replaced Marvel.
  • Zeplin was added to Invision for handoff to development when it didn’t have Inspect functionality built-in.
  • My colleague and I started to create the first Design Systems, and I wrote a case study about it if you’re interested

Why not use Figma, you might ask? Adding Figma to a group with an inefficient process was too challenging for us. Moreover, designers considered it difficult to learn. Things are changing in 2022, and there is a desire to switch to Figma.

Program Management

Crunchyroll purchased Ellation, an Eastern European product company, around 2017. In my role as Head of Design in Eastern Europe, I had to evaluate how to integrate Ellation’s designers into Crunchyroll’s Design Department and how to work together. Despite the organization

Jira was the app of choice for design management. I helped the Product define the backlog and trained Designers on Kanban principles. We needed to identify the phases of the design process and ways of collecting feedback from stakeholders. I’ve created a Jira Kanban workflow that allows designers to pull tickets whenever they have free capacity, preview and gather input, request design QA, Design Approval, Product Signoff, and close the ticket.

Standups

The time difference poses a challenge for distributed teams regarding real-time collaboration. To make this easier, I established Standup as a way to meet daily to sync on work in progress, offer critique, share challenges, and mitigate risks.

Previews

After testing it with one of the design teams, I introduced a live design preview/review to all other teams. Product, Development, and Design can now gather feedback in addition to offline asynchronous methods.

Retrospectives

Designers were divided into pods by platform, so there were Mobile, Web, and LRX (10-foot user experience or, as we call it, Living Room Experience) teams. I met periodically with each group to discuss what was going fine and the challenges and brainstorm solutions. Retrospectives helped us determine when and what to course-correct and make designers feel that their needs mattered.

Definition of Design Done v1

It is essential for Product Design that the final designs respect platform development guidelines just as much as the explorations or iterations. For each platform, I wrote a set of guidelines to raise quality and add to the workflow a way for Designers and Developers to agree on what is best for implementation.

Learnings

Having worked with Kanban for some time, I realized that some problems cannot be solved, and we must explore other options.

  • There are a significant number of tickets in progress at any given time, and limiting the number of tickets in progress wouldn’t help.
  • A small number of designs are tested. As soon as a ticket gets into the “ready for UX testing” column, weeks pass before the results are received.
  • The company and design department do not clearly see how many new features to design versus how much time to spend fixing/improving the product.

No, this does not mean I’m against Kanban. We were not ready for it. I believe a group should start with Scrum, learn, adapt, and then switch to Kanban. Kanban is for mature teams.

Would you like to read part two?