I think it’s typical to think of user experience design and usability in the context of “users of our product”, i.e. buttons and menus and toolbars, and colours and drop shadows that we need to update every time fashion changes. Much benefit can be derived from thinking about usability more broadly, in the context of all our work.
Even in the extreme case of an engineering team of size 1, there is an infinite number of users involved — the you of today, the you of tomorrow, the you of next month, and so on. They all have different mental contexts, are differently alert or tired, have forgotten the details of different parts of the code that they rarely look at. When multiple humans interact, over time, focusing on them as “users” and designing the experience for them can have a huge impact in terms of lowering the cognitive overhead of working on the code, thus increasing productivity, reducing the number of errors, increasing the sense of understanding and thus ownership, empowering to keep the quality of the codebase high.
This is all to say that user experience design is not just for user experience designers to worry about — it should be a primary concern for programmers.
It can be beneficial to start paying attention to usability of other objects you interact with, both physical and virtual. The interplay of usability concerns and constraints imposed onto the design by external factors tell interesting stories about the design process, and the more such stories you expose yourself to, the more lookahead and visibility you’ll have next time you are designing something. In short, it will make you better at your work.
You are about to sit down in your chair. Just as you’ve transferred most of your weight from the feet to the seat, you execute the “pull chair forward” maneuver. The last thing to get comfortable and back to work is to plant your right foot on one of the chair’s caster legs. Just as you try to do that, your heel jams against the chair’s height adjuster, causing the chair to descent, jamming your foot. This happens once every few weeks, just around the time you forget the frustration of the last time it happened. Did they really have to put the bloody lever in that exact spot?
How many times have you screwed yourself or colleagues over by making the programming equivalent of this sort of design flaw?
Comments
Post a Comment