Improving Developer UX

Software engineer and data scientist Gabriel Pickard recently has published an article about developer experience being fundamentally harder than normal UX.

He defines developer experience as the user experience of the tools software developers use in order to do their job:

• code editors
• IDEs
• command-line tools

Gabriel identifies these main aspects in which in his opinion developer tools are failing their users:

• Counter to any UI/UX philosophy, as programmers we find ourselves maintaining vast background knowledge about the structure and dynamics of our programs, with nary a visual cue to help us.
• It’s often so hard to figure out what exactly went wrong when something goes wrong.
• A lot of tools are truly ugly!

Among other aspects he suggests the following measures and considerations in order to improve developer tools specifically:

• Address the many components that make up programming in concert. Software development often involves countless tools and components at a time: CLI, IDE or code editor, browser, remote servers, network infrastructure, you name it. How can we use those in conjunction and make sure that the overall process results in a smooth user experience?
• Search: It’s a well-known “secret” that searching for specific solutions on Internet search engines is part and parcel of being a good programmer. So, why is search relegated to the position of a second-class citizen during the development? More importantly, what can we do about public search engines apparently and progressively getting worse and less useful for non-generic usage patterns?
• Standardize fundamental questions: How can we standardise aspects such as bootstrapping, configuring or starting a project? How can we keep README files up-to-date? How can we develop consistent best practices for project structures?
• Improving testing usability.
• Coding is a social process.
• Programming languages are user interfaces: Why is it then that so few of them seem to take developer user experience into account as a core design principle?

While he does have a point I think that – while developer user experience in some ways indeed is special – software development is not the only discipline for which user experience is fundamentally harder than usual. In fact, one of the early origins of the human-centred design approach conceived and advocated by Don Norman are the design failures that probably led to (or at least exacerbated the failure to appropriately deal with its cause) the Three Mile Island accident.

Another example of early applications of the nascent discipline of user-centric design was the arrangement of instrument in WWII fighter plane cockpits, which led to frequent crashes and so-called “pilot errors”. As human-centred design has taught us and as Don Norman never gets tired to explain: Human errors are almost always flaws with the design the person used at the time, not actual human errors or personal failings!

It’s safe to say then that software developers aren’t alone in that their job involves tremendous complexity and the tools they wield often are inadequate and error-prone. One key aspect of tools for professionals, whether they’re writing software or operating a nuclear power plant, is that these tools expect their users to learn how to use them properly over time. Therefore, not every action has to be as in intuitive, not every affordance has to be as obvious as it would have to be for the casual, first-time user.

However, what stays the same between both types of users and hence both types of tools is that actions and feedback should remain consistent!

In “The Design of Everyday Things” Don Norman describes this distinction as knowledge encoded in the head versus knowledge encoded in the world:

For professional tools knowledge encoded in the head supported by appropriately encoded knowledge in the world absolutely is a viable approach, provided there’s appropriate feedback and a tool’s conceptual mapping corresponds to the mental model a user has about how that tool works, i.e. actions and reactions should be consistent.