On communicating design
The wireframes looked good. But the story wasn’t there.
I stood there looking at the flow diagrams, the mockups, the outline numbers and details and boxes and arrows, and it was hard to follow.
“Can you tell me the story?” I asked the designer.
The designer rattled off the story, pointing out the boxes and arrows and detailed drawings and the outline numbers that cross-referenced to the flow diagram, running around between the mockups stuck to the wall.
Yes, the story made sense. The user flow felt right. The research backed it all up.
But.
I couldn’t see the story. Instead, I saw sheets of paper stuck to a wall.
So I called over a developer, one who’d be working on making the design into a reality.
“Can you tell me the story?” I asked her.
She looked. Stared. Squinted. Looked at the flow diagram, pointed to some things, and said, “Well, I think….”
She trailed off.
“I think this happens. Then this happens. But maybe not… shouldn’t that happen before this? Wait, why are these outline numbers here? What’s this diagram for? Do these wireframes run across the wall or down them?”
She couldn’t tell the story. Her version was as jumbled as those pieces of paper stuck to the wall seemed to me.
“I’m not out to embarrass you,” I told the designer later. “But if the person who is going to build your design can’t tell you what you’re asking them to do, then there’s a communication problem you need to solve.”
My own designer’s arrogance
Early in my transition from web generalist to UX designer, I switched from designing in HTML to creating wireframes. With wireframes you can turn out design iterations quickly, providing “just enough” information to explain the idea you’re trying to communicate.
I worked for a company where the engineering team held great power, so I was in a symbiotic relationship with UI developers in pair programming and design processes. I was sending out designs and markup and getting back running code and feedback. Developers could just about finish my sentences. They knew exactly what I was saying on every wireframe.
But every new developer we hired had to adapt to me and my language. And that became increasingly time-consuming for me, increasingly confusing for them. One day, one of the devs went rogue and didn’t follow my wireframes and my stories. They didn’t think I was delivering the system they thought the user needed, so they stopped listening.
Looking back, I can see that “designer’s arrogance” got in the way of my empathy. I was so headstrong about creating right design for users that I had forgotten to communicate the design to the people who most needed to understand it — developers and product owners — in a way that they could understand why.
The UX of our UX
“Who is the user? What are they trying to accomplish? Why are they doing it?” We repeat those questions, over and over, when presented with the latest design challenge. The who, what, and why help us figure out the how.
But once we have the how, we struggle with communicating the how to the users who will execute on it.
We forget to UX our own UX.
Who is your design’s consumer? What is their goal? Why are they doing it? And how are you going to help them fulfill that goal?
Every deliverable should tell the story. But more than that, it should tell the story in a way that the deliverable’s consumer — whether a developer, a product manager, a content strategist, or an executive — can understand the story and their part in fulfilling the story.
For a developer, clarity on how to execute on the design. For a product manager, the ability to trace the path from the problem statement through the requirements and user stories to the design solution. For a content strategist, an understanding of how the design informs the content needs — and how the content informs the design needs. For executives, the business value of design.
The need for clarity in communication is a crucial first lesson not just for the newly minted designer, but also for the new developer, too. Undocumented and underdocumented code litters the codebases of a universe of sites and applications. I’ve watched dev teams fight with product owners over the value of a piece of technical debt that needs paying down — because the dev team can never explain exactly why the organization should pay it down, much less why the check needs to be cut now.
Design is communication. Code is amplifying that design so the world can see and hear and interact with it. Know your audience. Know their language. Communicate, communicate, communicate.
Originally published at the-pastry-box-project.net.
