workflows with engineering: what does/does not work?

Edit: new title

So here’s the deal, after working in an engineering department as the only designer for almost four years, we’re finally drafting a process for product development, and the best part is…it includes design! So I’ve been slowly breaking down the “design is just sketches and stuff” walls for a while now, showing the benefits of design process and how it can help to create a product that hits the target user, and now I’ve been tasked to link the process I was taught in school/would like to follow, with a more traditional engineering (think lean, dfma pfma type stuff) process.

I have two things to go on, my training in school, which only a couple times involved engineers, but we thankfully did have a class in marketing (or at least how market research, product planning, things like that) and how to integrate that into a design process. Secondly my experience here at work, and freelancing the couple of times I’ve done it.

But at the end of the day, I don’t have any good examples of how a designer (or design department) and engineering work together on a daily basis/what that flow of work looks like.

So here are the things I’ve been tasked with drafting:
• What funnels ideas into the idea pool
• How do we assist director levels in selecting ideas and vetting them for selection as projects
• At what points do things like exploration and ideation come into the process
• How developed of an idea or concept does it have to be before engineering takes over (switch seats with me)

My major fear here is missing something, and then basically building myself into a corner later on down the road process wise. Do you all have any advice about the ins and outs of what has worked with you as far as implanting the design process into an already existing company/engineering department? Things to not do/do/watch out for?

Thanks again,

Love the quote. So true.
This was my experience at my last job - we had an established design group but the dynamic of how we worked with the other disciplines (ME, EE, software, customer svc, manufacturing) were always in flux.
I believe we found success through starting as early as possible with the design phases (research, scope, framework, what questions to ask) and bringing in select but key engineers to collaborate in those early phases. My lead engineer and I would always go out for sushi right after the project got green-lit at the proposal phases, just tossing sketches back and forth to get ideas flowing.
In addition it was essential for the design effort to have an ‘architectural’ component to it - not meaning buildings but by the designers comprehending everything that might go into a finished product. For instance I had to engage engineers very early on to understand what might drive part/color breaks, what molded parts might be complicated to fasten together, what could be plastic or metal, how we can stay under budget, etc. It meant the designer had to have a good idea of the vision and then act in a technical manner to imagine how it would be made in the end.
With these two tips you can go a long way to engendering a more productive relationship with engineering, one that hopefully won’t just be seen as sketches and stuff.
Oh - also we found it important to try to isolate the areas where more investigation/innovation had to take place, and work those as separate projects, driven by ID. For example I had an idea for a new kind of seat construction process. We spun that off as a separate project, built protos, found potential vendors to help develop it, and did everything up to proof-of-concept models, at which point it became part of the overall product. Again, this means starting EARLY - because as I’m sure you know, once the development and delivery process starts moving its hard to say “wait wait wouldn’t it be cool if this part could be more like this”.

I could go on and on, will wait for other responses or questions first.

(ironically I’m now in a job that is 99% design and I’m the one who has to inject some product development rigor into it!)

It’s difficult to be specific as all companies follow a different process even though they may adopt a common model.

My history has always been starting from a product specification document originating from marketing or sales. Over years my involvement started earlier until actual release of the product specification document to the project team included select ID sketches and renderings. The design interpretation, critique and selection was done by a very small group, which worked well compared to other projects where there were more stakeholders and, usually negative or just inappropriate, opinions.

It was established, by the engineers of all disciplines, that having a mental image of what they were starting to design was a tremendous benefit, rather than previous finite specifications such as functional block diagrams and cost targets. As various engineering disciplines started I and other designers continued in communication with them to refine the concept with appropriate space claim, including models. Something I’ve never really done in this process is “hand over to the engineers”, always staying involved to some extent, often to continue to explain, fight for and defend everything from the entire design concept to minute details of button placement. A few projects where I have been less involved indeed the engineering team has been guilty of some pretty egregious redesign based on their individual finite work packages, and unfortunately in a complex world it’s the original designer , not the engineers, that gets asked why this detail is so bad.

I would include in any multi-discipline team design procedure the ownership of responsibilities, not time limited.


Those are some great ideas! Through the years I’ve developed a really good workflow between some of the more “conceptual” thinking engineers and I, and you are completely right, spending two days sitting around a desk toss sketches back and forth is a great asset to the project. I like your idea about taking the new ideas that might pop up during a development phase, and realizing when they’re out of scope, and breaking them off into their own projects.


Maybe “hand off” was the wrong wording, think of three people sitting at a table, one the project lead, and the others are support, I was mostly saying at some point I would switch seats from the project lead, to a support role (never leaving the table though.)

Did you find that marketing needed some amount of training as to know what type of information you needed to start on a project? If so, how deep do you think they would go ideally into research? (like a macro vs. micro thing)

Thanks guys for your comments and advice!

The hardest part I still need to figure out is how to make space for there to be some kind of random exploration. At the end of the day my department is made up of very few resources: vp, director, manager, three engineers, and myself…