DesignOps Summit 2021 – Design as a Team: Practice, A Practical Guide to Cross-functional Collaboration (Christopher Taylor Edwards & Valerie Roske)

Christopher Taylor Edwards – Product Designer and Strategist, Lead, Thoughtworks

Valerie Roske – Lead Software Developer at Thoughtworks

 

Early in the project we got feedback from some of the developers that they didn’t understand why they were building our product

  • They didn’t understand how their work related to the larger context of what mattered for users
  • It became increasingly difficult for them to make appropriate tradeoffs on technical details

We had a situation where everyone individually had information that others needed but information wasn’t flowing between us, leaving everyone frustrated

  • Like an assembly line where you don’t really know what’s happening before you or what needs to be done after you and it can be difficult to know if and how your work moves the needle towards the desired user outcomes
  • Makes it harder to foster empathy with your colleagues

Look for the blockers – The unmet needs of the individual

BICEPS stand for

  • Belonging – People feel connected and community within a team
  • Improvement – People can see personal growth and progress word the purpose
  • Choice – People have autonomy and flexibility to make decisions about things that matter to them
  • Equity – People feel like the access to resources and information is fair and everyone is treated as equally important
  • Predictability – People can anticipate and prepare for future challenges an
  • significance the work is visible to others and recognized in ways that feel good

 

Developers were expressing need for improvement and understanding progress

Product strategists were expressing their need for choice, flexibility and how to express requirements

Everyone was missing equity and access to information as well as belonging and mutual understanding of their teammates

  • The assembly line way of working was introducing these unmet needs
  • How could we specifically address those needs?

Reimagined our biweekly showcases to include visualizations of how each individual unit of work was making progress towards new capabilities for users – people were engaged, motivated, and found meaning in our work

What does it mean to design as a team?

Human Centered

  • When we talk about designing as a team and solving real problems that teams are facing, we need to center all the humans involved
  • Regardless of our roles we must remember that we have shared goals that we need to achieve for our users

Systems Thinking

  • What are the structures barriers in ecosystems that our teams operate in and around?

Short Feedback Loops

  • Looking for opportunities to get faster feedback from the system as well as from each other

Using those values, we came up with a few principles that would drive those desirable behaviors and practices on our teams

Focus on exchange

  • I believe I have something offer and I believe I have something to learn from others
  • Foster collaboration and shared purpose to amplify everybody’s expertise and to breakdown hierarchy

Be open to experimentation

  • This is about imagining possibilities and trying new things and recognizing that experiments don’t have to be big it’s simply about asking you know what we could learn if designers and developers work closely together for instance or what about developers and product strategists or designers and quality analyst and then

Software is a social technical system

  • The process of building team practices is both technical and social
    • Not just about maximizing individual strengths and expertise but also about strengthening our relationships with each other in a cross functional collaboration

Approach is not prescriptions

 

How we put principles into action

  • Pairing is our entry point into cross functional collaboration

Pairing as an approach to collaboration

  • Fundamental level pairing is two people with two roles doing activities together simultaneously
  • Ex: driver and a navigator are pairing in the act of traveling in a car together

It’s important to consider what success looks like in collaboration before you start doing any work

In our example success of the trip looks very different based on our reason for traveling and changes the responsibilities of each participant and how they relate to each other

Applying the driver/navigator pairing to developer/designer pairing

  • The Driver – Developer
  • The Navigator – Designer

Example:

  • As the Developer – Core activity might be coding on some HTML and CSS together perhaps the impetus for us pairing is that I found an edge case and I have no idea how we should handle it
  • Invited the Designer over to pair with me and I’ll share my screen to explain the problem to the Designer who will ask me some probing questions to get more clarifying
  • The Designer can start sketching some thoughts, provide possible interaction patterns that could help solve the edge case
    • I can take those ideas and prototype them in real time and get his feedback to see if it looks right

  • If the edge case we’re looking at is particularly difficult and we’re not sure the proposed alternative is feasible to implement
    • We might switch roles
      • The designer might start to sketch the journey out to that point to understand what we know about the problem
      • Use the developers real time feedback on feasibility and technical constraints to draw the flow that will address that situation and figure out the problem to help our user

The activities that we pair on are pretty fluid and there are lots of ways we can take advantage of each other’s knowledge to solve problems

We must see each other as peers and patterns in innovation

  • Makes empathy and trust important for pairing activities

Social and Technical dynamics come into play whenever people are pairing regardless of the problem or goal

Influencing each other by exchanging expertise to reach our goals and solve the edge case

  • Maneuvered through our power differentials and other social and technical obstacles
  • Our conversations simultaneously helped make tactical and strategic decisions by expressing needs and offering each other insight into progress

We were getting better at working together we were fostering empathy with each other through sharing stories and understanding underlying needs and motivations and through all this learning to trust each other

Pairing

Create a shared understanding of our user journey and work together side by side to harness all our different skills and perspectives

  • The result of this cross functional collaboration represents our hypothesis on what’s feasible, viable, and usable without this
    • Product managers are merely guessing at user needs
    • Designers are handing over UI specifications without explanation
    • Developers are coding without understanding
    • Nobody is measuring if what we delivered was at all meaningful to the customer

What activities are worth pairing on? & Who should I pair with?

  • The answers are going to come from within your team
  • Start with a role and responsibilities exercise
    • This approach can be done with a whole group in a workshop at the start of a project
      • First, have each participant write down their strengths, skills, and expertise that they offer (even if the skills aren’t related to their functional roles)
      • Next, have each participant write done what they need from others to do their job well
    • Between you and one other person or informally daily at your check-in
      • More about the mindset of collaboration
    • Once everyone’s had an opportunity to share their ideas look for patterns and matches
      • Get everyone’s needs met through the various offers that are available
    • The exercise will start to reveal the opportunities for pairing

  1. Unmet needs
    • Address first, so people can do their work well and find satisfaction in their work
  2. BICEPS needs
    • Just because an issue didn’t make it onto a sticky note doesn’t mean it’s not an important thing to address
    • Perhaps we want to introduce new practices that will address those needs or find ways to incorporate change into existing practices
  3. Where an offer matches a need
    • This is a natural pairing
  4. Where offers match (pairing with similar skills)
    • Excellent pairing to share knowledge, reduce risk, and bounce ideas off each other to solve complex items
    • About injecting creativity into the workplace based on what people are most passionate about
  5. Where an offer is not utilized
    • Pairing is not solely about focusing on each other’s needs – not purely a transactional interaction
    • Just because someone’s offer doesn’t meet a need doesn’t mean what they have to offer isn’t interesting or useful
    • Through exploration we start to understand our team and coworkers and can gain new insights from surprising places
    • There’s potential in someone’s untapped knowledges – make the most of them
  6. Just ask
    • Breaks down barriers within the team

Pairing can be a vital activity in fostering trust and empathy within a team

  • A fundamental skill to building relationships with colleagues and experiment different ways of working

Designing as a team doesn’t mean that we eliminate the design role but that the team actively participates in design and shares an understanding of how the product solution supports the goals and values of the users

For more information – Design as a Team Guidebook by Christopher Taylor Edwards and Valerie Roske