The greatest successes in the field of HCI are those that bend technology to the will of human need. But bridging the gap of silicon and flesh is arguably one of the hardest challenges that faces those working in the tech industry. Building anything technical requires technical thinking, but to step away from that and consider human factors, then back into the technical realm to serve those factors, is a rare skill indeed.
It is for this reason that getting it right with humanistic technical products is really hard. Making things work well for humans and for machines requires constant realignment of thinking. When writing code, one must be detail-oriented and take a granular approach. But as users we tend to view things in a holistic, top-down way: at first making sense of interface, then functionality, then breaking down individual process in our head. So in order to build something that is functionally sound but also usable, one must continually shift their perspective from bottom-up to top-down.
How then do we make the process of building human-friendly products easier? The most obvious and common approach is to do things in teams. If one person is focused on usability and one person on making it work at a technical level, then the end product will be informed by both machine and human-influenced thought processes. In reality, however, even close-knit teams are subject to drifting from a common goal. And what if you’re going it alone? There are certain heuristics that can be applied to humanistic design regardless of team size.
Be ruthless about MVP
Countless reams of blog posts and books have been written on the importance of sticking to an MVP, but more often than not this is for the simple reason that scope-creep and bloated functionality result in blown deadlines and budgets. When building a humanistically designed product, MVP becomes important becuse that added complexity can easily make your product less suited to the need of the target user.
Talk to people
No web-based service that has ever gained substantial traction has got away with not thinking about how to tailor their product to real people. Who are you really building for? Children? Adults? Restauranteurs? French horn players? Even if you think you are building for yourself then at least find someone like-minded and get them to take a look at your product. The value of external input should never be overlooked for the simple reason that they don’t know what’s going on behind the scenes. While your mind is cluttered with wireframes and code, they are innocent and bright-eyed, unfettered by the hours you spent tearing your hair out fixing bugs. A fresh pair of eyes can do something that yours can never do, and that is to see the product in a completely holistic way.
Don’t be a magpie
It’s easy to be distracted by the possibilities afforded to you by shiny new technology. But in order to keep your product lean and user-centric it’s important to evaluate any new technology through the filter of “is this improving the product for the user”?
Just because a couple of extra lines of code make your product navigable via webcam-based semaphore detection doesn’t mean you should necessarily add them. The added layer of complexity, i.e. having to learn semaphore to use your product, can easily put people off. An even greater danger is basing your entire product around a new technology. Indeed, part of the reason so many startups fail is because they try to use technology to solve problems that no users actually have, and therefore end up with a technically exciting but ultimately useless product.
Wear hats
Wear a developer hat when you’re knee-deep in views and controllers, but routinely take that hat off, put it to one side, and put on your user hat. Stop thinking about the functionality of your product and look at it from the perspective of a human being. Always thinking like a machine will only result in a machine-friendly product. It’s important to take a step back and inject some humanity into what you’re building.