Hi, I am conducting a research about communication between designers and engineers.
How do you associate with engineer?
Hi, I am conducting a research about communication between designers and engineers.
As an equal partner with a different knowledge set, approach to problem solving, and priorities but the same (or similar) ultimate goal of creating a quality product.
Be interested in them.
Chris Bangle talks a bit about this in a recent interview: http://www.fuelyourproductdesign.com/chris-bangle-on-being-a-better-design-leader/
Basically that you guys have to understand each other and that you two have similar goals. Have a dialogue about how you can get to that ultimate goal, rather than who wins or loses.
I am constantly talking to myself. It only gets weird when I reply.
Express and demonstrate genuine empathy for the issues that concern them and how what you’re doing affects their work. Conversely, share with them the issues that you’re concerned with and how what they do affects your work. Learn to express your ideas using their language and terminology. Be willing to compromise, negotiate and collaborate. Share your successes–you either succeed or fail together.
I wear two hats and interchange them multiple times within the conversation.
1: the teacher: I explain what i am doing / why i am doing it/ and what my over all goal is.
this allows the engineer to better understand my point of view and the goals I am trying to achieve. It allows them also to offer suggestions and options that may achieve the same objective while better meeting their needs. it also removes the impression that i am doing something “just because”. The most important things also is that I am not talking down to the person but talking to them at their level and simply explaining my goals and objectives from a different point of view based on my back ground and training.
- The student : I listen to what they are saying and why, and ensure i understand their objective and goals they are trying to meet.
this allows me to have a better understanding as a whole to the product development and to also see some issues that i may have missed or may not have addressed as fully as i could have in the upfront id stage. I also ensure that I allow the engineer to fully explain their information without interruption in order to show the respect due, I also ask questions to ensure that i fully understand and offer different points of views at the end. making sure that I am not coming across as dictating how it needs to be done.
In this way I find that the interaction is truly a collaborative effort and that we both walk away from the conversation with a better understanding of each others responsibilities / goals / objectives. thus coming to a middle ground that meets all our needs, and providing us with a strong cohesive design solution.
But in order for this to work both individuals need to have the right personalities and professional objectives for the project. But this opens up another discussion on how to deal / interact with various work personalities within the Development Process.
- 1 on the empathy for the respective skillsets and objectives. They are often the opposing point of view in design compromises, and it’s easier to work within the constraints when you understand their POV
I’ve worked in several positions where offices were set up so engineers and designers regularly mixed and didn’t become siloed… sometimes the open office plans encouraged better collaboration, passing in the halls or at the coffee pot. Once they even paired software designers with software engineers in offices, so they could empathise like partners.
In my last assignment, I came up with the engineering concept myself, along with several backup options if that concept didn’t work out. All the engineer had to do was a few calculations regarding the manufacturability of the concept, and then launch the concept into production. An industrial designer who designs for manufacture should be very competent in engineering skills. The dialogue between two occupations shouldn’t be so complicated and there shouldn’t be many problems.
It depends on how you see the relationship. In every equal partnership there exists a push and pull. I don’t want to reduce his work to calculations, I want him creatively engaged on helping me solve the problem.
An engineer once told me “My job is to tell you what is possible and what is impossible” and I my reply was “No, your job is to help me to transform the impossible into the possible”
I agree, mutual respect for each other skills /knowledge, and learning as much as you can about each other’s work goes a long way. Ultimately you and your engineer colleagues have the same goal, getting the best product possible to market.
I’ve been working in consultancy for the last few years, and find that teaching your colleagues more about what you do (and being interested in what they do) helps in several ways. Not only does project planning and design work tend to go more smoothly, but when it comes to meeting clients, we appear a much better integrated team if I can talk about engineering to the client and my engineering friends talk about ID.
The company I work for is unique in that I am one of just a few designers amongst the majority of engineers as opposed to other firms where I have been that have been the opposite with the one “office ME or EE”
Now on a daily basis I work on teams where I may be the one ID guy with several ME’s, EE’s, and CE’s.
I agree with everything that has been said above. I think it really helps to be able to speak an engineers’ language and use the terms they would use. I also think it’s important to show that you as a designer are thinking about all aspects of the design, manufacturing, pcb boards, tooling ect.
I think this helps bridge the gap between the two worlds because the perfect scenario is not a case of one group allowing the other to achieve their goals but rather the two groups working hand in hand to achieve a goal.
Something I’ve found that helps in client situations (when I am the only or one of two designers in a room full of other people) - and which may be applicable in your situation - is to work with the project team to identify clear, specific, measurable criteria in the concept phase and assign weights to all the criteria - so we’re all focusing on the valuable/important problems. For example, project X has the following criteria - easy to use, easy to assemble, high margins, good looking:
Ease of use becomes:
a) User segment 1 must be able to insert new cartridges into the housing in low light conditions sixty times a day
b) User segment 2’s monthly servicing of the components in the housing (which requires access to components x and y) must be supported
c) Menus must be minimized or eliminated.
d) Menu vocabulary must be based on end users’ vocabulary, not our vocabulary
Easy to assemble becomes:
a) Must assemble in such a way that one tool can be used to re-open the case in no more than 30 seconds
b) Must use in house injection molding and machining operations
Good looking becomes:
a) Finish quality must be similar to Dell Workstation PCs
b) Must visually communicate robust reliability
c) Must capture or complement design elements of product DR-4533
High margins becomes:
a) 40% margin
b) Minimize/simplify routine servicing by 20%
Each of these broad categories would be weighted (adding up to 100%):
Ease of use 30%
Easy to assemble 15%
Good looking 35%
High margins 20%
and for each concept, scored on a scale of 1-5.
By doing this, you make sure everyone’s interests are being articulated and represented, and that the scope doesn’t drift to some outspoken engineer’s obsession with clip fasteners, some designer’s obsession with Hytrel resin, or some marketer’s obsession with Apple ipods. You can objectively talk about ideas, and how tradeoffs from concept to concept compare.
I’ve done this, I call it “The appearance of objectivity” , in reality each of those scores, and the percentages themselves are pretty subjective, but it makes the left brainers feel better about right brain decisions that involve risk and responsibility for failure.
've done this, I call it “The appearance of objectivity” , in reality each of those scores, and the percentages themselves are pretty subjective, but it makes the left brainers feel better about right brain decisions that involve risk and responsibility for failure.
True - but it puts the whole team on more or less the same page of subjectivity.
We have 3 design engineers, technically 4. Two of them are great, we challenge each other and generally they’re quick to engage and see possibilities, there are always areas of tension, but from a background standpoint we are on pretty even ground, I think that in and of itself does go a long way. Typically I bust out a big range of concepts to show potential scope to generate some excitement and then we brainstorm how to get there. I never claim to know how everything should be engineered and they never claim whatever market we should design for or how to market it. So, it’s pretty good, a recent success was the launch of a product line that crushed sales projections by about 200%.
Then, there’s the other two…and their boss. They drag the whole process down because of top level politics, it also doesn’t help that one of them has relations high up. The egos are huge and they don’t have the cred to go out and get the same positions at any other company so they blow sunshine up the owner’s ass and fight tooth and nail to maintain engineering’s high position within the organization, not to mention their own jobs that fresh ME grads could do better… Bitter, yes.
I agree, even though I wrote a sarcastic response. It gives a little more definition.