2006

Going pre-technical

  • Friday, 15 December, 2006
  • By:

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. 

What’s the value in changing colour?

  • Thursday, 14 December, 2006
  • By:

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.

Don’t say UCD is incompatible with agile

  • Wednesday, 13 December, 2006
  • By:

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.

Working software that doesn’t work

  • Monday, 11 December, 2006
  • By:

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.

Human Computer Experience

  • Sunday, 10 December, 2006
  • By:

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?

Cack-handed speed boat

  • Wednesday, 6 December, 2006
  • By:

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.

Pictures and narative

  • Thursday, 23 November, 2006
  • By:

Every night I try to get home in time to read my daughter a bed time story. Currently her favourite is Cinderella. The story is short, it could easily be fit onto one sheet of A4 paper (the plot in Wikipedia is just under 800 words). I could even decompose it down to a number of bullet points to fit into a couple pf PowerPoint slides. Somehow I doubt this would engage my daughter. I read Cinderella from a picture book. There are only a few words on each page, I read those whilst she looks at the illustrations. It is from these pictures that her imagination is fired. They bring my words of princesses and castles and fairy godmothers and balls to life.

Similarly when building new propositions, I’m much more interested in drawing pictures that articulate the user journey story. But this blog entry is not so much about pictures to articulate the process of building products. It’s about PowerPoint.

I have a bit of reputation as a PowerPoint monkey. Whilst our developers build code, I spend a lot of time building presentations on how they will do it. All to often I see slides that have been crammed full of words. There is often an unwritten rule that considers 20 slides to be a maximum number in a presentation. The rationale? An hour long presentation, say three minutes per slide and pow! Time up!

First slide title “Background”. A dozen bullet points on the history of the project.

This is like telling Cinderella from an A4 sheet.

I’ve been inspired by the Lessing method; tearing up the 20 slide convention. A PowerPoint presentation should be like telling a story. Just like the picture book of Cinderella engages my daughter and her imagination with pictures, the words being a cue for the narrative, so a successful presentation should have a narrative, supported by images and carefully chosen points. And if that means a slide deck with 100 slides so be it. Take a look at Dick Hardt doing this for real. Awesome!

The product is irrelevent. It’s the customer experience that pays the bills

  • Friday, 17 November, 2006
  • By:

Why do organisations exist? To make money.  In corporateSpeak “to add shareholder value”.
Where does money come from to deliver shareholder value? Customers.

Many organisations seem to forget this slight detail. It gets lost in the internal machinations and politics.
Why do individual funcitons exisit within an organisation? Marketing, product development, IT, sales, operations… None of these add shareholder value make money in themselves. Yet in all too many organisations these different functions behave as if they exist for themselves, they are entities unto themselves. Each entity may pay lip service to the “customer” but how joined up is the reality?

How familiar is this.

The product team identify the need for something, based on anecdotes from the sales guys, or something they perceive to be wrong with the existing product or a hunch about a potential niche in the market. A niche in the market but is there a market for that niche? A bunch of requirements are written up and an optomistic benefits case is written up. There are x million widget users in the market place. Y% of these would benefit from NewGizmo. We project 10% of these will buy at a price point of £z. The requirements are thrown over the wall to IT to put some development costs on the project. The project has yet to start and a launch date is set in stone. And a project manager has yet to be assigned. Marketing are brought into the picture and tasked with how are we going to sell the product. Development starts (the new project manager is aghast at the scope and timescales he is inheriting). Operations enter the project and throw water on the fire. There a whole bunch of compliance and business as usual considerations that only now come to light. Relationships become tense as the project manager tells the product team that they can’t have what they want by the date they wanted it. The date has been set in stone, so the product team throw out some of the initial requirements, based upon an argumentative workshop on Thursday afternoon (noone bothers to refer back to the initial benefits case, even less any thought of how their decisions impact the overall customer experience). And inevitably a cut down NewGizmo is launched to the market a month late and sales are nowhere near what was projected. What we need is NewGizmo 2.0 and so the cycle starts again…

What if we put the customer at the heart of the organisation.  What if everything we do is motivated by serving the customer?  What if we forget all about our products and focussed upon what our customers’ need and how we can delight them.  What if the products become an enabler to a compelling customer experience, rather than an end in themselves?

Isn’t shareholder value all about generating revenue? Isn’t revenue driven from customers?  Aren’t customers driven by compelling experiences rather than mediocre hassle?

Clarity in objectives

  • Thursday, 16 November, 2006
  • By:

Too many IT projects have vague buzz-word objectives.

  • “Single sign-on”
  • “Legacy refresh”
  • “Migration”
  • “Porting”
  • “Global Tick database”
  • “Unified platform”
  • “Cross channel integration”
  • “Content mashup”
  • “Real-time la-la”
  • “Streamlined processing”

These aren’t objectives. They are recipee for confusion, lack of clarity and focus. Better to think in terms of customer journeys, what is it that an end user want’s to achieve, end to end, and focus on delivering real value to customers, rather than trying to deliver some amorphous, mamouth “implementation” that does a lot of something mediocre, and little of anything great.

The project see-saw

  • Monday, 13 November, 2006
  • By:

Most organisations have separated their IT function with IT offering their services at a price. There are good reasons for this, but it is not without its issues. Prashant Ghandi has written some good stuff on this. All too often the separation is more a divorce. This manifests itself in the “business” creating projects (hopefully with clearly defined benefits) and throwing them over the fence to IT to deliver. This would not be an issue if the project is founded on a solid benefits case, with benefits matched against project costs. But all too often the relationship is like a see-saw, with benefits and costs bouncing up and down and focus on the business case is lost. Far better to work together in partnership, building the business case together, focussing upon delivering strategic value to customers rather than balancing the project on a fulcrum of mistrust and compromise.

Project in balance
1 of 9
123456789