User eXperience – Quality Essence – Testing Essence

A vision for the future: a workbox for tool builders

Software is ubiquitous, and yet so often fails to delight us.

I work in the IT industry, principally in software quality improvement, user experience and software testing. I have over 30 years of experience. I observe a problem with software: it is ubiquitous, yet fails to delight us. I observe a problem with software engineering: the tools used by engineers is hard to use. This leads to poor decision making and hence to delivery of inadequate software that delivers an inadequate user eXperience (UX).

The problem

The last few decades of experience highlight for me a conundrum: technology changes rapidly, yet the mistakes made when delivering software are repeated as each new generation enters the industry. In my last two blogs, I discussed Why everyone needs a better experience of software and Why we need a better tool set for building software. I said that technology and software are flawed. I said that the industry and its tools reflect an unconscious bias, towards a notion of a “typical software engineer” which then becomes self fulfilling.

Supposing we could change that?

The vision

My vision is to radically improve the quality of software, specifically the user experience (UX), by addressing one root cause of the problem: the engineers’ tool set.

The tools used by the teams who design, build and support software are essential, and could be a delight to use – if designed with UX in mind.

The tools could provide a beautiful UX to a wider group of people so that a diversity of people are encouraged into the industry

The tools are then made by “diverse software engineers” and used by “diverse software engineers”

The tools reinforce the use of interface designs that appeal to “everyone” because they are naturally and usefully beautiful.

If the tools are improved and modernised, then it will easier for engineers to deliver software that delivers a beautiful UX, because they themselves will experience a beautiful UX. Also, a wider range of people will want to be engineers and use the tool set.

By engineers I mean anyone working on the delivery; some may not see themselves as engineers. They may be product owners, business representatives, acceptance testers, even sales and marketing teams may contribute. In terms of job roles within the team, they may be designers, developers, testers, release teams, support teams.

All of those people contribute to the users’ experience of the software. All of those people rely on tools to provide information about the software and how it behaves. All of those people will contribute information – often into a tool – which feeds decision making about the software. Few of those people build their own tools. Many feel undervalued, unsung, and, as we saw in my earlier blog, blocked/dehumanised by the tools they use.

The workbox

My plan is to implement a project that will to help tools builders improve their tools. This will enable the engineering teams to concentrate on making software delightful, improving the UX for everyone. I want to provide a Workbox for the tool builders, that contains everything they need to build beautiful tools for the software engineers.A workboxis more than just tools:

As we saw in my last blog, the current tools do not help the teams provide delightful software. They are old and require the engineers to think about the tools rather than what they are making. Usually, engineers do not build their own tools, so providing tool builders with a Workbox of tools, patterns, and methods that improves UX for the engineers will enable them to deliver better solutions for their customers.

The Workbox

The Workbox for tool builders will include:

Tools for checking the UX of the software engineers’ tool set

Methods for designing, reviewing and testing the UX of the software engineers tool set

Notions, training materials and guidelines that explain the why and how of UX.

The UX will not just be focused on what is right for a “typical software engineer” but will also give guidance for the UX required for non-technical people using the tools. These can include managers, business representations, acceptance testers, people who are contributing to the IT project but in a non-development engineer capacity. They too need to use and understand the tools. In my next blog, I will start to form a plan for building the Workbox.