Brendan McKenzie

Building solid, useful and usable software

Sunday, 17 November 2019

I work for a digital agency, which means that I have the opportunity to work with a number of various clients on a number of different types of projects. The types of project vary not only in their technical requirements, but also in their target audience.

The fact that we are not the end user of the product generally means that usability can be lost along the way.

Work that ends up on my desk has generally gone through a number of phases before development is set to begin. There is typically a pitch that talks to the clients high-level requirements. Then there is blueprinting, requirements gathering and roadmapping which begins to flesh out the actual end use cases for what we are to build. Then we head to design, and finally - development.

Throughout the process everyone - business analysts, user experience designers, graphical designers, etc. - does their best to keep usability in mind, but it is not until you actually build the thing that you can feel how something works, and how it can be improved.

Contrastly, I also part-own a travel agency specialising in African safaris. Here I am both client and provider in terms of technical solutions.

What this means is that when I build software, it directly affects me as I (along with others) am actively using the software and as such am always looking for ways to enhance the experience.

I recently built a tool to help with one of our business processes and found that as I was building it, actively using it meant that I could easily identify potential spots for improvement.

This can obviously lead down a dangerous path where I spend more time tweaking and optimising the tool than performing the tasks that I need to keep the business going.

But that aside, I believe that the key takeaway is that in order for developers (and designers, analysts, etc...) to build quality software we need to put ourselves in the shoes of the end user and see what we are building from their perspective. We need to take on their responsibilities and see how we can improve what we build.