Developers who no longer code refer to themselves as going “post-technical”. I’m never sure if this is a badge of honour or not. For someone who is pretty non-technical, I am delighted to announce that I’ve gone “pre-technical”. I’ve got an apache web server running on my local machine with a mySQL server all courtesy of the delightfully simple Apache Friends XAMPP. In only a few minutes I had it up and running (and after an internet basics 101 with Dan North) and a couple of clicks I’d installed Wordpress on my laptop. I can now play around with different designs and start making this website exhibit the sort of production values that I strive for with clients.
As a registered user, I want to change the colour scheme on the web site so that…
Where’s the value in this story? Agile focuses upon business value, and in doing so it commoditise features. The sponsors of the development are invited to prioritise features based on their “business value”. This means that seemingly pointless gimmicks will slip out. And this may impact the overall experience that the sponsors strive for. Yet by commoditising features the sponsor sees how the costs break down. To have functionality that changes the colour of the site will require effort. It’s not going to come for free. And that means that either scope will increase resulting in either increased cost or increased time. The challenge is when you have a sponsor who knows just a little: “changing colour? Pah! That’s a bit of JavaScript and changes to the stylesheet. I could get the code on hotscripts and knock it up in front of the telly tonight…”
And of the requirement to change colour on a site, in fact that whole customisation thing? Until recently I’ve never seen the value of it. After all, how many people have you seen with a personalised theme on their windows desktop, or even just changing the desktop background? One reason people don’t do this is because they are lazy. The call to action to change it is hidden behind a right click, and it’s not exactly straight forward to do. But there’s a bunch of new sites that challenge the user’s laziness. These seemingly pointless customisation features are part of the overall experience. And they work. And by doing that, they add value to the site.
Consultancy is great, you get to see lots of different problems that different organisations and people have. You get to apply the learning’s built up through experience to help solve problems, and sometimes help organisations realise opportunities that they may not have realised possible.
I was recently working with a new client and sat through a presentation by an agile coach from a different consultancy on what agile is. It was great to hear a different slant on the agile proposition and how it delivers business benefit early and regularly. The presenter really honed in on human behaviour. She was suggesting that despite our best efforts and beliefs otherwise, human behaviour is fundamentally unpredictable. The best plans in the world are held hostage by human behaviour…
At the end of her presentation there were a number of great questions from folk more happy in the waterfall space. People who have seen agile and it’s like before - RAD, DSDM etc etc, “yeah, yeah, heard it all before. Agile’s just another passing fad. Then one of the HCI guys asked the question: “in what you have said, it sounds like you would have little time for doing low-fidelity or paper prototypes; a fundamental tool in the interaction designers arsenal of techniques to ensure usability (and acceptability) in design”.
To give her credit, the presenter explained that agile practices are by nature pragmatic and there may be instances where such prototypes may be valid, but in principle she suggested that they should be eschewed.
Something bothers me here. We are quite happy to “spike” technical problems, but possibly the most important part of any software implementation, the user interface, we are happy to let emerge according to the developers’ preference? For it to be refined following feedback from each showcase? What if we call the lo-fi prototype, the wireframes a “spike”. Does that make it acceptable to the agile zealots? What if rather than writing code, testing and refining it, we draw storyboards, test and refine them? Get the UI right quickly and cheaply before a line of (costly) code needs to be developed. It helps you to have a shared vision of how the application will be manifest to the customer. It helps you to show what they will be getting in an iteration, what the goal is for a release.
To say that user-centred design is incompatible with agile (which was certainly the impression the presenter left the UI team I was working with) is nonsense. Which reminds me. I’m supposed to be writing a paper to this effect.
Seen recently. A developer at a broadband provider proudly showcasing functionality that enables customer to perform fault diagnosis on their connection. Step one “do you have access to the internet?” Functionally it might work, but did no-one stop to think about the value of this functionality. You need an internet connection to get it to work…
The agile manifesto champions working software over comprehensive documentation. Working software does not just mean that it functionally works, to work it must also provide business value and a compelling customer experience.
HCI. Human Computer Interaction. Whilst I’m an HCI practitioner, it’s an acronym I feel uncomfortable with. It is a discipline grounded in task-based activities with its roots in organisational computing. Now that computers are ‘ubiquitous,’ task based analyses of the way that people interact with technology are insufficient. HCI needs to borrow from anthropology, graphic design, sociology, visual arts, to more beyond the “task” to the “experience”. Human Computer Experience (HCE) anyone?
A colleague did Luke Hohnann’ s speedboat exercise last night. The way she drew it looked a little different to the way I draw it.
Picture a speed boat. Now attach some anchors that are holding it back. Which direction is the boat heading?
The boat is on the left, (travelling from right to left) and the anchor is on the right?
You are right handed. For us special people, the left handed amoungst us, we draw the boat on the right and the anchort on the left. That’s because we think quicker and better at performing complicated jobs.
