“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.
- 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