Part 1: What is Design Language?by Gray McCord
Let’s get this out of the way right now: I am an engineer. I’m also going to admit that for many years, my understanding and appreciation of the value of Industrial Design and Design Language was minimal.
My first experience with designers was with a couple of guys in leather pants speaking to me using terms that I did not understand, much less know how to apply to my products. They were very different from me in terms of background and skill. I had no training or experience that could help me evaluate what they were telling me. Naturally I immediately rejected their input. Over the years, however, I have come to understand the value of a well-crafted and implemented Design Language to the quality, profitability, user experience, and R&D of products.
As the technology leader for a Product Development firm, I frequently work with client engineering teams that have difficulty with “design,” Designers, and Design Language. Many confuse these with the engineering efforts necessary to create products. After all, we’re called “Design Engineers” for a reason. It also seems that the more complex and mission-critical the products these teams develop, the more likely it is that they will resist the Design Language concept. This seems to be true even if the company leadership embraces Design Language.
As an executive with an appreciation for the value of design and design language, you will likely have to face an engineering team that resists it. How should you deal with this situation? My answer is in two parts. First, you must educate your team on exactly what a design language is and is not. Get rid of the misconceptions. Second, explain the value of Design Language to your engineers in terms they understand, with a focus on how it can help them. That is all. Of course, while this is simple in concept, it is challenging in practice.
Defining Design Language
What Design Language is not
Before we go any further, let’s look at what the common misconceptions about Design Language (and design) are from the engineer’s perspective. Here are some common statements I hear:
- “You’re just making it look pretty. Our customers don’t care.”
- “This just makes my product more expensive and doesn’t add value.”
- “This is just more work for me.”
- And of course words are not needed for this classic (no offense to pigs):
The fallacy that leads to statements like this is the idea that Design Language is nothing more than a cosmetic addition to a product to make it look pretty. Look your engineers in the eye and say “No. That is not Design Language!” Yes, a product that is created using Design Language will look good. However, "looking good" is merely the by-product of Design Language’s carefully considered approach to the overall usability and functionality of the product. Repeat as necessary. Be consistent and persistent!
Design Language by Example
I’ll give you a written definition in a moment, but let’s first look at a few examples of companies that implement well-conceived Design Languages.
What do the three companies represented above and their products have in common? Well, nothing really. Except I’m going to bet that if you look at any of the products these companies make next to their competition, you will likely be able to pick them out quickly. John Deere green and yellow. Apple’s clean appearance.The BMW front grille. Why is it that these brands stand out, and why do most of us respond positively to them? Yes, they all make very high quality products for their markets, but their competition in many cases is just as good or better. That isn’t it. They are generally more expensive than much of their competition; yet many lower cost products perform just as well. What makes these products instantly recognizable and “iconic” is simple. Design Language.
Here’s a definition for Design Language:
- Communication of a brand promise through visual and experiential elements of a product or family of products expressed as a set of guidelines for the industrial design of future products that balance business objectives and human needs with engineering requirements.
That is certainly a mouthful, so let’s break it down a bit. Design Language speaks to what your company desires to communicate to your users, influencers and other stakeholders about what your company is all about. This is called the “brand promise”. Generally speaking, if you want your customers to think about you in a certain way, it is the experience they have with your products that will determine if they received the desired message correctly.
The visual aspects of your product, both hardware and software, hint at what customers can expect, which draws them in. The experience they have with the product validates those expectations. When these two things reinforce each other in a way that is consistent with your desired brand promise, you have the maximum opportunity for success. If either of these dimensions contradicts the brand promise, or each other, the customer is likely to have an unexpected experience. This can result in a negative response to your product. Design Language is the framework that allows you to prevent these disconnects by systematically providing for positive reinforcement between the brand promise, product expectations and product experience. And yes, engineers play a key role in this. While the Design Language will specify how users interact with the product, it is the engineering team that must create the device that consistently meets those requirements!
Design Language is not something created for and applied to just a single product. It is a set of guidelines that a skilled Industrial Designer uses to ensure that multiple, future products provide the consistent brand experience you want to provide to your customers. It is not a set of prescriptive requirements that can or should be implemented by engineers without help. It is a set of guidelines that are interpreted for each new product by an Industrial Designer within the context of your overall business and technical priorities. The best results are realized when Industrial Designers and Engineers team up to properly prioritize all of your product requirements, including Design Language, within the context of your overall business constraints. This is the product development process at work.
You are now armed with the first component you need to allow you to educate your engineering team about the value and purpose of Design Language. You should now be able to have a conversation with them that will lead to the “Oh. I get it.” moment. However, this is the easy part. While your engineers should now understand what Design Language is, they probably still won’t understand what the benefits are to them. In part 2 of this series, I will provide you with examples of how Design Language not only benefits your customers, but your engineers as well. Until next time…..