At UXDX USA 2022 we invited 37 speakers to share their case studies on how their teams are improving their ways of working. The agenda is focussed on breaking down silos and helping companies shift from working in projects to autonomous product teams, and the challenges that companies face on this journey. In this series of articles we are sharing the key trends that arose at the event.
Increasing efficiencies in product teams
Product teams are great for moving fast, but they are not the most efficient way of working. Functional structures are very efficient, when things don’t change much. But since we live in a world where the pace of change keeps increasing, functional teams are not feasible any more. Given this challenge companies are identifying ways that they can improve the efficiency of product teams without sacrificing the speed of delivery and innovation. And this has led to the explosion of Ops teams!
Marieke McCloskey, Director of UX Research and Kassie Chaney, Director of User Research and Content Design at LinkedIn had a conversation about their internal organisational design.
In Linkedin, there are decentralised teams aligned to product teams who focus on their respective customer segments and product needs.
In addition, they have a centralised research team, which can leverage scale to focus on bigger picture research tasks, pulling together research from around the company and thinking about ways to make research better. Interestingly they don’t call this team ResearchOps, which is seen as a more administrative function within LinkedIn, whereas this centralised team is filled with serious research practitioners doing real research.
The description of the centralised team matches what I would expect an Ops team to do. An Ops function should be staffed with your most experienced people because they are the ones who know the challenges of the role and are best placed to solve the problems. It will be interesting to see if this push back against admin-style Ops teams continues.
DesignOps and Design Systems
One of the biggest challenges as teams scale is ensuring coherence of design across teams. Design Systems have built on style guides to help achieve this coherence but they come with challenges around maintenance, utilisation and ease of use for developers.
Alkistis Mavroeidi, UX and Product Design Manager at Kayak explains how they evolved their Design System to address these challenges in her talk on 3 Learnings from KAYAK's Design System.
"Design, engineering and the product team are the core teams that need to work closely together. We strategically made choices for a baseline UX UI that is using the same components for all brands. It also helped us create integrations between design and code, through component libraries, design tokens, and a scalable theming model.
This focus on utilisation and usability helped to ensure efficiencies were maintained as they expanded their design system to tackle the consistency problem.
"In the past few years, we came a long way to building consistency. First, within one brand by starting off with building the Kayak design system, and creating unified components for all the travel experiences. We then proceeded to expand and scale the design system to the rest of our brands, and create a system that's flexible enough to accommodate the unique challenges and allow for different modes across various brands"
Davy Fung, Product Design Manager, Disney Streaming explains how tokens have helped to ensure coherence across brands. Disney+ is global so they need to support many different languages and typefaces, like Asia Pacific languages.
"As a team, we unpacked the support tokens for typography, which includes type size, line height, letter spacing, brand colours, and utility colours, and spacing in general.
"This has already paid dividends to Disney and Star+ as two brands that live in separate locales. [...] because of the alignment work that we've done with typography tokens, we were able to extend the support for new non-Latin typefaces. So a lot of the work that we're doing early on to think about future alignment has shown results very quickly," he explains.
Baylie Brenner-Bruzgis, Head of DesignOps at Twitch, tackled DesignOps from a different perspective, that of the DesignOps leader, in her talk on Integrating, Scaling & Maintaining DesignOps. Her tops tips included:
- Ensure there is the right appetite for DesignOps
The leader DesignOps reports into should be looking for a strategic partner, not an admin assistant
- Have a compelling value prop
Prepare an elevator pitch for DesignOps
- Get to know and really care about the team
Be the voice of the team when they need it
- Be credible and consistent
Understand the commitments your boss is making, avoid over committing and deliver!
- Foster relationships across the business
Be conscious of politics and get ahead of people trying to undermine you
- Be flexible and always learning
Nothing is ever finished
Developer Experience (DevOps was taken!)
A key theme for developer experience at this year's event was around security, because cyber attacks are becoming more common and the impacts of a breach, from data leakage to ransomware attacks, can be costly and damaging to companies. Specifically, the focus was on how to decentralise control of security to the product teams so you are not slowing them down by conducting an, often too late, security audit, while simultaneously improving security quality.
Frédéric Rivain, CTO at Dashlane, explains that product teams need to take ownership of security because security, like quality, is everyone’s responsibility. But for teams to take ownership they need to be aware of the most common attack vectors so that they can know how to mitigate against them. He lists the five common vulnerabilities in his talk: Security and Privacy when Building Great Products
- Compromising the application
- Compromising the user’s device
- Compromising the server infrastructure
- Compromising our internal IT (e.g. the pipeline)
- Compromising an employee
By being aware of the possible risks each team member is responsible for designing an architecture that minimises the chances of being attacked as well as limits the impact should an attack be successful.
In another talk, Feross Aboukhadijeh, talks about How to Secure Your Software Supply Chain, which aligns with the Compromising the application vulnerability. On top of sharing some humorous and scary examples of how software supply chains can be attacked and the impacts that it can cause, he shares the tools that developers can integrate into their build pipelines to mitigate the risks.
The theme in both talks was that you shouldn't rely on a separate security audit, which slows down product development, but, rather, empower teams to make security a key part of the job.
The list of Ops wouldn’t be complete without mentioning ProductOps. Some of the most interesting opinions on ProductOps arose in our Forum sessions. Forums are informal conversations between attendees centered around specific topics. Feedback was that the forums were one of the standout pieces for the in-person attendees as it allowed them to share their experiences, hear how other people are tackling the same problems and create connections with people they wouldn’t have already met.
In the session on Product versus UX it became apparent that a lot of ProductOps teams are doing a lot of the same things that ResearchOps teams are doing in other organisations - streamlining interview set up, helping to document insights, enabling broad access to research data and evangelising the customer within the product teams.
The other challenge for ProductOps arose during the Role of the Product Manager forum where it became clear that everyone had a different definition of the role of the product manager and where the boundaries lay; from the product manager setting the vision for empowered product teams to the SAFe product managers writing requirements documents for teams. The majority of people lay in the middle - trying to work on the vision while being dragged into the delivery.
ProductOps can help in these situations by clearly defining the boundaries in roles and helping to remove some of the admin overhead from PMs so, instead of trying, they can succeed in developing and evangelising the product vision and strategy.
Guilds and Communities of Practice
Functional structures are great for learning and development. There are clear role delineations with specialists who are experts in particular areas. This is a challenge in product teams which favour generalists.
Guilds are a fantastic way of solving this problem by helping people to develop skills in particular areas while also opening up opportunities to people who would normally not be able to learn such skills.
Cindy Chastain SVP, Global Customer Experience and Design and Mastercard shared how they were surprised when they discovered that most people attending the guilds were not in the corresponding function. This delivers the benefit of developing the T-shaped skills across their product teams.
"We learnt that 76 percent of our guild members have experiences in other disciplines.”
By bringing together the different roles within the guilds, it allowed Mastercard to identify the areas where there were the biggest skills gaps so they were able to target their training.
Companies are experimenting with ways to increase the efficiency of their product teams by trying to remove and automate as much of the administration work as possible so that teams can stay focussed on the core work of building products for customers. There is always a fine balance to navigate between Ops functions that support and empower teams and ones which impose mandatory ways of working on teams. If you are implementing similar structures beware of falling into the trap of the PMO’s of old which often provided little benefit for teams but incurred large overheads. By allowing teams to opt into the work of the Ops teams it ensures that they stay focused on the needs of the teams rather than other stakeholders. Customer centricity strikes again!
I hate "It depends"! Organisations are complex but I believe that if you resort to it depends it means that you haven't explained it properly or you don't understand it. Having run UXDX for over 6 years I am using the knowledge from hundreds of case studies to create the UXDX model - an opinionated, principle-driven model that will help organisations change their ways of working without "It depends".
Free Community EventsSee all
Get latest articles straight to your inbox
A weekly list of the latest news across Product, UX, Design and Dev.