Over the last decade I have developed HMI (Human Machine Interfaces) and SCADA (Supervisory Control and Data Acquisition) user interfaces [amongst many other things] as well as few desktop/mobile apps - one of which made it to the App Store a few years back. As I’m embarking on yet another piece of desktop software development I’ve been thinking a great deal about how end-users (aka customers) see, use and react to the work I do. This is healthy and I suppose, nothing new or particularly interesting. Today I had an epiphany: the problem so often isn’t satisfying your customer, it’s identifying your customer in the first place.

When developing software for a client there are often meetings [sometimes far too many] with different people representing the client and all too often they are not the end users of the product itself or worse, have no experience with what you’re doing. When developing your own software the first people that use the software in question are usually the alpha and/or beta testers. They say a good beta tester is worth their weight in gold by exercise functionality and also reporting bugs accurately: making it easy to track them down and fix them. That’s all well and good but testers like that don’t provide the balance you need. The problem is the selection process for beta testers and for client representatives is usually A) influenced too heavily by ourselves or B) out of our control entirely.

Clients will often “allocate” someone who is interested in the product from the client side and for our own Beta testers we typically choose those within our close circles: i.e. geeks like us. In both cases these people will often bend your ear and say “I’d really like this feature” or “I think this would work better this way”. They distort what your application is trying to achieve. As such, feedback from them will give a distorted view of what end-users will actually think and how they use the end product.

With clients I find the best choice is to request two representatives: one that is well versed with similar products/software in their organisation or the market and one that is going to use the software regularly but is preferably NOT well versed in other similar type software. The balance between their views should hopefully guide the product to a more balanced end result. Admittedly one does not always get a choice, but it doesn’t hurt to ask nicely - they can only say no.

With beta testers, have as many friends (geeks probably) that you like, but try to get older people (aunts, uncles, parents, grandparents) that aren’t as familiar with technology to have a look if you can. They will provide more balance and push and prod the software into places it wasn’t supposed to go. These are the sorts of beta testers people should value the most.

My only other piece of advice is to remember that you are also your own customer. Think to yourself: Am I proud to put my name on this? Would I use this software and recommend it to others? (selflessly of course). If you make a design decision that you strongly believe is right (even against the opinion of one or more of your testers or client representatives) sticking with it is usually the right call. Understanding who your end customer honestly is, helps you to focus. Be careful who you choose as the customer(s) to satisfy. Pick the wrong one(s) and you’ll burn time, money and waste effort. Pick the right one(s) and your chances of success will improve dramatically.