Let's Play a Game
At the beginning of the presentation, Rachel and I led the audience in an interactive game of “Name That Component,” which is basically a web pattern version of the telephone game (technically it’s a web-related version of Telestrations).
To play, everyone gets a game booklet with a different site component inside. The components are nothing special — just common landing page pieces with slightly ambiguous purposes. When the game starts, participants have 30 seconds to give their component a name, then pass their book to a neighbor. The neighbor then has another 30 second round to draw a component based on that name — without ever seeing the original — then pass their book again. This 30 second name/draw process continues for six rounds or until total chaos breaks out.
The game is a little silly, but it really demonstrates how the simple act of giving something a name can send communication quickly off the rails.
Abstract/Summary
“What’s in a name? That which we call a rose
By any other name would smell as sweet.”
Thanks, Shakespeare. That’s a great sentiment, but when we’re talking about websites, it gets a little complicated.
Naming components isn’t just a problem for the developers who create them; it’s a cross-disciplinary challenge. From variations in how something can display to patterns that reflect design behaviors, names serve different purposes for everyone, whether you’re a user experience architect, designer, developer, content creator, or the end-user. And what’s really challenging is that everyone is right, in their own context.
Each discipline (usually) has some sort of logic to support what they want to call things. Developers often want to name components by structure, not by the content they might contain, in order to keep the code flexible. Designers want to name by color or style, even though what’s technically a single component might just be skinned with multiple display options. And if the component names don’t reflect the content they’ll ultimately be used for, content creators will have a hard time choosing the right one for the job (and might come after you with pitchforks).
In each phase of design, the qualities and behaviors of a component must be interpreted by the next person in line, from wireframe to design to development to content strategy to client. Without clear communication, it ends up a protracted game of telephone, except at the end no one’s laughing. A simple “circle-headshot” in one use case devolves into “circle-headshot-full-width-inset-with-green-link-style” in another, and things get complicated quickly, leading to widespread panic and confusion.
We’ve spent way too much time debating this subject with our (very smart, very passionate) teammates. And while we’ve come to realize there’s no one-size-fits-all solution, we’d like to save you a few of the gray hairs we’ve earned along the way. We’ll share hilarious missteps we wish we could take back — along with some examples of what’s worked well.
Takeaways
- Understand the needs of each discipline and what the consequences of different naming conventions could mean for the project.
- Learn the importance of documentation and alignment starting from the very first sketch.
- Hear our best recommendations based on years of experience, arguments, and sometimes-heated debates.
