Seeing the elephant

How a centuries-old parable improved our product design process at MailChimp

Recently I was walking through the office at MailChimp when our CEO, Ben Chestnut, approached me. “How’s it going, Todd?”, he asked. “Design team doing well? Working on new things?” I responded by offering a progress report on all the various projects the product design team was currently working on.

“Sounds good,” he said. “But remember…make sure everyone can see the elephant.”

I responded with a blank stare.

Elephant? What elephant? We may have a fondness for primates and certain household animals, but elephants were completely new. After some quick Google searching, I found what he was referring to.

Ben’s “elephant” was an allusion to a centuries-old parable you can find in multiple cultures and religions. You may have heard a version of the story at some point in your life, but here’s the general idea.

An elephant is surrounded by a group of curious blind people. Each person is touching a single body part — trunk, tail, ears, and so on.

The group gets together thereafter, compares notes, and are shocked by what they find. Everyone has a different impression of the elephant. The descriptions offered by each participant is completely different. As a group they’re incapable of describing the elephant because no one is able to see every part.

To put this story in terms of software, the elephant is the product. Each blind person is an individual or team responsible for a particular part of the product (e.g., accounts, billing, on-boarding, integrations, etc). The more complex the product, the bigger the elephant, the more magnified the problem.

Spreading the elephant

Following my impromptu interaction with Ben in the hallway, I couldn’t escape the elephant. I kept thinking about it, rehashing its cautionary tale, and marveling at how perfectly it captured our quest for cross-team design consistency and awareness.

I shared the elephant story with all the designers on my team. The story also spread to other departments inside MailChimp. Within a couple of weeks I found myself in meetings hearing other people talking about “the elephant”.

The elephant story “stuck” — as the Heath brothers would say — because it took an abstract idea and wrapped it with a clever, visual narrative.

Seeing the elephant

Getting back to the original question, what prompted the elephant story in the first place? My answer to our CEO’s question was focused on deliverables, deadlines and roadmap Gantt charts. All fine and good, but in his world those were all givens. For him the greater challenge had less to do with detail and more to do with our goals as a business and the overarching user experience of our product.

Meaning, if everyone on the design team is working on a particular part of the product, how do we avoid working in isolation? How do we ensure our product has a consistent, clear experience through and through? How do we ensure one designer isn’t working on something that conflicts with the work of another? How do we encourage designers normally focused on detail to think more broadly to help identify opportunities and generate new ideas?

The product design team at MailChimp continues to explore solutions, but here are a few things we’ve been trying.

1. Draw the elephant — As obvious as it sounds, before anyone can describe part of the elephant they have to have a mental picture of the elephant itself. What is our overarching business strategy for the future? How do we intend to grow and expand our customer base? How does our product compare competitively, and how do we intend to expand the product to meet customer needs? Where do we see ourselves in two years, or more? Who is responsible for answering these questions is less important than ensuring everyone is able to answer them. Nobody is expected to keep every moving part in their brain, but everyone should at least be able to describe the elephant’s outline.
2. Encourage openness and visibility —For many designers, submitting incomplete work to a public forum can be painful. It’s incredibly easy (and I speak from experience) for a designer to confuse the value of their creative output with how they are valued as an individual. Like any creative field, design is messy, frustrating, and open for personal interpretation, so designers tend to keep work under wraps until their confidence is sufficiently strong to withstand blowback. That’s okay in late-stage design phases when details matter, but too much fidelity too early can be detrimental to ideation and exploration. Create open environments and opportunities for large and small collaborations. Ideas generated for one area of a product may solve a design issue in another.
3. Fully utilize prototyping and communication tools —Design teams today are drowning in tools. It’s an embarrassment of riches. The challenge facing most teams today is figuring out which tool or combination of tools allows everyone to see and discuss the elephant and all its requisite parts. At MailChimp we’ve been trying a variety of tools, and thus far have been relying on Invision prototypes and boards, as well as communication channels like HipChat and Slack to notify everyone on the team of changes, updates and comments. These spaces and channels offer persistent cross-team collaboration while also providing senior leaders and managers visibility into our process.
4. Schedule repeat design critiques and stand-ups — Digital tools and devices are helpful, but nothing beats personal interaction. Schedule as much time as possible (without it becoming disruptive) for people to share work and be exposed to what’s happening outside their immediate purview. Try to find the right balance of scheduled team meet-ups in addition to smaller collaborative sessions that benefit from fewer participants.
5. Watch for patterns, overlaps and dependencies — When design ideas are shared, encourage everyone to follow the invisible breadcrumbs lurking underneath. Does this idea overlap with another? How will these modifications affect external dependencies? What will need to be edited, added or removed in order to support this new approach? Chasing rabbit holes to their termination point may be time consuming, but are absolutely necessary to ensure what’s good for one section of a product doesn’t harm another. If someone spots a design change that affects their work, encourage them to speak up, ask questions, and work together to find a solution.
6. Involve engineering early and often — Pretty prototypes and mockups aren’t worth a damn without solid back-end engineering. Everything may as well be vapor. At MailChimp we’ve structured our product teams in such a way so designers collaborate amongst themselves and with engineers to inform and improve the design process before a single line of code is written. This ensures design ideas are not only technically feasible, but scalable. By the time a design is marked “complete” the engineering team has been involved every step of the way.
7. Keep an eye on the horizon — It’s easy to get caught up in what’s happening in the day-to-day slog. Throughout the ideation process, encourage yourself and those around you to question whether the work you’re creating is contributing towards the product’s broader goals and initiatives. Ask yourself how much functionality is truly necessary — from a design, user experience, and engineering perspective — to meet your short term objective without ignoring your more complex, long term product goals.

Summary

By now the elephant and I are great friends. Not a day goes by without someone (including me) bringing him into a conversation. The real takeaway from this story — for me anyway — is how powerful goals can become when they’re wrapped with some kind of mental hook. Like an advertising jingle you can’t drop, or a catchy chorus that keeps looping in your brain, the elephant story stuck and brought everyone together.