“To throw rubbish in the bin instead of onto the floor shouldn’t really be so hard. Many people still fail to do so. Can we get more people to throw rubbish into the bin, rather than onto the ground”

One answer is to make it more fun.  Check out The FunTheory for other ways of improving mundane products by making them fun.

Now think about that mundane product of yours.  Maybe it is your on-line retail bank.  It is getting tired and it is time for a technology refresh.  You’re going through a process of capturing requirements.  How about playing an innovation game, but base it on the concept of fun.  What could you introduce to your product that would make people smile?  What would make people laugh?  OK, so after a while the bin would no longer be fun.  What makes it fun is the element of surprise.  Again, what could you drop into the product that would surprise people.  What would a ‘fun’ internet bank look like?  Focus on fun and surprise and you might uncover a nugget of inspiration that will make the final product.

If your house was on fire, what would be the one thing that you would save?  (He saved the hard drive with all the family photographs on).

There are three systems that have been developed over the years, commissioned by different business stakeholders with different budgets and different delivery teams. Of each of these systems only a fraction is ever used.  (This is especially true of vendor products that have requirements rooted in the market rather than the specific needs of that organization.  Think about how many of the features in Microsoft Word you use).  If there is significant functional redundancy in the applications, there is also duplicate functionality that results from the different development legacies.  It is not unusual in such a landscape for the user to enter the same data into each system.  Not something you would wish to replicate in a new world.

In building a new application, the place to start looking for requirements is not so much the as-is processes or existing applications.  The place to start is the business intent and what the business actually wants the system to do.  More importantly, that means starting with an open mind and challenging notions of process complexity.  Is the process complex because it really is, or because the current systems make it that way? In my experience, more often than not, it is because of the former.  Spend time with end users, see what they do today.  By asking seemingly stupid questions, taking a starting position that the process is simple and challenging ‘why not?’ can yield valuable insights.  By all means consider the as-is world, but don’t let it cloud your judgment in designing ‘to-be’.

As an Expert User
Given I have had no training
When I have to complete <insert goal>
Then I will be able to accomplish it in under five minutes

As a Novice User
Given I have had no training
When I have to complete <insert goal>
Then I will be able to accomplish it in under seven minutes

Links

Dan North introduces BDD

So here’s the question.  Do people really want to make your homepage look the way they want it to?  Is there a demand for iGoogle and netvibes customisation?  They look cool and are attractive to the geeks in us, but do they have mass market appeal? Is there any research out there on the take up of user customisation?

“…back when Windows 95 was released, users could easily change My computer to something more personal. Apple users had been able to do this for many years, and many of them did name their computers. But few Windows users took the opportunity to do this, suggesting that they saw the computer as more of a tool than something with which they wanted to have a personalized relationship.” (David Malouf)

Just because we can doesn’t mean that we should.  When you log into your bank account it could look like netvibes, complete with BBC news feeds and YouTube videos (you decide what you want).  But should it?

Why should your customers see your website as something to have a personalized relationship with, especially if you don’t engage them with a personal relationship throguh your other channels?

In a single image you can convey a simple concept, an idea, a need or a desired outcome far quicker and more accurately than writing it in a sentence.  This is especially so in developing software which more often than not is visually manifest as a user interface.

When we captured requirements in agile, we are effectively conveying a simple concept, idea, need or desired outcome as a requirement.  And we do it in words.  Those slippery things that are so often misunderstood.  Things get really slippery when we try to prioritize those words against each other.  Stories are laid out on the table and the team spend as much time discussing what each story actually means, as giving them priority.  And because they are supposedly independent, you loose the inter-depedencies between them.  Jeff Patton has written some great stuff on this.

So prioritization with stories can be flawed, especially when you are working with a large volume of requirements, say at the outset of a programme of work, and what you really want to do is get an idea of what a first release should be.

Throw out the stories.  It’s too early to be writing words.  Muda.  Create illustrations of widgets and features and functions.  Sketch out on post-its illustrations of the simplest implementation of the concept, idea, need or desire.  On flip chart paper create blank screens that illustrate the interfaces that the requirement will be manifest on.  Identify the stakeholders who will interact with the requirements.  For example the retail website, the operational support application, the finance system.  Now ask the team to stick onto the screens the sketches.

The challenge is to strip back to the minimal functionality that they really need for that first release.    Let them draw extra functionality if they like, but everything must be on post-it notes.  Now pull the post-it notes off, one by one.  What if we removed this? What would happen if it wasn’t there?  Is there something simpler we could do?  Something more elegant?  Is an operational function required to make the website function work? The exercise may be extended with pictures of legacy applications and data elements, again, stripping them back to the bare necessities for that first release.

That didn’t take long did it, and it looks like an initial release candidate. We’ve defined our scope in a way that we do not believe we can cut any more.  Any less functionality would not be a meaningful release.  Now we can get down to writing the stories, focusing our effort on something we are agreed looks right.  We’ve prioritized pictures, outcomes over words; Picture Driven Design.

Just in the same way that it takes a car time to accelerate to a meaningful speed, so a project takes time to reach it’s planned velocity.  To reach 60 miles an hour takes ten seconds and means moving through the gears.  You don’t put your foot on the accelerator and suddenly find yourself doing sixty.  Nor do you put the car into forth gear and expect to move without stalling.  It is the same in agile projects.  Velocity is misunderstood; you cannot expect to have your planned velocity immediately without acceleration.  Similarly, putting a fall sized team onto a project is like trying to start in forth gear.  You will stall.

When planning an agile project you need to consider acceleration.  The first iterations will be slow as you come up to speed.  Secondly you need to be in the right gear for where you are at.  Start in first (small team) and change gear (ramp the team up) as the velocity requires it.  Better to have the engine screaming in first (change gear) than to have it stall before it’s even got going.

Sadly, this means the simple pictures on burn-up and burn-down charts are wrong.  They need to take into consideration acceleration and appropriate gearing.  And that is advanced maths.

Firstly the Halifax.  Listen carefully to what happens after you key in an option.  You here a key click.  You are then prompted to enter your account number.  “thanks” the voice says, “I’ll just enter that”.  And you hear a clackerty clack of data being entered into a keyboard.  BUT YOU ARE A MACHINE!!!  It is a nice touch, but it is trying to make an interaction that is clearly not human more personable.

Second example is the Financial Obudsman.  “Thank you for calling” says the voice.  Not a stock, model voice, but a real voice, “I hope we’ll be able to help you. My name is Walter Merricks and I am the Chief Ombudsman…”   The message is clearly a recording.  There is no attempt to be anything but a recording, but giving the voice a name and explaining the nature of IVR is a real human touch.  Even better, the narrative about recording the call- it is not scripted from the IVR manual.  It talks to the customer in language they understand.

If you must be mechanical in your communications with customers, be human, be transparent, but don’t try and pretend to be what you are not.

Links
Halifax | Financial Obudsman

Shareholder value means nothing if the organisation doesn’t provide value to the customer.  Yet  I see far too many organisations who fail to grasp  the importance of their customers.  They prioritise their internal processes and policies to the detriment of customer satisfaction.  They focus upon narrow propositions that represent organisational silos rather than meeting the broad needs of the customer.  Innovation is morphed into ‘requirements’ that are performed by ‘actors’ in multiple volumes of ‘use cases’.  To my mind, too many organisations are struck down by corporate Guillian Barre Syndrome.  The brain knows what is going on but is powerless to act.  It feels pain, it senses something is wrong but is paralysed, it cannot move.  Prisoner in its own body.

If that is the diagnosis, what is the cure?  There are many, but a starting point would be to place the customer at the heart of your design.  Don’t start any proposition without the customer experience at the core.  Create personas and walk through customer journeys.  Use scenarios to develop your thinking.  Broaden the scenarios to introduce what-if models.  If it is an internet offering, sketch out the screens, if it is a service, sketch out the touch-points with your people, processes and technology.  Don’t allow the proposition to be talked of in the abstract, work with the concrete.  Would a persona accept the experience your proposing? Would she accept that pricing model? Does that journey make sense? You do not need to spend weeks and months documenting the exercise.  A couple of days with the right people in the right room with white boards, post-it notes and business-speak banished from the proceedings should deliver far more fruitful insights than playing document-tennis with revision after revision after revision. You may even kill the proposition before you invest too much time on it. Or better still identify a better, customer-centric proposition waiting in the wings.