onsdag den 12. oktober 2011

The user is never right


The user/customer is never right – at least when it comes to designing good IT systems. This might seem like a odd statement to come from someone like me that thinks agile is great. Because agile places a lot of weight on commucation and customer collaboration, and most agile methods uses user stories or use cases as their basis for development. And if we base our design on user stories they must be correct, right?

Well, sorta but not quite. In the recent massive amounts of articles about Steve Jobs that have appeared after his death I came upon this qoute: ”You can't just ask customers what they want and then try to give that to them. By the time you get it built, they'll want something new.". I know from personal experience that this is often the way customers act when you present somenthing to them. There is always changes or imperfections, or their problems and processes have changes. I am sure many other developers out there know the feeling.

So if we do not trust the user/customer to supply us with what to do, should we then just do what is awesome? Well, that often do not work either. I found this qoute in a blogfrom CCP about the problems they face when developing (they use Scrum): ”..when we start off with an awesome idea rather than an actual problem we want to fix or a feature that has a clear, functional and necessary goal, it generally requires painful fixes further down the road”.

Does that leave us with a catch-22 problem? We can't rely on customers and we can't rely on what we find awesome.

No – we actually have all the tools needed in agile thinking. As I see it much of the agile way if thinking is based on that the user never really know what they want. We – the developers – need to help them. So lets look at it that way.

First – as agile developers we are always ready to respond to change over following a plan. We know we can not trust the user/customer to know exactly what he wants, so we make short iterations and continiously deliver stuff to the user, so he can see if he can use what we have made – if the system solves his problems.

Secondly we collaborates with the user/customer. This is usually done by frequent interactions with the user/customer to build trust between them and us – we need them to trust that we understand their problems and that we will deliver something that helps them.

Which leads me back to user stories and the qoute from the CCP blog. User stories is a great tool if used correctly. They are however not requirements. They are a tool that facilitates communication with the user/customer, and grounds our – the developers - understanding of their problem. It is not the solution to the problem – the solution is experessed in deployable code that solves the problem.

When we look at the standard template for a user story (*) it has often struck me, both as a developer and business analyst, how often the last part is omitted – the benefit. But that is crucial for understanding the problem that we want to solve. It is the benefit that creates value not the action. So I find that the trick to creating a good solution is to focus on the benefit and how to achieve that and not so much on the action. If we can find a better/faster/smarter action that achieves the same goal surely we will deliver value. But if we assume that the user/customer is right, we often focuses on the action – which is usually also easier, but also leads us much more in the direction to focus on contract negotiation instead of customer collaboration – afterall the system can do all the required actions, right?

In my experience it is the projects that take user/customer inputs as absolute requirements that fail – at least in delivering value. The ones that succeed is the ones where the developer solve the user/customers problem often using novel technology or solutions that the user/customer did not think of. So the user is never right – but neither is you – but that does not matter if you have a little faith and trust in each other and look at the problem and what creates value.

(*) "As a <role>, I want <goal/desire> so that <benefit>" 

5 kommentarer:

  1. Ja, hos Nokia var jeg ofte ved at brække mig, når vores såkaldte user-experience eksperter så insisterede på at tale med slutbrugere om "når vi nu lave denne nye feature, som du aldrig har hørt om, og ikke aner hvad du skal bruge til, vil så så helst have at menuen skal se sådan eller sådan ud?"

    Enhver med lidt omløb i hovedet burde jo kunne regne ud at en slutbruger ikke kan give en fornuftigt svar på hvordan en feature skal fungere, når de ikke aner hvordan og til hvad de vil bruge den. Men som udvikler havde mine ord jo ingen vægt, for de var jo eksperterne...

    SvarSlet
  2. Translation of Anders comment:

    Yes, at Nokia, I was often close to vomitting when our so-called user-experience experts insisted on speaking with end users about "when we make this new feature, as you've never heard of, and have no idea what you need for, will you so prefer that the menu should look like this or like this? "

    Anyone with little common sense ought to figure out that an end user can not give a reasonable answer to how a feature should work when they have no clue as to how and to what they will use it. But as a developer my words of course had no weight because they were the experts ...

    SvarSlet
  3. The user is always right! But if you ask a funny question you get a funny answer.

    It is a difficult skill to extract valuable information from user dialogue and user studies. But you and I as developers are never better sources of business knowledge than actual users. User proxies are a step down the value ladder from actual users but sometimes you have to accept that real users are unavailable.

    When you innovate you have to innovate from user needs not from technology features - or you let luck decide if you succeed or not.

    User stories are just one of many media to express user needs and business knowledge. Sit down a set of technology specialists and developers to develop user stories? That's techie stories, not user stories. You must involve users and customers or at least good proxies to turn the requirements gathering into real business requirements gathering.

    Especially the "so that ..." part of user stories is where you always need users/customers. To estimate business value you also need access to users and/or customers.

    -- EXAMPLE: Extract user neeeds from funny answers --
    "If I'd asked my customers what they wanted, they'd have said: Faster horses!"
    Quoted to Henry Ford - source unknown.
    MicKr: Henry understood the user need: "Faster transport" because he new his potential users/customers. You should ask yourself each time you get a funny answer: What is the actual business need expressed?
    -- EXAMPLE END --

    SvarSlet
  4. Hi MicKr

    Thanks for your comments - I believe that we are in agreement - my post was a provocation aimed precisely at those companies and developers that tries to deliver a faster horse when the user ask for a faster horse, instead of trying to understand the underlying problem.

    I believe they take the easy route precisely because it is easy - as you mention it is a difficult skill to learn to extract the correct user information, and to many I have encountered do not bother and just delivers what the user ask for. It is also more safe - you can always say to the user afterwards: "You asked for a faster horse and you got a faster horse". Which technically is correct but did not solve the problem.

    SvarSlet
  5. Hi Martin,

    I understand what you are talking about exactly and I think that's what my worry was too when I wrote a blog called "I don't know what I want" based on my conversation with one of my coleague. From that discussion and blog I realized that it's not only customer who doesn't know precisely what he wants. It's actually a general human problem and that's what I realized with that discussion with my coleague. Please take a look at the blog http://sampreshan.svashishtha.com/2011/05/09/i-dont-know-what-i-want/ and see if it makes sense.

    Kind regards,
    -ShriKant
    http://www.svashishtha.com
    http://twitter.com/vashishthask

    SvarSlet