The boys over at 37signals have put the danger flag up over the following words. Need, Must, Can’t, Easy, Just, Only, Fast.

The following comments thread has been an interesting read. But it does highlight what to do about when you hear these words, and whether they necessarily are bad. I tend to think of them as helping you, the business analyst, or developer, to extract exactly what the client wants to acheive. Harking back to the general philosophy that a client/user (be it a your paying client, your designer, your developer) just wants to get things done, when they can’t the frustration level can start to increase and you start to see these words - by the time you personally get involved things might be getting a little heated…

So, what do they really mean ? And how do we deal with it ?

Take the case of our proverbial user. Our user is tring to do something, our system is (hopefully) helping them to do this but along the way, boom, somebody can’t get past step Y, because it won’t let them enter x. The following call is made “why can’t it just do this…” so what’s wrong here ? Well… maybe the original developer for not figuring out the requirements, or maybe the business model has changed. Either way our poor end user has gotten stuck. And we need to fix it for them.

It’s a mindset shift all dependent on your audience - sure you can continue down the Mr UnPleasant road and not deal with it. However, if you’re an enterprise system where things have to get done, no matter what. Then simple, get down to business. If you’re running a public web app with a wide audience you’ve got a tough decision on your hands to make.

So what do they really mean?

“I just need it to do X, I can’t complete my task”
[translation: I'm trying to do something, I know what I want to do, and I think I know what the software needs to do in order for me to do it.. so I'm telling you what you need to do, I think this will speed up the process if I express it to you like this]

First off, before saying yes or no, it’s part of my job to figure out what they actually need. Nearly always I ask these key questions.

1. “What are you trying to acheive?”
2. “What’s the steps they took to get to X, so I know context”
3. “How did you do X before today ?”
4. “If in a perfect world, what would your preferred way of doing this.. ”

All of the above should provide a gold mine of information in helping you to design the best solution, and to work out whether it is really needed, or a work around can be provided.

Okay so after a bit of backwards and forwards figuring out what they want to do, and the best solution we’ve realised that our ‘please just do this’ is a bit of a kicker, we’ve got tonnes of code to rewrite (unless you’re rolling on rails of course!). So do we go straight back to our office and start coding.

No. Not yet.

You now explain to the user what you’ve got planned out in the next short term, all of which will be impacted by this change, and then how long the change will take. Ie “we’ll I’m currently working on the new inventory feature, which I have 3 weeks left for. if I implement this it will take probably 1 week” and ask the really important question “What do you want me to work on ?”

You will be suprised how often the decision won’t be this ‘critical urgent’ problem that was just raised.

Now, if you get the do it now, do everything else you’re working on, and I don’t give a damn type attitude there are two ways to handle it. One involves lots of this stuff and all nighters, the other involves giving them a business card of your competitors. Problem solved, go off and find a client who values your relationship.

Going back to wether those word’s are dangerous, in my world no, it’s just a way of expressing a need. I think the occurence of those words is inversley proportional to the happiness of our client - a good system that is returning value and have content users will see very little of these. A system constantly hindering our users workflow will see a tonne of those words…..