The UX problem with Agile

In the past 48 hours three of the services that I use fairly extensively have had significant changes: LinkedIn’s user interface (UI) has been tweaked, seemingly in their drive to make things look as much like Facebook as possible, TweetDeck’s user interface has been significantly altered and “given a cleaner look”, and the Android phone I use alongside my Windows Phone has had an update (somewhat belatedly) to the most recent version of the operating system, Jelly Bean.

Wahey! New stuff! For Free!! Shiny shiny shiny.

This idea of continual change is central to so much of modern software methodology and to much of the (lean) startup world. But I’m in two minds about it all.

On the one hand, change gives new features, functionality and keeps an app or service fresh. But on the other I fear I might be getting to a point where it’s all getting to be too much, too unpredictable, too much at the same time. I saw someone tweet a few months back that “People moaning about changes (in this case to Facebook) are like old people moaning when they move the aisles around in a supermarket”. Actually, that’s ageist. We are creatures of habit, and constantly provoked changes to our habits are unsettling and stressful.

There was an interesting article here http://www.itworld.com/software/359398/why-your-users-hate-agile-development-and-what-you-can-do-about-it that I came across yesterday that seemed on the face of it to start to address some of these issues, but reading it again this morning it strikes me that there is constant confusion between end users and people who are paying for software development (who may or may not be the same folk). At the end of it all, what is constant, iterative change doing to the overall User Experience (UX) of an app or service? The risk is that it’s making it unusable.

Change is a challenging thing to do en masse. Much of my career has been about implementing change within organisations and most of the approaches taken by the massive online services so many of us use today would have rightly got me the sack in jobs in the past. If the benefit of a system is great enough to an end user, then they will put up with perpetual change I guess, but each change runs the risk of chipping away at trust that might exist in the service provider. That can only go so far.

I’m not sure I can square this particular circle – as I say, I’m very much in two minds about the whole thing. But one element that can help is for the providers of systems to try to hold onto empathy for their users – and to understand fundamentally that sometimes what we see as “making things better” might not be perceived in the same way by the people using a service. For most of us the status quo, no matter how buggy or badly designed, is initially favoured to the new because, whilst it might be crappy, we know its limitations and have built coping mechanisms to work around. Every improvement runs the risk of initially removing a level of self determination from the people who are using the system. Flagging in a timely way in advance that a change is about to happen might be one way to start addressing this…