content design.jpg

Defining Content Design at Lyft

Defining Content Design at Lyft

When I started at Lyft in early 2020, content design (CD) was about 3.5% of the product design team and supported about 85% of projects. Most CDs were juggling 15+ projects at a time and supporting 50+ partners across product design, product management, engineering, UXR, marketing, and more.

The team was working reactively to cover a high volume of projects. And since quantity was the team’s primary metric for success, CDs were pulled into projects after designs were locked with limited product context and very little time to iterate. CDs were experiencing burnout from context switching, rarely felt pride in the quality of their work, and didn’t always feel like content design was fully understood or appreciated by partners.

If you’re not a CD, you might be wondering why we needed to move away from prioritizing quantity over quality. One of the biggest misconceptions about CD is that it’s always quick. And while product content can be speedy, it often takes more time and iteration than partners realize. That’s because CDs primary focus is determining what to say—not how to say it. The best CDs aren’t merely copyediting the language they receive in a Figma file. Instead, they’re diving deep into the experience by considering what the user really needs to know right now, organizing the overall flow of information across screens and components, understanding the technical constraints of the dev environment, surfacing and addressing edge cases, balancing legal constraints, writing for localization and accessibility, and more.

Content informs the overall design and product strategy. CDs can’t produce content without considering the full flow, hierarchy, and components. It’s what informs how and in what state the info will appear. Similarly, product designers can’t create a flow without considering the content. It’s what gives momentum to the screens and helps determine components. Working together throughout the design process is where the magic happens. When CDs are included early, they can point out that we’re missing a critical piece of information and need to add a screen, that the hierarchy of information is a little confusing and we need to rearrange components, or reach out to an engineering partner to determine if we can include dynamic content in a string to help users make an informed decision.

Although I was the sole IC CD on three high priority lines of business (Driver, Fleet, and Mapping), I set out to transform CD at Lyft so we could have a greater impact on the user experience and business metrics. My goals were to improve ways of working and team morale, raise the bar on craft by creating foundational resources, and get CDs to a place where they could focus on the highest priority projects.

Thanks to these efforts (and many others spearheaded by CDs and others throughout Lyft), by 2022 our team grew to about 8% of the product design org, CDs were able to focus on fewer (and higher impact projects), and the team reported increased job satisfaction.

I focused on three pillars when it came to defining and improving CD at Lyft:

  • Quality and culture to help streamline styling decisions and provide ongoing guidance to improve craft and morale.

  • Process to get the team out of reactivity and into proactivity by allocating CDs to fewer and higher priority projects, providing clarity around key CD activities across the product development cycle, and improving cross-functional collaboration.

  • Evangelizing came to life through ongoing roadshows and presentations* to cross-functional partners and leaders throughout the company.

    *In addition to this top down approach, I’m a big believer in the bottoms up approach of proving and showing value. When CDs have time to go deep, iterate with partners, and show thorough explorations, they’re able to highlight how vital and time consuming it is to create useful and concise product content. The day-to-day work of showcasing that product content is a UX practice also helps underscore that CDs can’t meaningfully support everything. Therefore, improving content quality and creating a process is also a big part of evangelization efforts.

 

QUALITY AND CULTURE

Style guide

What: Comprehensive best practices on Lyft’s internal hub with component guidance and tips for writing for localization, accessibility, and legal, and more.

Why: Since best practices for product content weren’t documented, CDs were spending a lot of time asking each other duplicative standards questions and/or making one-off styling decisions to meet tight deadlines. Not having codified best practices and guidance was therefore time consuming and contributed to inconsistencies and content debt. Additionally, cross-functional partners were used to reaching out to CDs for all content questions, big and small. We needed a Lyft-wide resource to help teams unblock without needing to reach out to CD.

How: I wrote more than 50% of the sections and managed a team-wide initiative where every CD was responsible for writing at least one section of their choosing and reviewing 3-5 sections. I also created a governance model to ensure that updates and edits were discussed and finalized by the entire team.

Impact: Improved CD focus time and content quality. Reduced ad-hoc CD asks.

Terms sheet

What: A Google Sheet repository of Lyft-specific verbiage that tracks correct and incorrect usage across platforms.

Why: Similar to the style guide, the team was spending a lot of time asking each other about terms. Since we didn’t have a source of truth, there was a lot of inconsistent terminology in our product. Tracking and updating terms in a Google Sheet allows for collaboration since the team can easily add or edit terms usage, and gives partners one place where they can quickly reference verbiage.

How: I created the initial list of terms and rallied the team to make updates as questions arose.

Impact: Saved the team time and improved term consistency. Our terms sheet was linked in our CD style guide, so anyone at Lyft could reference it.

Survival guide

What: An in-depth presentation with everyday guidance and tips for common CD/UX scenarios.

Why: CD is still a relatively new field and many members of the team were experiencing similar pain points when it came to being included in projects at the right time, presenting their thinking, completing CD reviews, etc.

How: Identified the need for this resource, created deck based on all the lessons I’ve learned over the years, and presented it to the team. Also linked out to relevant sections in the CD playbook for greater cohesion.

Impact: Even a year after sharing this deck with the team, CDs would tell me that they reference it every day.

Showing CD thinking

What: Figma templates so CDs can showcase the depth of their thinking and explain the rationale behind their recommendations.

Why: CD can be invisible work. If a partner just sees the final content in a flow, it’s not always apparent why a CD made a specific decision. By creating Figma templates, CDs can more easily share the complex work of bringing a concept to life in product. Additionally, situating this work within Figma more strongly aligns CD as part of product design.

How: I created the majority of templates and encouraged the team to add their brilliant templates as well. Templates were also shared out in the CD survival guide and CD playbook for greater cohesion.

Impact: CDs began to share the why behind their content during crits and presentations, which resulted in better collaboration and respect for CD recommendations.

Checklist

What: A checklist that outlines the dimensions of good content design to improve quality and help partners understand what goes into bringing product content to life.

Why: Since we were moving to a model where CDs wouldn’t support everything, having a checklist helped cross-functional partners understand what constitutes good content so they could iterate on and finalize product language. We also had several wonderful junior CDs on the team, and the checklist helped them more quickly understand how to assess their content across various dimensions.

How: I wrote the first draft of the checklist and partnered with another senior CD on finalizing it.

Impact: Helped junior CDs onboard quickly and understand expectations. Additionally, CDs were able to share the checklist with partners who didn’t have CD support. The checklist was also shared out in our style guide as part of self-service resources.

Mentoring

What: I held ongoing 1:1 mentoring and office hours sessions with the team.

Why: As the most senior CD IC, the team looked to me for guidance and support. Since we were also figuring out the world of remote working, it was important to carve out intentional space to connect and collaborate.

How: I held weekly 1:1s with 4 CDs (junior and senior), along with office hours sessions twice a week for anyone on the team to jam on projects or just talk.

Impact: It’s hard to measure the impact of mentoring, but I hope all my mentees got something out of our time together. My office hours session were almost always fully booked, so the team seemed to value having dedicated time to jam.

Strengths activity

What: An activity I led during a team offsite focused on helping each CD identify their unique strengths, connect them to their product team’s needs, and determine their own metric for success.

Why: Team morale seemed to be declining (being a CD can be hard and it’s easy to fall into the trap of equating one’s success with whether or not our partners understand what we do) and I wanted to recenter the team around autonomy and the opportunity to create new definitions for impact and success.

How: Created and led an interactive activity during our team’s annual reflection.

Impact: Several members of the team reached out to say that the activity gave them a new perspective on their project work and helped them identify a path forward.

 

PROCESS

Intake and planning

What: Developed and implemented an intake model, support framework, and proactive planning process that allowed CDs to better identify and support requests.

Why: CDs were trying to do everything all at once and fielding requests over Slack and email, leading to porous and idiosyncratic ways of working. This wasn’t sustainable and reinforced that CD work could be done quickly and with minimal context. Given our lean resourcing, we needed to find a sustainable and clear way to support planned work and ad-hoc asks.

How: Created a framework for the level of support we’d provide (eyes-on vs. hands-on), a company-wide monthly CD planning process to ensure leadership buy-in, and a formal intake process so we could vet and track all requests. Worked closely with the design program management team and a senior CD on the proactive planning process.

Impact: Gave CDs much-needed focus time, while still ensuring that we were providing partners with the right level of support (i.e. end-to-end CD support vs. a working session or time-boxed support).

Prioritization

What: A deck that helps demystify what’s a high impact CD project.

Why: A frequent topic of conversation with the team was that they were feeling pressure to work on everything and weren’t always sure how to prioritize—particularly since they were so used to working on everything.

How: Created a framework and presentation for the team.

Impact: CDs were able to use the framework to more effectively select projects and explain their allocation rationales to their cross-functional partners. The framework was also adopted by the design program management team.

Playbook

What: A flexible, comprehensive content blueprint that shows key milestones, secondary activities, alignment moments, deliverables, and dependencies across the entire product design process (kickoff, explorations, refinement, reviews, handoff, retros, and ongoing iterations). I also created additional contextual resources like a project plan template to identify expectations for CD involvement, identify outputs, and dependencies early, along with guidance for content reviews, tips for working with partners (legal, eng, and marketing), and more. The playbook included links to preexisting resources from the CD style guide, survival guide, and more for cohesion and ease of use.

Why: As we carved out more focus on projects, CDs weren’t always sure what was expected of them at any given phase of a project in terms of deliverables and collaboration. This was particularly needed since Lyft didn’t have an established process, so CDs had been trying to adapt their working style and deliverables to each individual partner. To work more effectively, CD needed a playbook for better clarity and guidance. Codifying our playbook also highlighted the complexity of our work and better situated the discipline within the product development lifecycle.

How: Owned the entire playbook from end-to-end and held ongoing workshops and shareouts with the team to make sure it was as accurate and useful as possible to ensure adoption.

Impact: CD team loved having a resource they could reference at any and every step of a project to identify what needed to happen next. Also helped our cross-functional partners understand why CD needed to be involved early and often.

Boundaries

What: A presentation so the CD team could more confidently focus their energies on the highest impact projects.

Why: The team was accustomed to saying “yes” to everything and weren’t always comfortable with setting and holding boundaries. To get the team out of reactivity and overwhelm, we needed to empower the team to say “no” to lower impact requests.

How: I created a presentation explaining why it’s hard to set boundaries (we want people to like us and it feels so good to be needed) and why boundaries are necessary (we really can’t do it all and saying “yes” to everything is actually saying “no” to the most important work). The presentation included specific strategies for saying “no” (redirect to a resource or another team, offer up a short working session, or empower the requestor to own the content).

Impact: Team was much more confident enforcing boundaries. The presentation was so successful and that I was asked to give it to the UX research and design program management teams.

Resource guide

What: A big ol’ Google Sheet to help CDs find and discover resources.

Why: If you’ve made it this far down (hi, thank you for reading!) you probably know that we had a lot of resources at this point, but they weren’t always easy to find. This meant that the team was spending a lot of time reaching out to me and others asking for links to various docs. We needed to get everything into one place.

How: I created the doc, shared it with the team regularly, and made ongoing updates.

Impact: This doc became another widely-used doc that helped the team quickly find the resources they needed when they needed them.

 

EVANGELIZING

Roadshows and presos

What: Various presentations explaining what CD is (and isn’t), why it matters, and what we work on to help our partners understand our unique role.

Why: Our partners didn’t always understand what a CD does (aka we’re not copyeditors and/or copywriters). We needed to show that language is foundational to the product experience and that content influences the overall flow of information across screens and components. CDs also need to understand the dev environment and backend logic when crafting content. Since our work often drills into the specificity of what’s happening and how it impacts users, CDs have an important role to play in identifying engineering optimizations.

How: I created and gave presentations to the entire product design team (designers, UX researchers, and design program management), marketing, product management, and engineering teams. I also created an intro page in our CD style guide that summarized our role and the surface areas we own so we’d have a resource we could easily share with cross-functional partners.

Impact: Many attendees cited that the presentations helped them understand the complexity and importance of content design. We saw a decrease in the number of asks for copyediting and copywriting support.

Collaboration

What: A presentation about what we do, why it matters, and how best to partner with us (i.e. bring us on early and often, give us time and context to iterate, and create space for CD to contribute to the flow).

Why: As we moved away from reactive asks toward a place of proactive planning, we needed to educate our partners on how to collaborate effectively with CD.

How: I created the deck and presented it to my product teams. Based on the success of my preso, every CD shared it with their design partners (and a few even shared it with their product managers and engineers). Was also included in the CD playbook.

Impact: Several CDs cited that their partners better understood their roles after the presentation. Having a deck also gave CDs a resource they could point their partners to if they had questions or concerns about working effectively with CD.

Jeopardy

What: An interactive game about CD and our style guide I led during a product design all-hands.

Why: We had given lots of presentations and created many resources for and about CD. To make it all stick, I wanted to create a fun and interactive way for the entire product design org to engage with our CD style guide and better understand what we do. A Jeopardy game just felt like the right thing to do.

How: Came up with the concept, wrote all questions, identified and onboarded participants, and hosted the game.

Impact: Several attendees reached out to say how delightful and informative the game was.