Apples to oranges: Why designers should care about words at work
Speaking a common language across disciplines is essential to great product development.
Product design as a field is young enough that what it means to be a designer — and what we even call the job — changes from year to year. We debate whether or not designers should code, whether or not they should be heavily into visual details or lean towards systems thinking. But as more companies start to value design and involve us in all stages of the product development process, one thing is abundantly clear: Product designers need to be able to use words effectively.
I’m not saying we need to give talks or speak up in meetings (although we absolutely should, especially women and POC). I’m also not advocating for designers to write our own product copy (although being able to is a valuable skill). I’d argue that we need to embrace the power of spoken and written words to communicate within our teams and with our professional partners.
Why? Because we’re not isolated artists creating work in the corner. We’re part of a system of people — our fellow designers, engineers, product managers, and business owners. Understanding their languages and possessing full mastery of our own will allow us to speak clearly, listen effectively, and translate fluently in our daily work lives. In today’s cross-disciplinary industry, communicating with these players with clarity, empathy, and purpose is the only way we can get our ideas out into the wild and advocate for our point of view within an organization.
I say potato, you say subheading
The designer-engineer relationship can feel like a beautiful dance or a frustrating game of telephone. Very often it’s language that makes the difference.
Like many others in the industry, at NerdWallet we’re working towards a design system — a living library of structured templates and UI elements that engineering and design can contribute to and benefit from. This means both teams working together to improve each other’s process and technology. But before we can improve anything, we have to make sure we’re talking about the same thing, using the same words. For instance, many of our designers just learned that our engineers work with rems rather than pixels. Rems are size measurements based on a website’s body text size. Our body text is 16px, which is our base unit. So that means if an engineer wants to create 32px text, they’ll specify 2rem; for 20px text, it’ll be 1.25rem. In the past when a designer has proudly spec’ed out a pixel-perfect comp, the engineer has then had to go through it all and convert from our language to theirs. Our engineers were already bilingual, but our designers were not (and some didn’t even realize there was another language being spoken).
But how do you explain the value of “rems” to someone who hasn’t worked with them, and who have never even heard the term? That was the task of one our designers at NerdWallet, Zane. He had to convince a wary group of designers that rems may be the right language when we’re creating responsive web layouts: Whereas pixels represent a static design, rems communicate a system of relationships between elements that can translate across browser widths and contexts. Designers already think in relationships, but pixels aren’t as useful as rems for supporting them. To convey that message, Zane had to have a deftness with words, and a deep understanding of the team’s goals — but also real empathy for why pixels have been important to designers.
Another great example of why words matter arose from our new text styles. NerdWallet has a diverse set of products and content, which means that text styles need to do different jobs in different contexts: Articles have more heading levels and often need larger headings, whereas calculators have fewer levels and need smaller headings. To optimize for accessibility and SEO, our engineers are always careful to use HTML tags, like <h1> or <h2>, to semantically define our HTML.
In our style guide, we listed out our font sizes as Heading 1, Heading 2, Heading 3, Heading 4, Heading 5, Text, and Small Text. But when we were talking with engineers about implementation, we got caught in a terrible game of Who’s on First. “For this page,” we said, “the <h1> is Heading 2, and the <h2> is Heading 4.” “Wait, <h1> is H2?” they asked. “Yes, but not always, just for this page.” And around and around we’d go. We decided on a simple and practical solution: We removed the word “heading” from our type styles and instead used Text 1, 2, and so on. Now, the word “heading” only has one definition for our team and in our documentation.
As a designer, I want clear user stories
At NerdWallet and many other places, designers want to be strategic partners with product management, not just hands that move the pixels (or rems!) around. We bring visual skills to the table, but being good partners also means working with words to help craft the product narrative from inception to execution.
User stories are an inspiring way to start thinking about design work. When done well, they help designers start from real problems rather than solutions, which is one of our company values at NerdWallet. They can also be a concise way to translate research learnings into tangible projects. Usually, product managers are responsible for ushering user stories into being. But business goals are the native tongue of great PMs, and it can sometimes be challenging to take off the “ship it fast” hat and identify a root user need. As a result, we’ve come across some stories that skip the problem and jump right into a fix.
To take one example we’ve seen, “As a user, I want to see a dropdown with options” defines the solution, rather than clarifies a user need. It’s our responsibility as designers (and in our best interest) to take the time to explain why this story isn’t useful, illuminating the difference between a prescribed feature and a defined problem, and articulating how user stories fit into our design process — and even into engineering QA work. Successful conversations like these can lead to stronger relationships, cleaner process, and a precedent of honesty and collaboration on the team.
It’s also important to make sure we’re on the same semantic page with PMs when it comes to scoping projects and mapping deliverables. The distinction between words like “feature”, “solution,” and “concept” can mean the difference between a well-oiled team shipping on time and a grumpy group woefully behind schedule. Even if the industry doesn’t have clear, unified definitions of these terms (or others like “wireframe,” “prototype,” the list goes on), the PMs, designers, and engineers working together should take the time to ensure that they do. “Let’s meet to talk about language,” may strike some as shaving the yak, but a simple conversation can save an unfathomable amount of time and stress. It’s the product development equivalent of “Measure twice, cut once.”
On our design team, we’re developing a system of definitions for project types and phases. The goal is to set up a shared language with our working partners to avoid the missed connections we’ve experienced in the past. For example, I was on a team where I could never pin down the design QA window. “We shipped it!” the engineer proclaimed in standup, but I hadn’t had a chance to check the design on our staging site yet. If we had established our shared definitions by then, everyone on the project would have understood that the QA phase includes design QA, not just technical QA and bug fixes — and we could have planned our time and attention accordingly. A shared glossary can help properly set expectations and timelines for a team and let everyone get down to the job of making a great product.
The squeaky wheel gets to launch features
As designers, we understand the power of the visual. It’s why we do what we do. But demonstrating a mastery of language can help us take our influence to the next level. We should always be precise with words to get our message across, and we should strive to form a common language with our professional partners so that we can work together in lockstep.
These skills apply to any context: asking the right questions of company leaders, advocating for a point of view in a design review, helping a product manager with a planning deck, even discussing how a project went in a retrospective.
Below I’ve included a list of questions we as designers can ask about language when we’re working with partners. It may not be our natural first step, but the more we’re able to pause and choose our words carefully, the more effectively we can advocate for our work, our ideas, and our field, today and for years to come.
Questions to ask when working with a partner:
- Do we have a shared understanding of what this word means within our context?
- Does this word mean something other than what I’m using it for in the language of my professional partner?
- Am I using any terms that are specific to the design community? Is there a more inclusive word I could use instead?
- Does the word we’re using have negative or misleading connotations for one of my partners? Is there a word that is neutral or positively-associated for the group?
- Am I using a term as shorthand for a series of other concepts? If so, does my partner share that shorthand?
Many thanks to the generous eyes of Niraj Patil, Kimra McPherson, Devan Goldstein, Zane Riley, Nat Bolton, Jessica Bronson, Jason Lim, Parsha Pourkhomami, and the entire NerdWallet design team.
