Feature Promises

After reading (aka. skimming - it's a long article!) this article [gearlive.com] today, it made me realise that the problem of developers making functionality "promises" isn't just a problem with games.

This article is just a collection of my thoughts on this matter.

Introduction

Slashdot [slashdot.org] was running an article [games.slashdot.org] today talking about some folks and their musings on developers and publishers overhyping games [gearlive.com]. Pretty much, they look at how this "Overpromising" can ruin the end enjoyment by the players, directly due to their heightened expectations of the game.

Combined with the fact I had a meeting earlier in the day discussing someone doing some developmental for work my current project, this started me thinking - this problem isn't just reserved for games.

Great Expectations

Game players are a fragile breed - to me, they seem to be a fairly picky bunch (me included) and even worse, they seem to bear a grudge - if they don't like the first game, chances are they're going to be somewhat apprehensive about buying the next one you release. This is by no means a scientific or statistical statement - this is just from the way I know I purchase games and from what I have seen from my friends. Worse still, if one person buys a game and is disappointed, most of the friends just won't bother (for whatever reasons - whole new can of worms in that statement!). On the contrary, games that are great will be played times over, recommended to friends, etc.

The same holds true with other development too!

Example: Max Payne 2

I don't want to go into much details (this isn't a game review, its a commentary on development!), but I loved Max Payne 2. Perhaps it's because I enjoyed the first so much, perhaps it's just because I loved the storyline. Perhaps it just lead us a little bit closer to closure of the story (I can't stand stories that have no conclusion!).

Then again, perhaps it was because it was better than I expected, mainly because I had no preconceived notion of what I was expecting. Unlike many people, I don't find it enjoyable to know the plot line, features, etc. of a game before I play it - I'd much rather discover them as I go. It makes it more exciting; and I know I can't be disappointed by thinking "Wow, I expected the Colt to be better".

There is nothing worse than getting a game that you expect to be awesome, only for it to fall flat. I remember plenty of games like this in the past - sure, they sound awesome, but you download the demo and "Oh My! That's got to be the most boring game ever! It's nothing like what I expected."

"Real" Software

So what can we take from this about developing "real" software? (I don't use this term out of disrespect for games developers - more as a "It's 1am and I just want a simple term I can use to generally exclude games")

Clients tend to be a lot like those excitable kids reading up about the game in development. You just happen to mention a possible idea, and chances are they'll get it into their heads that it's gospel and it'll be implemented in version 1.X

Million Dollar Questions

I guess the problem comes back to the whole Architects vs. Web Designers [scottmanning.com] argument (points still withstanding for non-web developers).

Often, clients don't know what they want, because they don't know what's possible. They know that they want something to do XYZ, ABC and QRS, but they have no idea how they want it to look, how they expect to use it, or how they expect it to hang together. And why should they - they aren't developers.

Developers know what is possible. They know how things (usually / hopefully) get solved. The client doesn't care if their application uses CSV files or XML files. They don't know how to build a application GUI, or how to design the flow of a website. These are all things most of us (developers) consider to be quite simple (or at the very least, common) tasks of our daily work.

However, all the time, I see frustrated developers saying to clients "Tell me what you want????". How can they!? They don't know what is possible let alone strip out all of the bad choices to decide what they really want. After all, that what they're paying for (hopefully) - your experience.

A lot of developers, designers, etc. seem to forget that they usually ask for the wrong information. You can't ask a client "So how do you want this page to look?". You what? I thought YOU were the designer here - why are they employing you if you're going to ask them how to build their system? Surely, if they knew that, some 18 year old code monkey would be bashing it out right now.

But, they still get asked the questions.

Jumping At Features

We all hate not having an answer - so we do the next best thing - try and synthesise information to answer, come up with suggestions from what we know, or just plain guess. Unfortunately, most clients have at least some idea of buzzwords they know or listen out for.

Woe is you if you are asking these questions to back the client into a corner and make an offhand suggestion about a possible feature.

It's an escape route - "Look, I really know what I want now, you just said it!"

But all that you made was a suggestion.

Preventing Jumpage

So how do we prevent clients from taking a mere functional suggestion, or innocent musing, as a product specification?

Silence

Well, we could not mention these to the client; but you need to get feedback sooner or later.

This probably doesn't constitute a fix, more of just not providing any ammunition. Just wait until the clients 16 year old nephew walks in talking about this new Shockwave stuff and how it's so totally awesome and kickin rad and you really need it.

To quote Strongbad [homestarrunner.com] "Good... Gravy..."

Leave an Empty Expectation

We could ignore when the client "Jumps At Features" and just ignore the suggestion, leaving them with an empty expectation. After all, it shuts them up, right?

Wrong.

This is where the parallels start to emerge with games. The client has an idea now of how they want to see the system. They expect the system to be this way. After all, you did ask, and they did suggest this awesome feature. Surely, you're going to implement it, right?

Apparently not.

Just like the game player, they get upset - the expectation isn't fulfilled and they feel like it wasn't a success. Oooh.. You've just made a flop of a game! Kids everywhere are running back to EB to try and get an exchange right now!

Ask The Right Questions

Who'd've thunk it!?

Instead of asking for how a client wants something implemented, ask them what they want to solve.

The difference is quite subtle, but important.

Why ask a client if they want a 1 column floating content box of news items or 3 columns of news links? Do they really care? Can they really answer?

However, if you ask a client something along the lines of "Now the news on the front page, how many items did you expect, and how often?" might give you some idea on which is appropriate. They're much more likely to be able to tell you what they expect to be able to use the application to do, rather than how to solve it. Especially in the first stages of design.

Plus, it's something they can answer without needing any technical knowledge that they don't have. Last thing you want to do is give them a choice between blurting out an answer or making them look like a fool. Because really, that's the options most people are given - try to answer me with exactly the technical implementation or I'll think you are a moron. That's not a good choice... Ever... Even if they are a moron.

Todays Experience

It was nice today to see a developer doing it right. Granted, we most certainly weren't average Joe clients, and we knew exactly what we wanted, but the premise was the same. It wasn't a matter of "So you want me to write XYZ?", but a matter of "So, you want me to get you from A to B?".

Also nice to see was the developers approach to the job. He outright said (paraphrased) "I want to get what you expect and confirm the brief before I commit - I can't stand when people say they can do something only to say a week later they can't".

THAT is reliability.

THAT is work ethic.

Works well, as that's what I want from his work too. If you can't do the work, I don't mind - I can give you more time to look into it, or I can find someone else. However, if you say you can do it and then come back in a week and tell me you can't, well, good work - you just wasted a week of my project. Let's hope nothing else relies on your work (hahahaha, yeah, as if!)

There is no space for me to be dissapointed - he knows clearly what I am expecting. If he delivers above, he gets extra kudos. If he delivers only what I expect, that's fine too. The point is probably most important that we both know what I expect.

It's a simple task, but I expect certain levels of standards with regard to his performance, code, etc. For example, he knows that I am only expecting inline comments (it's quite a simple task, so anything more would be overkill). If he feels like spitting out more documentation, I certainly won't be arguing. But at least we both have a clear understanding of what I think we are getting.

Conclusion

Clients are funny beasts, but like all animals, you need to be careful not to back them into a corner.

Be careful to ask the right questions, lest they take your suggestions as their own child and you end up building something that doesn't live up to their expectations.

Unfortunately, no amount of technical documentation, design briefs or job descriptions can ever change what someone expects to get out. It's not a matter of what you signed you'd do - it's a matter of what you said you'd do.

After all, the last thing you want to build is the next overpromised game that leaves the player, and their friends, dubious about playing your games in the future. Or worse yet, refusing to buy the game after viewing the demo...