It happens to be exactly 2 years since I last posted on this blog. A lot can change in a relatively short period of time huh?
It was pretty much at the time I left off here when I decided to pivot my career from mechanical design to focus more on automation, controls, & software design. Observing how the pandemic has impacted most company’s decisions involving automation, this was a lucky move.
At that time I had been semi-recently laid off and I had spent enough time on my own to reassess the job market and determine that my career field in today’s world had seen many formerly valuable skill-sets become commodified.
Being able to use a given CAD program is not the special skill it used to be. We teach kids how to use them, which is great, but it means the barrier to entry for mechanical design is now incredibly low.
Nowadays, the moment a cool new product is revealed on reddit, literally hundreds of people are racing to copy it, then share that copy for free online. Then others quickly find it and start selling it on Etsy or Ebay, in a very short race to the bottom where some folks eventually sell the item for less than it costs to make just to get a sale.
It sounds like hyperbole, but its actually a repeated observation. This process can take as little as a day for simple items. Much too fast for a Kickstarter to even finish, let alone deliver… Incredible.
While this is not a new phenomenon exactly, the speed at which this happens now is new to the last couple years. Especially at the micro-business level. I’ve been following along as an admittedly guilty participant myself, having invested much of my free time learning how to select & build better products, better processes, and a better store. Taking inspiration from anywhere and everywhere, making notes along the way, but sharing none of them. Such is the normal culture of the webstore owner’s groups to which I belong. Dropping a link to your top selling diy-product in one of those groups to help out a newbie is like dropping a lambchop into a den of wolves.
But choosing not to share your work can be risky too. Isolation from competitors comes with isolation from customers. Many of the makers & self proclaimed startup guru’s I follow online profess the value of developing your products and sharing your processes completely in the open. Openly shared, if not open source entirely.
In a world where attention is literally currency this makes sense to me, but then again, how is the strategy of sharing your development process compatible with the current hyper-competitive compete-against-desperate-people-working-for-free atmosphere described above, if you are not seeking to be an entertainer as an end goal? Perhaps its as simple as artists/crafters should share, product designers producing more valuable IP should work in a cave… At what sales volume does a craft become a product and the optimal strategy invert? I don’t know.
I do know that I used to enjoy distilling my own lessons learned into random niche articles and that I’d like dust off this old hobby. A quote I saw recently, ‘I write help me figure out what I’m trying to say’, resonates. I know I learn more when I share through the process of unscrambling my ideas. Of course, I think anytime a writer is bored writing something the reader will be bored reading it so it is best to only share when inspired.
Today I want to share one thing that has inspired me lately. A strategy that has helped mold a major body of work I developed in a cave during lockdown.
Since the pandemic has prevented physical access to my library, I’ve taken to doing most of my ‘reading’ via audio through Alexa or the Overdrive app on my phone. Much easier on the eyes than eBooks.
So a while back I was taking a walk, listening to an excellent book narrated by author & world class poker player Annie Duke called ‘Thinking in Bets: Making Smarter Decisions When You Don’t Have All the Facts’; when she said something that made me physically stop to write down and mull over.
It was funny because the sentence sounded alsmot off the cuff as she was leading up to her main point, but this was the bit I as I remember, paraphrased:
In context to her book, Annie was referring to decision making tools, but it struck me as an interesting way to evaluate ‘tools’ in general. Regardless, Annie makes better than average decisions in difficult circumstances and she uses multiple strategies to do it.
She recognizes that factors outside your control always play a role in determining how a situation turns out for us. So when you reflect on your past decisions, she recommends that you evaluate the quality of a decision separately from the quality of the outcome that resulted from that decision.
Remember that your past self was trying to make the best decision you could with the limited information you had available at that time. If you find that you have ended up with a bad outcome, it does not necessarily mean that your decisions were bad. Similarly, when you find yourself enjoying a good outcome, its does not mean that your decision making process was sound. (the dog-money link applies here too, ha!)
If the tool only works for you and no one else, then you are the key variable causing the desired effect rather than the tool. So as we seek to equip ourselves with the best decision making tools we can in life, it is helpful to remember that the quality of a tool can be measured by how well it predictably produces desirable outcomes, irrespective of the user. How good one tool compares to another similar tool often seems like a subjective opinion, but by this metric it can be quantified.
Nowadays my day job consists of building various test machines intended to certify the quality of the products my company manufactures.
The products being tested are complex. The test requirements are strict. So the machines my team makes have to be complex too.
We know that in the end a person from outside our group has to operate our testing machine to perform the tests. So while the overarching high-level task is complex, we don’t want the sequence of low-levels tasks necessary to complete it to be too complex or else the process fails.
As designer of that test machine, I get to dictate exactly how that human-machine interaction occurs. And while thinking about how to best do this I’ve recognized two distinct interaction paradigms we can choose to use:
1. The multi-tool approach: Empower the end user.
Make the test machine/process into a multitool with a specific function for everything it might need to do so it is flexible for all possible needs. More gages = more feedback, more levers = more unique tools the user can deploy. Then we can rely on the expertise of the end user to apply their judgement on which feature to apply for their specific situation.
This approach is great for handling tasks where variety over time is a factor. If you know the operator is skilled enough to understand the context, then relying on their subjective input makes life easier as a designer. Though beware, a cynical person might say if you empower the user completely then technically it’s their fault when things don’t work…I imagine that excuse is frequently used to disguise technical debt or maleficent intent.
2. The automation approach: Disempower the end user.
Take all unnecessary control away from the end user & avoid relying on them when possible. Limit interactions to only those that are necessary at a given time. Let the machine use the information it has to make assumptions & do most of the work, while it provides the human operator with clear progress updates.
This approach has the advantage of more consistent results, since the human element isn’t injecting extra variability into the procedure. On the other hand, you do have to be careful as a designer when assuming so much control. Any computer automated system is like a chain. If you rely on unstable assumptions & the requirements change then the flow of information gets broken by the weak link, the system crashes, and the problem is back in your lap!
From the designer’s position, there is a time and place for both types of solutions, or a hybrid model, but undoubtedly the system you choose makes a drastic difference in the experience the end user is subjected to. Something like this:
From the end user’s point of view:
I would rather have technology serve me like George Jetson.
My latest product is a specialty CNC machine.
There are powerful free tools out there for programming & operating DIY CNC machines. I can’t remember the last time I saw a homebrew CNC-something that didn’t use GRBL, the amazing catch-all CNC multi-tool.
That’s because its highly configurable and there are hundreds of GRBL compatible software solutions out there that empower the user with unique tools to complete the universal workflow of digital fabrication. That is:
Raw Input <to> Paths <to> List of Machine Commands <to> Serving/Performing Commands. Then hopefully <to> the outcome I want.
Here’s the rub. All the extra gages & levers make for a byzantine process to setup, troubleshoot, and carry out that workflow on a day to day basis. Here’s a perfect example of the effect I’m trying to avoid, scroll down to the UI screenshots here…
More is less & less is more. I just want my machines to work for me, not the other way around.
It seemed to me that the CNC machines in my target market could be easier to setup & operate. Even a sophisticated consumer grade CNC machining tool is not even classifiable as a ‘robot’ because they are purely functionally programed. They produce one possible response for a given input chosen from a predetermined set of discrete inputs; they are as predictable as a pocket calculator. Which means there are many assumptions that the designer can make on behalf of the end user to make their life better.
Like the writer who writes to better figure out what they mean, as I designed my machine I kept revising it until I eventually figured out what it was I actually wanted to make.
A machine that is a joy to use.