Chris Kimbell Head of Design at Trello, part of Atlassian. His team consists of product design and research talent, distributed across a few time zones.
We interviewed Chris to find out how the Trello team designs remotely together and what advice he has for others. Read on to find out how the team at Trello works effectively from a distance.
JIM: Tell us a little about the UX team at Trello. What's the make-up of the group? And what's your secret sauce for delivering great experiences?
CHRIS: The Trello product team is made up of cross-disciplinary teams which include product managers, product designers, developers and product marketing managers. Those teams may also partner with research, analytics and growth people. The product design team has product designers embedded in those cross disciplinary teams.
We don’t have dedicated user experience roles. Instead, everyone at Trello feels responsible for creating an excellent product.
Most experience decisions are made at the cross disciplinary team level rather than being decided by someone not as immersed in the problem.
Our not-so-secret Taco sauce is sticking to a set of principles, many of which have been around from when we started out. They explain our approach to making Trello. For example we have a principle that ‘Trello is easy’ so that a new user can be up and running in a few minutes. As ideas come up, we ask how the idea fits in relation to our principles.
JIM: I understand your team is dispersed, right? Can you describe that situation and how you collaborate on a day-to-day basis?
Distributed collaboration is fundamental to our culture. Trello has always embraced remote work, going back to practices pioneered at Fog Creek Software where Trello got its start. Today the Trello team is 70% remote although we have an office in New York and are part of Atlassian, a much larger organization which has offices around the world.
The Trello design team works entirely from home offices. Like many design and product teams we are not just creating a product, we’re simultaneously refining a process for making product. For us that means exploring better ways to collaborate on design as a distributed team.
Day-to-day we use tools like Trello, Invision, Figma, MURAL, Zoom, Stride and Confluence. What’s notable about remote collaboration though, is, when you break down how a software maker spends their time these days, anytime they’re working through a screen they could be anywhere in the world.
For software makers, it's arguably a benefit to be remote because there’s less distraction.
JIM: What challenges does your team face in their remote collaboration?
CHRIS: The challenge then becomes how do you have effective synchronous, face-to-face design meetings when you’re not in the same physical space. While those meetings are hopefully only a relatively small part of a maker’s week, it's still important to get right.
We’ve been exploring various collaboration exercises from design sprints to critiques to problem framing, but doing those all remotely.
We’ve learnt that it's important that people who aren’t in a local office have the same experience of a meeting as those who are, so all meetings happen as video conferences on Stride or Zoom.
Everyone should be represented the same way in the meeting - and the more you can read someone's facial expressions - by having one camera per person, including attendees in a traditional office - the better.
If we have a need for the remote equivalent of a whiteboard or wall - i.e. a synchronous multiuser visual and tactile collaboration surface - we’ll use either Trello or MURAL for that.
JIM: Detractors of remote collaboration might say remote design sprints are impossible. (I've heard that before.) Can you tell us more about how you and your team pull off remote design sprints? What advice do you have for someone new about to try one?
CHRIS: We’ve learned remote sprints are both possible and valuable. The conventional way of doing sprints is a large block of time where people are physically collaborating, sketching, doing things with stickies and generally physically working together intensively. We occasionally fly people to ‘off-sites’ to do these.
But we need to do this much more regularly than logistics permit. So we’ve been pioneering remote design sprints, a hard test for remote design.
A good design sprint is more than just problem solving. It brings a team together and creates positive energy and momentum. For remote sprints, we need to think deeply about the dynamics that happen in person and innovate to generate them remotely.
We want to pull off that psychologically safe, supportive, focused, creative atmosphere. And also that sense of a special group time away from the usual daily routine and distractions.
JIM: Sprints require a lot of focused attention. How do you maintain engagement with remote teams?
CHRIS: Sprints are demanding. They take full days of focus. Usually you’d book a space away from your office to remove the temptation to step away. For remote sprints, we ask participants to let their teams know that they’re effectively ‘out of office’.
An important part of any design sprint is creating a common room where your team will meet and work, often surrounded by the artefacts generated while exploring the problem. We use Zoom for this, both for it’s rock solid performance and the gallery view a.k.a. ‘Brady Bunch Mode’.
We’re basically on video chat for multiple days, where people stay in the call even if they step away to grab a cup of coffee. We've found that after sprints, teams miss seeing each other for long stretches like that.
We do remote group ‘warm ups’ each morning. We have to get a bit more creative with these but we’ve found some great ones that get us into a creative, collaborative headspace despite not being physically together.
JIM: Any advice you’d give teams trying to do a remote sprint?
CHRIS: Sure. We have a ritual like set of rules for remote sprints:
JIM: Do you have to modify the method in any way when doing a remote sprint?
CHRIS: In terms of the work sessions, we pretty much stick to many of the typical exercises and formats of design sprints like the ones popularized at IDEO or Google Ventures.
Where there’s a need for sticky notes or whiteboard type stuff we’ll use MURAL. We’ve also invented a couple of mural-based exercises for things like voting in a nuanced way at the ‘converge’ stage, or collectively placing ‘How Might We’ stickies on a huge customer journey diagram.
In collocated sprints you sketch with pencil on paper. For remote we encourage people to use the medium they’re most comfortable with.
However, because we’re sharing digitally in MURAL, we can also step up the fidelity designing in Balsamiq or even Sketch. The extra fidelity and ease of sharing makes it easier for people to get their ideas across in a way that rapid sketches by people who don’t sketch a lot often don’t.
And the experience of a group following the exact point of a view of a presenter as they zoom around a mural explaining work is a truly powerful way to design collaboratively that’s only possible immersed in collaboration software.
Higher resolution assets are also easier for non-participants to follow along with asynchronously, after the fact. We’ve come to prefer these aspects over collocated sprints.
We also use Figma - think Sketch meets the sense of presence of Google Docs - to collaboratively make rapid prototypes. It’s great for stepping up fidelity a bit or trying out many different design ideas quickly in a group.
One subtle but important part of a design sprint is the spontaneous conversations that happen outside of structured time. During a sprint, the team is so deeply focused on a problem that they naturally discuss what they’ve been ruminating over at lunch and in breaks. Some of the best ideas come from those casual conversations.
We wanted to create space for this kind of spontaneity remotely, so we started having lunch together on video. Everyone eats together and just chats about whatever’s on their minds. This became a favorite ritual. This kind of breakout inspiration also happens well in smaller chat and video rooms.
JIM: Good advice. Do you feel the quality of work your team delivers is better, worse or the same compared to having them co-located? Why?
CHRIS: Things have been going well for Trello, and we’ve been getting good design outcomes. There’s lots of variables that go into shipping great design though, and collocated versus remote is just one piece in the puzzle.
Overall I’d say the work is better because of remote. Mostly because we’re able to attract and retain very high calibre design talent since we’re not limited to a small, already ‘intensively fished’ geographic area, and we can offer talented people the opportunity to work remote.
Plus there’s a lot of research out there that says remote workers are happier, and if that’s true, presumably that shows up in the work. Maybe end users can even sense that on some level? We expect to feel the creators coming through in the media we consume, or the products we buy, so why not software to some extent?
To do their best work, makers need to get into - and stay in - a flow state. That takes time and the right conditions. Attention is elusive and fragile. It’s often easier in a home office than an open plan ‘bullpen’. We find remote design team members tend to produce more high quality work in less time partly because they are simply being less social. There’s no one around.
That can be a problematic too though if we’re not careful. The insights shared by Google around their Project Aristotle data show it’s actually team members’ empathy scores that predict team success more than leadership, collective intelligence, skills, experience or proximity. If a team doesn’t connect with or care about each other they aren’t going to win (whether they're three feet or 3000 miles apart).
JIM: What about the lack of interpersonal communication. How to you make up for that with remote teams?
CHRIS: We have to overcompensate for that relative lack of social time which slows the usual process of developing rapport, camaraderie and empathy. Trello invests in that cultural piece. We have a bunch of rituals around that, Trello-wide, on cross-disciplinary teams and on the design team.
Humans are brilliantly optimized for in-person communication, and so much nonverbal signal gets lost without mutual physical presence. Introversion/extraversion is another factor, and remote work doesn’t suit everyone. I’m not sure there’s one perfect model.
Personally, my most satisfying weekly work configuration has been 3 days mostly ‘deep work’ remote, two days local in person.
On the other hand, a valuable side-effect of being remote we’ve noticed is, as designers we become especially attuned to the tools we use, including our own. Perhaps it’s a bit like how when people lose one of their senses, the remaining senses become super developed?
When you're 100% remote, your tools are effectively your office. You experience collaboration tools as proxies for a disappearing, or digitising workplace.
Many of Trello’s members are also in the midst of these significant transitions at work, including distributed or remote teamwork. By dogfooding Trello remotely we’re living some of the future of work right now. It makes us constantly inspired on how to improve Trello because we’re ‘scratching our own itch’.
The larger context for our design work is this new era where workers expect consumer levels of ease of adoptability and usability from work software. And it's those little big details we’re attuned to that can make all the difference.
JIM: Great thoughts! Thanks, Chris.