Yes, the pesky creatures that break your code are often worth listening to
I used to share an office with the most amazing user of all, who could slay the most stable code with just a flourish of the mouse: I’d never seen a compiler* fall into an endless loop with an eternally spinning Cursor of Doom until he did so by making a simple error in his program code.
Users also have a habit of avoiding innovation – or, more accurately, of not realising it’s an option. Blue sky thinking isn’t a concept that many can deal with: ask them what they want the new whizzbang app to do and they’ll say they want the same as they have already but faster and less crashy.
Techies, on the other hand, are often quite good at coming up with fun new things because they know what their tools can do; the downside is that these fun new things tend to be neither saleable nor useful to the common person.
On the face of it, then, it’s not all that sensible to get the users to help with the development of your new systems: they are uninventive and they’re likely to break them. Of course, the reality is quite the opposite.
We’ve said that the users aren’t in the habit of innovating, but what they do bring is the ability to listen to an idea and say: “That’d be really useful” – or, for that matter: “Why on earth would we want that?” Put them in front of a techie who can bounce cool stuff off them and there’s a good chance you’ll end up with some promising ideas.
They also bring with them a wealth of knowledge about what the current system does, and particularly the elements of their job that it fails to do. Although the average user is probably not an innovator, he or she may well be creative when it comes to ways of speeding up how the old system works, or finding workarounds to things that it doesn’t do.
Put on your business analyst hat and spend time with users and I guarantee you’ll learn something about how to step around the drawbacks of the company’s systems – and sometimes you’ll be scared to death.
My favourite example of the latter was in my consulting days when I sat with a user in a client’s billing team watching how we dealt with customer invoicing and invoice queries. Turned out that some invoice adjustments were done using a PDF editor on the invoice itself rather than by changing the finance system and generating a new bill… which instantly explained some of the thankfully minor discrepancies we were seeing between bills and revenues.
What the users also bring is the less obvious requirements. Performance, for instance, is often forgotten when writing the requirements for a new system – if I had a tenner for every major rollout I’ve seen fall flat on its face performance-wise I’d have at least 20 quid. It’s something I focus on a lot because it happens to be an area I’ve worked in, but it’s easily forgotten, and it is also often difficult to define precisely what constitutes “good” performance.
But give a user a prototype and ask them to use it and you’ll instantly know where it sits on the scale from glacial to amazing – and once the user is happy you can start defining and measuring parameters around stepping through the screens and programs and then write the necessary test cases.
Look and feel is another thing that’s hard to specify without interacting with the users, because it’s difficult to describe what you want (“It needs to be intuitive, attractive and easy to use” – ah, thanks for that) – so here you get the GUI design people to work with the users, see how they use the existing systems, and throw options at them to try out and rate in terms of usability. You can’t design a usable system without several approaches and at least a few iterations with the people it’s aimed at.
This brings us to the next benefit in engaging the users: they are great testers. They know their way around the company’s operations, how the products and customers work, what the simple and complex test cases are, what’s normal and what isn’t.
Now User Acceptance Testing (UAT) is a core component for every good test regime, but it tends to fall right at the end of the development/test process because you don’t get the UAT people in until you’re reasonably happy the system is working correctly. But perhaps by engaging the users in the testing process you can bring failures further up the development chain and nail them earlier – so long as you can deal with the problem that users think they know it all and don’t follow the test scripts.
There’s one final thing that I will mention before heading off on a crime against language: shadow IT. Yes, users are creative when it comes to finding “optimisations” to your corporate systems, and while this sometimes means they’ve got funky Excel macros to automate tedious key sequences, it also sometimes means they’ve gone out and found (or, worse, written) entire separate programs that they use instead of the company systems. Engage the users with people who can combine the functionality benefits of this “shadow” development with a proper, controlled development team.
All of this makes me think. You’ve heard of DevOps (in fact I’ve written about it more than once), which is all about engaging the Operations team with the developers throughout the project so that when go-live time comes the Ops sign-off is easy because you’ve developed according to their ongoing advice. And you may even have heard of DevSecOps: like DevOps but taking the security team along for the ride for similar reasons.
The inevitable new CamelCase term…
So… UserDev? DevUser? ShadowDev? They all sound dreadful but one can’t help thinking one of them might be next for the IT glossary. ®
*The Metrowerks Modula-2 compiler, if memory serves, and he’d not closed the definition of an Enumerated Type properly.