Users are people, too.
January 16, 2019
The conversation with our Development Manager started well:
yes, it's possible. But...
Ouch. I could have done without that "But"...
We were a day away from launching a free trial version of our software, to 500+ schools who’d signed up from a successful Facebook campaign we’d run earlier that month.
But, having heard that “but”, I knew what was coming.
...anything is always possible. But ‘anything’ takes time and, more specifically, what you’ve asked for will take 2 to 3 weeks. Oh yeah - and we also can’t start for another 2 weeks.
Wow. That was worse than I thought.
The problem was - on the face of it - a minor one. A bit of background: our online offering “Mighty Maths” is a programme which, at its core, has the belief that children will engage in targeted maths fluency practice better when they’re alert and invigorated.
A central element of this process is the delivery of a selection of physical activity videos, streamed into the classroom, which primary school children then watch and copy - before immediately getting on with some targeted maths practice.
From experience we know that certain children in certain classes will end up preferring some activity videos over others - nothing unusual there. So, we wanted to cater for this by enabling users - sorry, primary school teachers [must not forget: “users are people too”] to create their own unique playlists made up of the videos they like best.
Our error was that we’d overlooked some of the more intricate permissions restrictions required - in plain English, that means that if a teacher in, say, Cromwell Junior School created a playlist, that playlist would be visible to all schools with a trial subscription.
What’s wrong with that? The more options the better, right? Wrong. With 500+ schools taking part, there’s a high probability that before long the entire dashboard gets cluttered with user-generated playlists - creating unplanned load - each of which is also named… er… personally... “Testy MacTestList” anyone?
Problems like this crop up. It’s normal within software development. Requirements change, and the journey from ideation to realisation is a long and winding road. Disruption, whether positive or negative, is to be expected - indeed it should be welcomed, if it makes the product better (without holding it up too much).
So, when I’d asked our Dev Manager whether it was possible to sort out the issue I’d only just discovered, I had phrased it badly, and he knew that. What I really wanted to know was what we can do about it now. In fact, after toying with me with his initial “ideal-world” answer, he then talked me through the workaround which he’d already stepped through and sense-checked prior to my even being aware of the problem.
Working through issues with workarounds is fine. Managing them isn’t always as easy as one might think, but as long as they don’t preclude the opportunity to pursue more elegant and efficient long-term solutions, then not only are they fine, but they're what often happens.
And whilst users don’t always understand this, they often do.
Because after all, users are people; and people appreciate it if you talk to them.