- May 8, 2014
’Tis but thy name that is my (fr)enemy
- @rumorehigh
- Strategy Director
“What’s in a name? that which we call a rose / By any other name would smell as sweet; / So Romeo would, were he not Romeo call’d” (Shakespeare, Romeo & Juliet, 2.2).
In the world of project management, naming conventions are often the source of miscommunication. You have to call your work something, but if you assume everyone interprets a name the way you intended, you’re likely to stub your toe during the course of the project. As managers, minimizing risk and setting expectations is an everyday task, yet something as simple as a name or label can fly under our radar. We live and breathe our work, and we are passionate about it. It’s a good practice to never assume labels are understood out of the gate. Here’s a few tactics to help you make naming conventions work for you.
Account for internal and external interpretations
Consider this: A brief and fleeting twitter survey had Person A defining a template as a “page layout that is intended to be reused by changing only its content.” Person B called it a “damn annoying software thingie the CMS won’t let me restyle natively.”
If I walked over to the gaggle of designers having lunch and asked, “Visual design is the same as graphic design, right?” several talented individuals would have strong opinions. To the client on the project, (without supporting context from your design team) there’s a good chance they are one and the same.
The term “wireframe” also ignites spirited debate within our industry, so what can we expect from our customers? Consider the stakeholder who is expecting “wireframe” to mean static drawings. Another stakeholder thinks a “wireframe” is going to give her responsive markup she can hand to her development team to use for a build. Deliver anything less than what either expected and you’re sure to hear the record scratch loud and clear from your client.
Nobody wants to have those reactive conversations. It can shift the whole well-being of your project. It’s worth giving it your attention upfront and making sure you tell the story behind any name early and often. Be sure everyone on the project team agrees on a name and what it means.
Lead the way
We have to start somewhere. In many cases, we’re forced to bear the burden of choosing the first label. Ideally, clients are using terms your team already embraces, and you’re all on the same page. Choose a term your team can get behind. This way, your whole team can contribute to the story you want to tell. While there’s merit in letting the client choose what’s best for them, you then have to cross your fingers and hope they can tell the story behind the name as well as you could. It’s best to have the creators of the work give it its name and to document it well, and often.
Make sure stakeholders all sing the same song
As with any project, one of the first tasks is to identify the stakeholders involved. Since you are representing the work being delivered, it only makes sense for you to take ownership and ensure each and every stakeholder perceives the work as intended. Your primary client contact might understand design deliverables as “design in the browser.” Yet, the person who signed the agreement and writes the checks is expecting Photoshop files. If you get to the delivery deadline and these folks are misaligned, it’s already too late, and an otherwise-awesome client relationship will suddenly hit a sour note.
Unfortunately, we can’t always trust that everyone on the client side is on the same page. The safer bet is to take measures to facilitate clear lines of communication whenever, and wherever, you can. Make sure the right people attend the meetings and sign off on documents that provide context around the naming conventions you’re introducing.
Provide context
For each deliverable, describe in excessive detail what it is you’ll be handing over as part of your project.
It’s important to consider how people will use what you are describing. A developer’s list of what she wants from a prototype could be wildly different from what a marketing director needs it to do. Make sure you speak to how your prototype will fulfill your client’s particular needs, and when that will happen in the course of the project. It’s just as important to clarify what a prototype won’t do (i.e. “This prototype should not be considered production-ready code.”).
Use that label throughout the project
The chosen naming conventions should be used throughout the project beginning in the initial agreement right on through to the post-mortem meeting. It should be spelled out in your project plan and be accompanied by context wherever possible. If you use different language internally, make sure it never bubbles to the service, as it poses a communications risk.
Whenever you can, be as specific as possible. There are plenty of repeat offenders that have likely burned many of you. Consider these culprits:
- “Styles” vs “CSS”
- “Front-end code” vs “Pattern Library”
- “Prototype” vs. “Wireframes”
If you find yourself thinking it best to create a glossary of any kind, STOP. You’re doing it wrong.
Clarifying the work that’s hiding under a label is key to ensuring your solution meets expectations. It takes a lot of digging, a series of conversations, and you might stub your toe here and there. It’s worth making frenemies with labels. In the end, we all just want to celebrate a job well done, no matter what name it bears.