Introducing a Key Functionality Change
Whilst recently driving home from our Butterfly Christmas party I discovered at entirely the least opportune time that Google had seen fit to make a pretty impactful functionality change. (Don’t worry this isn’t another Google rant, I got that out of my system back here). I regularly use the ‘Go’ functionality which enables me with just a couple of taps to get live directions to my home. This time I’d turned it on primarily for the benefits of live traffic information. I was on a route I was very familiar with, it was fairly standard motorway, A-road, city link road fare. Whilst trundling through oncoming snow though I learnt that Google wanted me to leave my very straightforward easy route (which was ideal for my dance-induced aching legs) and head off onto a cross country A-road & lane focused pathway. All of this was being introduced under the guise of the new feature “Prefer fuel-efficient routes”.
The specific merits of the actual functionality I am not particularly interested in here. Rather it is the way it was introduced into the application and how, as a user, suddenly my expected experience had suddenly changed. In my particular case this was a bit disruptive. I had turned on navigation just for the benefits of potentially avoiding adding myself to a long queue of traffic. In the moment I had to interact more with the app than intended and without explicit visual indication infer from what I could see the reason why the app was acting differently than I had expected. Basically it felt like suddenly the app was not behaving as it previously had and it wasn’t clear why.
My guess is that at some point one of two things had happened:
At some point, likely to be an earlier occasion when I was starting a journey, a splash screen was flashed up indicating the change and I had not given it proper attention and just quickly pressed an ‘ok’ button so I could get on with what I wanted to do.
At the start of my journey Maps had popped up one of their timed “we’re changing the route to do this, please press no to opt out.” I had then either not seen it (which is fair enough, I was rightly watching the road!) or because I have audio notifications on silent I had missed being alerted to it.
So in both those scenarios that is a case of human error right? An example of users not using the software in the way they should have? I don’t think I am just defending myself when I say I do not think that was the case. I think the mistake here was Google not giving enough thought (or testing time?) to how users will interact with Maps and therefore will be caught unaware of a change in functionality. My guess is a lot of people will use Maps’ navigation feature like I do, opening just before starting a journey when as a user you’re thinking about plenty of other things and really not in the headspace to be wanting to mess with app settings.
The question needs to therefore be asked then - what is the best way to introduce busy, distracted and experienced users with functionality changes that will have a real felt impact? The best answer is probably different depending on the context. With the kind of systems we make at Butterfly we will typically have direct access to our users and therefore can workshop changes in advance, gaining feedback and input meaning new functionality is never an unwelcome surprise but rather a much desired new feature. In other circumstances probably the slightly more onerous form of splash screen is necessary, the kind where you need to scroll a bit and then pick between a number of valid options rather than just between a flashing blue OK button and a grey uninviting NO button. That doesn’t feel like the best kind of user experience you can provide though and certainly does not take into account that a hurried user doesn’t want to fight through option selection.
A lot of software can ultimately be classified as being a tool, made to enable its user to achieve a task they would be doing anyway but now maybe can be done in a more efficient and satisfactory way. The fluid nature of software in our new Cloud era means unlike the tools of old we can constantly be shaping and updating our tools to do the job better than before. Getting (indirectly or automatically in the background) feedback from users and then knowing how to use that data is probably key to solving this problem.
