Back in February, I wrote about the battle between the big endians and the little endians, between those who see service design as an engineering problem and those who see it as a customer agility problem. Like most battles, it should be an unnecessary one.  It’s pretty clear that both sets of skills and perceptions are needed for any real prospect of success, so the interesting question is why that’s not more self-evident than it appears to be.

That problem has long been a real and important one in the commercial sector (which is not at all the same as saying that it is recognised and addressed on any consistent or comprehensive basis).  The public sector has been more able to duck it, because it hasn’t tended to care very much about the quality of the user experience it delivers, but that excuse doesn’t have much of a future.

Markus Smet has what I take to be a closely related thought, from a slightly different starting point:  the impossibility of a linear engineering mindset, applying the heuristics of past software solutions to new software problems.  He talks about something he calls ‘bounce’, by which he seems to mean the communication gaps between users and usability designers on one side and software developers on the other (though I didn’t find it altogether easy to work out whether that is quite what he means by it).

Bounce is a consequence of how developers work.  Developers need sophisticated puzzle solving skills and linear thinking to execute a process in a way that’s logical.  This approach encourages people to form habitual ways of solving problems.  Consequentially, once a developer has figured out a way of doing things, they can do it more quickly next time.  What’s good for one client becomes good for the next.  Software is a language and as with any language, people develop patterns of communicating that are familiar to them…

Bounce in software projects is unavoidable, because we can’t avoid being human.  Which means that bounce can squash the best attempts at defining user requirements as developers take more familiar paths to solving the puzzle you have given them.

Smet’s solution is to embrace and manage bounce.  He suggests the use of prototyping, and organising work to ensure that each development bounce delivers something – if only small – of real value.  I rather wonder whether even that is enough though, given his observation that developers inherently think differently from users.

Perhaps we just have to build things twice:  once to deliver the front end we want; then again to ensure that we have the back end we need.