I’m an industrial designer with minimal hardware experience. Is there anything you wished industrial (or product) designers knew about tools, skills, or info relating to hardware design? Either within your own scope of experience, or based on what you’ve seen in the wild.
I want to better serve the hardware and engineering folks I work with, so we can make everyone’s job easier. In the words of Jerry Maguire, “Help me to help you.”
Thanks!
Also, I forgot to mention: It’s my first post, and I’m super stoked to have found this community!
Hey Daniel,
It’s great to have you with us! A good place to start would be at a local hackathon! They’re a fantastic place to learn how to work with hardware folks in-person. Aside from those, using Upverter by forking existing projects is another way too!
You’ve already tried the tutorial, so you’re well on your way! 
Those are both really great ideas. Thanks!
Not a problem, Daniel!
Hi Daniel,
I have been teaching electronics and hardware design to industrial designers and media and interaction designers for a couple of years now. At the start of each class, I tell my students that their goal is not to try to become electrical engineers, but to acquire sufficient knowledge about what can be done and what cannot to be able to have a good collaboration. So you don’t necessarily need to understand the inner workings of anything, as long as you have a good grasp of how everything works together.
In hardware as in code, the line between the easy and the virtually impossible is often very thin. In order to know where it lies, the first step would be to take a couple of arduino tutorials, make the circuits, etc. This will already give you a good starting point. Then, as Yusef said, hanging out at a hackathon is a great experience, as would be joining your local hackerspace, if there is one. Go there, look at the projects and ask as many questions as possible. Also, if you’re still at school, I’d suggest trying to challenge yourself by adding as much hardware design in your school projects as possible.
That’s very helpful. I think that while orienting oneself in any field (especially the more technical ones), it’s easy to feel as if there’s too much information to even begin, but there are constantly tools to help novices get a good basis in the field. Thank you very much.
I think that to some extent, ignorance of the field can sometimes be a blessing. When you know what the hard things are (or think you know, at least), you might be hesitant to do things that will be too hard. But if you come at it with no experience, and know knowledge of where the limits might be, you might inspire someone to think outside the limits, approach the problem from a new direction, and end up doing something cool.
I used to work for a company building software for mobile phones. They were pretty weak devices at that time, with no GPUs, and battery life was valued above almost everything else. The engineering teams had told the UI teams that animation was impossible. They said it would take too much CPU, use too much battery, and would never look smooth. But one day, a group of developers who hadn’t been told about these limitations decided to build a small app with some cool-looking animations.
It worked! It animated at about 30 fps, and since it was used judiciously, the battery drain was minimal.
There’s a similar story from Apple, when Jobs was given an early version of the iPod to look at. He complained it was too big. The engineers of course explained that they had done everything they could to shrink it down, including inventing new assembly methods to get it as small as possible. In response, Jobs dropped the prototype in a fish tank. Pointing to the air bubbles, he said “See, there’s still space in there.”
It’s probably very useful to understand how engineers work, but be careful if they tell you something is hard or impossible. Those barriers may not be as solid as they seem.
Thanks for sharing! I agree on all points. I know I tend to learn more when trying something that’s known to be impossible (and likely failing) than simply taking that impossibility at face value.