Hang Up and Talk
Leaving a visual telephone approach to product design and development, and embracing a balanced team.
If you’ve ever played visual telephone, you’ll know that it’s a super fun party game that starts with a sentence, alternates drawing the sentence and rewriting it, and ends with a sentence that is, more often than not, hilariously different from the original. There is a lot of chatter, laughter, and bonding that occurs and in the end everyone is happy (and not just from the gin). If you’ve never played, you should, and I Googled you a pretty good write up.
Story time
Back in the day, I used to work in a cubicle. A cuberhood, if you will, because everyone was in cubes. I would quite literally receive and give work by throwing it from my cube, over the wall, and into someone else’s. (Not always literally, sometimes they were too far away or the printer was broken. In those cases, it would get emailed.)
Besides redecorating my cube walls to keep from drowning in a sea of taupe burlap, I would spend a lot time deciphering the cryptic and red-tapey requirements document that was given to me and translating it into high fidelity, pixel-perfect mockups. They were precious pages, all design was done up front, and I had even gone so far as to sprinkle in nice-to-have features to impress. I would get some signatures, and then pass them off to the developers. After some pats on the back (from myself mostly, thanks to decent arm flexibility, but also my fellow cuberhood designers), then together we would set off for the happiest of hours. Fast forward a month or so, and those precious pixels were ready to be pushed.
Usually this resulted in a round of WTFs.
The stakeholders would be like: WTF, where are the features I asked for? That’s not what I meant when I said X. Why is this taking so long?
Previously, the developers would be like: WTF, did the designers really put a bevel on that tab? WTF color is that? How the hell do we build that custom-looking modal? Eh, this library is close enough. WTF, where did this page come from? WTF, there is no way we can do all of this by the deadline. WTF do I do if there are errors?
The designers would be like: WTF, this doesn’t look like my mocks. WTF happened to that drop shadow? Where did that teal color come from? WTF happened to that entire required feature? Did the devs spend all their time on that nice-to-have thing?! Where are the borders for the alert messages? WTF…is that error message just code? It’s not even human readable!
Over time, I started seeing similarities between visual telephone and working in working in this siloed way. Much like the index cards, we each handed our work off to the next person and called our part “done”. What we started out with was not what we ended up with. The carousel turned into a seesaw in stable.
Unlike visual telephone which was a fun and bonding experience, this way of working was stressful and built contention between each group. There were long delays in feedback. The product check-ins were scattered and often got derailed. There was a fundamental lack of understanding and empathy for each other. It was “us vs. them.” Even if the release was successful, someone was often surprised at the result. It wasn’t very fun and no one was very happy.
Working together shouldn’t be this hard.
Enter the balanced team
A balanced team literally breaks down those silos, and moves each discipline closer together so it’s more of a Venn diagram of overlaps than separate groups. At Pivotal Labs, we always work in an open space with a balanced team of designers, developers, and product managers all sitting together.
That might sound pretty fuzzy, what does a balanced team really mean? It means that collaboration and conversation are emphasized and valued over specifications and sign offs. It means we are constantly working together.
Design is not just a department, it’s a mindset. -Klaus Kaasgaard
A designer on a balanced team is the design leader, not the design dictator. It’s no longer the designer’s job to be a bottleneck, she is now a design enabler. Whether the designer likes it or not, and whether her teammates know it or not, anyone working on the product is making design decisions. Using a library over building something custom — design decision. Prioritizing a date range picker over error messages — design decision. Guessing on which grey was supposed to be used — design decision. It’s the designer’s job to help them make well informed ones.
While it’s true that that designer is responsible for the design: the layouts, interactions, assets, etc, he will also be responsible for constantly communicating the design process and progress. He will explain the why’s, present research, and facilitate team workshops so that the rest of the team understands what design is and how and why things were designed the way they were.
This will be true for the other disciplines as well. Developers will help designers and product managers gain technical literacy and understand the complexities of their design decisions. Product managers will help designers and developers prioritize and understand the needs and goals of stakeholders, users, and other dependent teams.
The teams start doing everything together: researching, story writing, sketching, even developing. Each member is still the expert and leader of their discipline, but there is mutual understanding and support for each other and what they do.
Once a team starts working this way amazing things happen. Trust and respect is built. Communication lines begin to open. Everyone is engaged and shares the same vision. Now developers will start reaching out and asking questions. Designers will share the design process and invite the others to participate. Product Managers will work with developers and designers to create user stories that continuously provide value.
There are no more surprises in the production environment. Every feature gets a conversation, and every story gets accepted before it’s shipped. Now, if it’s not a carousel at the end, it’s because the whole team decided it shouldn’t be.
A balanced team approach isn’t all puppies and Firefly marathons, though. It can be really really uncomfortable for each discipline to share their process. The constraints that the other parts of the team will introduce can feel confining at first. Building a vocabulary that everyone can understand will be difficult. Stretching comfort zones to accommodate the needs of another discipline will feel like a childhood growing pain. Even sharing physical space can be hard.
But once the visual telephone games end, once everyone just hangs up and starts talking, the cube walls will fall, a mutual understanding will grow, and there will be room for new freedoms to build the right thing.
And this time, together.
Jenn is a product designer @pivotallabs in NYC who owns way too many Sharpies and drinks way too many Schweppes.
