Five things working at Thoughtworks has taught me about remote design

I live in Oakland. At the beginning of March this year, the State of California ordered residents to shelter-in-place and work from home if possible. Before the lockdown, I worked remotely on two distributed teams. I was an experience designer on these teams managing the user testing, user adoption and design recommendations for feature development across both teams remotely. Parts of my team was in North America, parts in India. Working from home was more or less the norm in this case. But that's not true for everyone. 

Flash forward to the present.

Thinking about the past nine months, I realized a lot of what I learned from being on a ‘remote-first’ project helped me transition to working from home full time. Whether it is now or it was before, building great digital products is just plain hard — very, very hard. Doing it on a remote, distributed team is especially difficult if you haven’t done it before. The added stress of the pandemic challenges even those with experience, myself included. And three months past lockdown, many of us continue to reinvent ourselves and our practices.

I am reminded that even the best teams run into the worst problems. In my experience, I’ve seen some of the problems center around communication, collaboration, research, and decision making.  

Communication: Design, product and development teams are not cross-pollinating ideas like they were before. Disciplines are siloing off and collaborating less frequently.
Collaboration Tools: Tools might be individual or discipline owned and used. There’s less collaboration and less visibility. Artifacts have more friction than they used to.
Design Research: Genuine customer-centricity means moving beyond having just quantitative information on the customer, to empathizing with them, through regular interactions to experience the needs and issues they face. 
Alignment/Decision Making: People are spending a lot more time in meetings which feel pointless and eating up valuable production time. Alignment isn’t happening and features are stalling out with either unclear prioritization or lack of confidence to launch.

But the good news is that it does get better with practice. Once my teams got over the initial hump, we ended up delivering some of the world’s best digital products on fully remote, distributed global teams. Finding practices that are resilient and adaptable helped us the most to our way in this new environment.

About this post

The post centers around five key practices I find helpful. These key practices focus on design’s value on a cross-functional product team. The key practices anchor in values of collaboration, communication, and transparency. They have specific learning outcomes that favor a remote or distributed team environment. In addition, for each I added a few starter activities to help the teams learn these practices. They found them enjoyable and that helped drive towards delivering a digital product.

Key Practice 1: 

Creating a Collaborative Digital Space 

I want to start off with the idea of space. 

Imagine a studio space, a conference room or a storage closet. In this space, there are lots of stickies and sharpies. Maybe snacks if you have brought them. Everything you and your team need to feel safe and productive for a good stretch of time is there. This is a place to deliberate on digital products you want to make. 

It might seem odd to start by talking about space when we are working remotely. But more importantly than ever, product design teams need a place to collaborate, brainstorm, share artifacts, and interact like you’re in the same room. The space — digital or physical — needs to support the activities of the team and become a way to embody values like transparency and collaboration.  The ‘space’, a Mural or otherwise, needs to be a place where a team can act in empathetic ways with the material. The energy of physical proximity to other people is essential for creativity in the work and it’s one of the toughest parts to do without. Because of that, I tend to design my spaces to hold place for different kinds of activities to debrief, reflect, and connect both together and apart. 

To work collaboratively — instead of individually — I need the space to be accessible by everybody so everyone can try stuff and not just sit around and talk. So we can show our progress through images, diagrams, and relationships between artifacts. The team needs to be accountable to our spaces, too, setting up the environment to amplify our work and foster the ability to be our best highly productive selves. 

Without these shared sacred spaces, things fall apart without even starting. Design, product and development teams do not cross-pollinate ideas like they were before. Disciplines are apt to silo off and collaborate less frequently. 

To avoid falling apart too soon, I recommend the following activities to play with in your shared space to get some practice. Mural boards are a great place to collect your assets.

Key Learning

Understand how to create a shared collaborative remote workspace to make visible the process from ideation to delivery.

Recommended Activities

Create an empathy map
Try Bet Prioritization
Create a UX Roadmap

Key Practice 2: 

Creating a Collaborative Understanding of the User 

Collaboration across a team that is based on trust and respect requires interaction with each other. This point can’t be emphasized enough. Whether it’s remote or co-located, one of the important decisions a team needs to make together is creating a shared understanding of a product that is aligned to the needs of the user through user research. 
 
There are tons of great ways to perform primary qualitative research remotely—from interviews to diary studies. For me, it's important for the team to be hands-on and learn through doing.  Finding ways to expose the team to that information in order to make sense of it, is where having good digital collaboration tools in place can make the messiness meaningful. Trello can be great for parsing the transcripts into quotes on cards, like the wall sorting of user data on stickies in your war room. Setting up time for the team to sort quotes into themes together can be a great way to involve all roles. 

In addition, the same data can inform a simplified journey that shows the sequence real people meander through to achieve their goals. As evidence, this provides a shared context for the team. This is something that can be added to the Mural if that's where you are working. Just as long as the team can get their hands on it together. 

Because the journey map will include users actions in steps that solve their problem and the emotions around that, the whole team understands how individual features support value the user takes away from the experiences. Building a consistent, usable product becomes easier if a team establishes this shared understanding early on. Following decisions based on that shapes the design, usability, and implementation work. If you don’t understand as a team what is valued, you can compromise customer-centricity and lose touch with the needs and issues of the people you want to help.

To avoid losing touch too soon, I recommend the following activities to play with in your shared space to get some experience. A Mural is great for this too.

Key Learning

Understand best practices of working in a remote cross-functional team on a design project through preliminary research, mapping journeys and prioritizing features.

Recommended Activities

Try gathering Preliminary Research
Try Hypothesis Generation
Build Customer Archetypes
Create a Customer Journey Map
Try Feature Prioritization

Key Practice 3: 

Creating Collaborative Design Practices 

This is in part about designers being able to work on the UI at the same time, but this is also about leveraging a team in the dreamy stages of an idea making to manifest and vet ideas early. Ongoing use of the shared collaborative workspace continues to make the design process visible during an ideation stage. 

One way to think about this is through the metaphor of a theatrical production. Consider the development of a product as the performance, the shared workspace as the stage, and the cross-functional team as the skilled performers. There’s the acts of the play too, that require the skilled performers to come on and off of the stage at very specific periods of time. No one is watching three plays at the same time with three different roles — well, maybe if this is a post-Zoom play. But generally, we consider all actors using the same stage to interact with each other, the play emerging from their interaction completing the story. In this way, I think collaboration becomes valuable for the team during this time in two ways.

First, the cross-functional collaboration on a team during design solution exploration includes other members outside of design that might introduce technical feasibility, focusing the potential design options around ideas that can be built. Every member of the team brings their viewpoints and their understanding of constraints directly into the design of the user experience. In this way, we as a team have synthesized these different points of view — product, design and development — into a well-informed design solution that will support the user’s expectations. It happens to be a bonus that generating the ideas together also fosters a shared ownership of the user experience and can accelerate decision making the team may encounter later on. This is the messy whiteboarding that teams do now in Mural.

 Second, design pairing, similar to pair programming is done for the sake of the product. Nina Mehta while at Pivotal Labs wrote about the benefits of pairing designers in the post ‘Pair Design’. Designers make creative decisions collaboratively, to externalize and validate thinking, to optimize for progress (not perfection), to remove individual ego and promote shared ownership of product. Pairing can improve projects by bringing fresh eyes to the process. When you work on a design by yourself, you can overlook details or fail to challenge your own assumptions; by working with another designer, you can prevent the cost of change because of developing the wrong thing at the wrong time. Patrick Gendron talks in depth about the value of design pairing in his post ‘Benefits of Design Pairing.’

In the decision making part of design, designers will often pair to iterate on visual affordances of screens and throw out design pattern ideas that solve the visual or interaction experience problems. Pairing is most valuable when this level of design decisions are being made. After that, and different from development pairing, designers tend to split the design work independently for separate things they need to do, like design features, screens etc. to move faster. Speed becomes more important and collaboration becomes a way of getting quick, frequent feedback.

As we have mentioned already, collaboration can dissolve along tool lines. This is largely because they are often individually or discipline owned and used tools. And, because of this, there’s less collaboration and less visibility to what each role might be doing. Because of this, artifacts will tend to have more friction when reviewed by other members on the team because there is less context of the decisions made by the disciplines.  

To avoid excessive friction, I recommend the following activities to play with in your shared space. Mural paired with medium fidelity collaborative tools like Figma or Sketch and Zeplin tends to work well here.

Key Learning

Understand remote collaboration within design tools and how this accelerates team decision making.

Recommended Activities

Try Concept Brainstorming
Map a User Flow
Create Wireframes

Key Practice 4:

Creating Collaborative Remote Research Practices 

I mentioned earlier the benefits of creating a shared understanding of a product that is aligned to the needs of the user through user research. User feedback is ongoing. In an agile environment, teams focus on launching small chunks of working code. These small enhancements, or advancements, in design should be constantly gathering feedback on their efficacy to users. The team wants to keep learning and adapting as they build. One way to do that, and make sure we are staying as close to solving the users problem, is validating what we are doing. Ideally, this contributes to the openness and culture of learning across the team through sharing information in timely ways. 

When possible, get members of your team involved in the research process the whole way through. Maybe it’s not every time or every member all of the time, but by having different people on the team help out with hypothesis generation or note taking in the research helps close gaps in the transmission of information. Less of take ‘my word for it’ and more of ‘you heard it yourself’. 

In terms of empathy, the whole team is building empathy with the user. The fewer handoffs you have between research and delivery, the more empathy stays intact. Developers and business representatives can be somewhat abstracted from the users. Distributing empathy for the user throughout the team subsequently establishes value to the team in the work itself. By observing and interviewing users as they interact with your prototypes and working software in any number of video shared screen scenarios, the team is able to understand the pains and gains of the user’s experiences  and develop empathy in the first person. And as a designer, feedback can be tracked in smaller more frequent check-ins with users limiting idea drift.

Effective team collaboration means a shift away from lengthy summary reports and playbooks towards more time working on solutions together as a team to get in front of customers for feedback, which is Agile at its best. The foundation of shared learning allows a framework for design to support collaboration over waterfall handoffs. If you don't understand as a team what is working for the user right away, you will compromise customer-centricity and lose valuable time in design and development investing too far down the rabbit hole of the wrong thing.I’ve shared feedback in team chats for informal, quick sharing and have kept a more extensive Confluence log for something I can go back to later and prioritize.

To avoid building the wrong thing for too long, I recommend the following activities in your shared space and Figma prototype or working software.

Key Learning

Understand best practices of remote research and how this refines design eliminating guesswork and waste downstream.

Recommended Activities

Craft a Testable Design Hypothesis
Create Defining Testing Scenarios
Prototype Something
Capture, Analyze, Socialize Research Data

Key Practice 5:

Creating Collaborative Continuous Design Practices 576

Cross-functional collaboration on the team during the development process continues the ethos of thinking about the usability, desirability, and feasibility of the product together for everyone involved. Thinking about the product from the beginning to the end this way makes sure we are not spending time on things that don’t have value to the user, aren’t meeting the business objectives or aren’t technically feasible. You can think of continuous design as a parallel to continuous development (CI/CD). As we build the product we learn and we make changes to the design.  

Design usually thinks of features as end-to-end experiences articulated in flows and wireframes. The leanest part of that design can enter the development pipeline but still requires close collaboration when splitting into work for delivery. It’s beneficial for designers to pair with the person writing the stories in order to make sure there is an adequate visualization of acceptance criteria for the story at hand. There are things that may arise as designs are broken into stories that are worth design consideration and sometimes quick design analysis. This might include micro-interactions, states, edge cases, or copy. This can be added as reference to the stories, and can help visually explain anything a developer might need to know as they begin working on the story.

Putting design work in the story wall also makes sure that design work is discussed in stand-ups and other regular checks of work in progress. One of these regular checks in progress is a ‘desk check’. The desk check, or technical and design pairing, is when a developer demonstrates to a designer a partial or completed story that has a design component. The focus is making sure the design meets the criteria in the story as expected from a user or a design pattern standard. The goal is to inspect the solution fast, discover any issues, and do quick changes without progressing to any environment beyond the developer’s local machine.

Stories are often written in a kind of shorthand that sometimes leaves out missing information critical to that story’s success such as acceptance criteria. A desk check is a communication touchpoint in real time. You are building a face-to-face relationship with your team mate and creating a shared accountability on quality. As Ian Pestelos says in his post ‘Test Early and Collaboratively with Desk Checking’, desk checks facilitate team collaboration rather than separation of responsibilities where typically only testers are responsible for inspection—an “throw-over-the-wall” testing mindset. As a designer, it is an opportunity to learn about limitations and understand why certain things aren’t possible. When you pair, your teammate can show or explain better and create a mutual understanding. The result is a developer understands the design POV and designer understands developer POV. Even setting up a special channel like ‘Ready for Desk Check’ in Slack or Gchat for this specific ritual can help facilitate these encounters. 

As the experience becomes a live product or service, design continues to evolve and refine itself. It will be important and necessary to keep and manage a design backlog. Later, after the experience gets released, the team will continue to test and gather feedback in order to learn, measure and evaluate how the design is meeting the users’ needs. New ideas or new enhancements to the existing designs need to be logged, groomed, and prioritized with the team. The value in this practice is visibility to design work and processes, supporting whole team ownership and participation. Otherwise, misalignment can persist and features everyone were excited about will stall out with either unclear prioritization or lack of confidence to launch. 

To avoid this sadness, I recommend the following activities in your shared spaces.

Key Learning

Understand remote collaboration within the design and development process.

Recommended Activities

Understand Design’s Role in Story Writing
Try Slicing Design
Try Technical Pairing
Plan Adoption and Continuous Design
Create Design Rituals in Agile

That about wraps things up—for now. This process is changing and evolving as we speak and would love to hear what everyone else out there is doing and what works well. 

Quick shout out to the folks that helped  read and re-read this: Rachel Murray, Christopher Taylor Edwards, Daniel Pallozzi, and Dongin Shin. And to anybody else who helped out in the editing of this. Also I tried to cite where needed, but please hit me up if something has gone misrepresented as I will do my best to correct it.