How ME’s Switch Gears During the Design Process
The product design process goes through many phases. An overly simplified version of events has participants gathering info, communicating needs, understanding limitations, designing and developing, and then finally manufacturing a product. Integrated businesses involve mechanical engineers (MEs) on teams throughout the process. And even when they aren’t directly involved in every phase, they possess key understanding to inform these transitions. Each product cycle is unique, of course, as are its challenges. And as each product evolves, so too, does the ME role, and with the Internet of Things (IoT), those changes are happening at an accelerated rate. We explored how this looks with three of our resident MEs at Altitude – Spencer Boone, Lee Powers and Amy Loomis.
Research and Understanding
At the start of a project, research is key, particularly when faced with an area where MEs aren’t experts, but will need to be if they plan to be successful! “When we’re going to enter a market,” Spencer shares, “we’re going to look at some user groups and we don’t really know what the final solution really looks like, so we research a broad range of technologies that we might think about including.”
“It all depends on the client expectations,” Amy adds. “We look first to what they are actually bringing to the table as a company, and what they actually want to achieve, too.” And sometimes it has them working backwards. Lee says the client “may bring technology to the table and say ‘we’ve already got the technology, figure out the details or something’ and that’s what we’ve been doing. Helping everyone realize what’s actually possible today versus what’s possible in the next five years.”
And understanding that distinction matters.
Using Technology Today or Wait for Tomorrow?
Waiting on five years of R&D makes sense in some verticals, but for many it’s just not a realistic number. And there’s the practicality of it from a consultant standpoint as well, where there are definite time constraints. “As consultants, it’s not in our best interest to propose technology that doesn’t exist yet for a product that we’re under the gun to develop right now,” shares Amy.
The hardest part is when there’s a disconnect between what’s possible and what’s probable in a defined timeline. This is why understanding what you’re getting into up front is super important, as Lee elaborates: “When we are looking for technologies, we are looking for tech that really has had all of the R&D done, so we can prototype it and make it real. . . . It gets really hairy when you’re working on something you think will take a year and a half, but really requires five years of research and development.” And knowing the difference between what will take two years and five years is really hard. It’s also difficult to say what will become obsolete, so it’s a balance between what’s relevant today and what we’re anticipating five years from now.
And one major distraction has, of course, been IoT. Everything is amplified and somehow affected by it, because an IoT product is not a stand-alone item, it’s a system. So any changes are more dramatic, transitions are harder, and the overall level of complexity has increased significantly for users and designers. Let’s take a look at the IoT impact on the design process a bit more:
The IoT Impact
IoT has quite an impact on the design process overall, particularly on the mechanical engineer’s day-to-day. Consider this example Lee offers: “A client comes to us and they have a product that’s pretty well thought through except that it needs to be connected to the internet. So what does that mean? There are lots of ways to connect – and do they even really need to connect to the internet? They’re trying to get data off of their product, and so we may even question do they need to get that data?” If the end goal is the data, they may not even need to connect to the internet to obtain it. Assuming they do need to connect to online somehow, a whole host of considerations come in to play:
- What are the possible technologies available that are currently in use, not future use, that could interact with this device wirelessly?
- How much effort would these technologies take to implement?
- What would the hardware cost be?
- What ongoing costs would there be?
And there are always additional product-specific considerations. “So when we start to say a device is IoT, there are many technological parts to it, and trade-offs have to be made before we even more forward.”
It’s important to continuously ask yourself “what does the user get from being connected?” says Spencer. “No one is going to connect to the internet unless there’s a real valuable proposition for them to have it connected to the internet.” And being tasked by higher ups to ‘go make a connected product’ is not always a good enough reason to move forward. “Outside of going down that rabbit hole though, we try to redirect client thinking toward thinking of the user experience first.”
Once the technology to be implemented is decided, it’s off to the races, right? Not quite. The dichotomy between strategy research and tech implementation always leads back to the end user where the question remains: what is it that a user really wants out of this? And it requires an ME to wear many hats to keep that concept in mind, while balancing physical production constraints.
The Fluid & Multilingual ME Mindset
Ultimately, the ME role is fluid and changes depending on where the product is in the cycle.
“Depending on what type of product it is,” Spencer offers, “we’re kind of the owners of it because we’re on the hook for making it work.” And making it work means speaking many languages. “We’re trying to speak the electrical engineer’s language as we consider battery life and startup procedures, we’re trying to make sure the database backend is all figured out so we can make good use of the data later on, and we need to own the physical components and their manufacturability, so like we end up being the jack of all trades.” There are seemingly endless conversations with other functions each step of the way to ensure the design intent is maintained. And we consider ourselves to be gatekeepers for that, of sorts. But every role at Altitude feels the same way – and that’s why it works!
For more about how our Mechanical Engineers think, check out Spencer’s blog on “At The Heart of Prototyping – The Experiment”.