Are machines here to serve us, or have we humans already sold our souls to serve the machines? If you’ve ever gone through the agonies of trying to rebuild a crashed computer or recover an erased hard drive – or if you’re reading this as you sit in the waiting room of the local auto repair facility – right about now you may be wondering. Buried in that question of, “Who is the master and who is the slave?” is frequently a stinging indictment of the quality and usability of many of the world’s user interfaces.
In new product development, any proof of concept should take into account that at the very end of the trail blazed by all that new technology is the living, breathing human being who has to use it. We often think of ergonomics in the context of where the controls on our automotive instrument panel are placed or whether our driver’s seat comes with lumbar support. But the human design element turns up in a whole lot more places than a car interior, and human factors should be considered for much more than just medical equipment design or the development of biometric systems. Ultimately we all have a connectedness to the machinery at the very bottom of the technology food chain if we’re interacting with the user interface at the very top.
As developers of real time embedded systems, control systems, and electronic hardware; at first blush it might seem that we at Focus Embedded would be among the very last people interested in human factors design. After all, above the applications programming interface (API) lies all the software and user interface design that demands cognizance of how humans work. But below that API, embedded firmware
and low-level hardware
is only ever interacting directly with other hardware and software – not real people.
It’d thus be easy enough for us to shrug and say, “We don’t deal with end users, so we can just code to the API specs and punt the whole ‘user’ question onto somebody else.” And a lot of engineering consulting companies and product development service bureaus that work in the embedded space do precisely that.
The hard reality, however, is that this approach results in products that though they be functional have poor usability. You won’t build a cult following of dedicated users (except among extreme masochists) with user interfaces that fall significantly short of those designed by Apple. And that means that if you’re an embedded design consulting company (which Focus Embedded is), you’d better be aware that your customer may well be the human being assigned with the job of using your low-level firmware
or hardware in a way that’s pleasing to his customer, the human being who is the end consumer. Apple remembered this well when they built the board support package (BSP) and software development kit (SDK)
for the iPhone, and the result is that they’re now leveraging the efforts of tens of thousands of applications developers worldwide who genuinely enjoy coding for Apple iPhone products.
Conversely, if you’re in the embedded development space and you’re making your API’s clunky and cumbersome for that person doing applications development, there’s an excellent chance that what he presents to the end customer is also going to be clumsy, inelegant, and unpopular. Much like the chef back in the kitchen, if you’re the embedded systems designer you may never see the guy in the dining room. Only the waiter may do that. But like as not, that diner is going to see you when the plate with his dinner is put on his table. Or to use a metaphor from homebuilding, once the foundation is poured crooked, there’s a limit to what even the best framing carpenter can do as each floor of the house gets put on top of it to make the upper floors straight.
Indirectly what’s done in the embedded space touches everyone – and most of all touches the human being who ultimately uses the device and either recommends it to his friends or pans it publicly on any of the “rate this product” bulletin boards out there.
Don’t underestimate what happens below what you think you can see. Keep your humanity in Focus.