Should Engineers Be Involved in Product Design?
Consider these roles engineers could play in human-centered product design.
Engineers are the problem-solvers of our world. They figure out how to execute a designer’s vision with the materials, components, tools, processes, and budget at hand. They help turn a concept or model into a reality.
Should engineers also be involved in design? They often are—after all, many engineers are design engineers. But the question is—should engineers be involved at the creation stage, exploring user needs and developing designs to meet those needs?
John Reed, managing director at Launch Consulting, a Division of The Planet Group, believes that engineers should be involved in all phases of the product design process. Reed has more than 25 years of experience working with a diverse range of clients and colleagues across industries and geographical boundaries. He enjoys focusing on problem-solving, both mundane and novel.
Design News asked Reed a few questions about the roles engineers should play in designing products.
What role should engineers play in supporting a human-centric product design approach?
Reed: In theory, engineering should participate in all phases of the product design process. Here’s why:
An empathetic understanding of users and their needs helps guide implementation design decisions.
When ideating solutions, engineers can provide insights into system level constraints and opportunities.
Collaborative prototyping introduces engineering perspectives on feasibility and implementation complexity.
Engineering participation and ownership reduces cost of implementation and aligns implementation effort to value.
In reality, this can appear to be an expensive investment (although, when done well, always yields greater return). Regardless, optimizations to the process are typical. Consider these potential roles engineers can play during the following design stages:
Empathy/Customer Research: No direct engineering participation. A readout and QA collaboration is typically sufficient to get key engineering leadership aligned with customer insights and direction.
Problem Definition: UX owns this but should inform engineering to again keep them aligned as to the “why” behind the problems to be solved. Some input can be accepted but is primarily driven by UX.
Ideate: This is where engineering needs to start being more part of the process. Note, this will be easier if they’ve been engaged from the beginning as they will have the appropriate context to participate. Engineers will have exposure to interesting technical perspectives and possibilities that could unlock additional ideas to solve problems. Note: it will be tempting for engineers to start “solutioning” at this point, which can stifle creative thinking owing to implementation feasibility fear. It will be important for facilitators to coach and guard against this.
Prototyping: This is where engineers can start introducing feasibility constraints and alternate approaches and weigh in on systems constraints and implementation costs to guide direction. Again, this is input and should not be onerously restrictive. The attitude should be to challenge the engineering team to drive the best solutions; not let them act as gatekeepers. This is where the relationship can break down and requires healthy product and engineering leadership to drive quality product decisions.
Test/Learn: The feedback loop here starts the next iteration of product refinement. Everyone should be active, candid participants on what is working and what isn’t to continue narrowing the focus on how to get value into the customer’s hands.
How can engineering feedback influence a product design to ensure manufacturability while retaining positive user experience?
Reed: Having a strong trust relationship between engineering and the product team is critical. The tension arises when the product team feels like the engineering team is being overly restrictive in their ability to create value. It can also develop when the engineering team feels like the product team doesn’t respect their professional experience on feasibility and implementation direction.
If leadership can get everyone truly aligned on holistically being a customer-centered organization as an identity, this dynamic seems to shift. Everyone gets held accountable to decisions that are driving the customer experience forward. When everyone believes that is the common objective, everyone becomes more respectful of the opinions of others.
So, engineering needs to be able to clearly articulate to the product team that they empathize with the customer research and understand the defined goals and needs. If so, their opinions and recommendations will be met with less resistance when collaborating with the product team on feasibility and alternate implementation direction to get value to the customer quickly. This is why it is important to have them as participants throughout the process, and one of the reasons why the investment in their involvement early and often pays a return.
Can you explain what a test-and-learn approach is and how engineers may be involved?
Reed: Test and learn is iteratively getting increasingly higher levels of prototype fidelity into the hands of customers for feedback so the product team can continue to refine product design concepts. Go cheap, dirty, and fast early to gather information quickly with minimal investment. As prototype fidelity increases approaching commercialization (and ultimately scale), the investment cost increases as well. These test and learn cycles mitigate risk that the company isn’t investing in the commercialization of a non-value generating product.
A human-centered design approach is iterative and non-linear. The results of the test-and-learn phase will direct the overall product team on where to revisit the process for further refinement. We’ve discussed where engineering participates throughout the process. In this phase, engineers must understand this output to provide feedback on where in the process the team should return. More importantly, it equips them with additional information and context to continue collaboration on product refinement.
How can engineers obtain user feedback and incorporate it into their work?
Reed: Engineers should be viewed as first-class citizens of the product team. Regardless of how an organization implements their human-centered design process, engineers should always be engaged and active participants. Their input, and the value it creates, should be a priority. So really, they should just be a part of the team holistically and be actively engaged in the process. It shouldn’t feel like an out-of-band activity to get user feedback.
Are there any standards or methods engineers can consult when developing a human-centric design approach?
Reed: There are a number of books out there on design thinking. But for an easy intro reference, I recommend the Institute of Design at Stanford’s An Introduction to Design Thinking PROCESS GUIDE.
Can you provide examples of how user feedback influenced the engineering of a product?
Reed: Consider these examples:
Early prototyping of a wrist wearable where we found that users wore heavy industrial gloves every day that would have obscured their visibility to the device. We scrapped the concept and saved countless costs hours and dollars in not pursuing further validation or engineering.
Early prototyping demonstrated use in a loud environment. We found that audio cues would be useless and instead opted for haptic cues and more pronounced visual cues. This saved implementation and user frustration of the end product.
About the Author
You May Also Like