Showing posts with label features. Show all posts
Showing posts with label features. Show all posts

Wednesday, March 19, 2008

We're gonna implement that cool feature! Great, but who's gonna use it?

Assume you're a programmer, part of team A to develop product B. You have release X.Y.Z coming up in 2 months, and there's plenty of features to develop. So, lets make up the list of features to develop, for release X.Y.Z.

A lot of companies these days are democratic - they will create some great meeting(s), involving all the team, and then deciding what (features) to implement next. Then, go ahead and do them, and as release approaches, well, just drop some features (those too hard to implement).

Sounds (too) familiar?
Well, I'm here to tell you - it's wrong!

No matter how democratic a company is, when deciding the features to implement, this should be up to the User Experience department.

Why? Because programmers will just choose the features that sound coolest for them to implement, not with the benefit to the user in mind. It's very hard for a programmer to think like a user, and even if you think you do, you're too close to the code.

The features should be in line with your customers' needs, and the priority of the features should always match those needs.

The challenge for you, the programmer, is to make it happen. It's good to be under a bit of pressure, so that
  • you'll talk to the User Experience department to understand what this feature offers the user, to implement it right
  • you can focus on using the best tools (as opposed to subjective thoughts like, I'm not using Language X because it lacks A,B,C)
  • you can shift focus on getting things done. We programmers tend to spend a lot of time blabbering about which technology is cooler/better/etc. - but it doesn't matter. You first need to understand the problem, and then choose the technology you'll use to solve it (not the other way around)

Sunday, March 2, 2008

Think, before doing like the crowd!

It's funny how people do some stuff, just because most others do them. Yes, I'm talking about IT.

Case 1

When developing a site, make sure you do a "captcha", wherever.

For Night Buyers, I've added captcha, only at login, and only after about 1.5 months since we've started it. Why? It wasn't on my top priorities. Captcha is good to forbid bots to register. But that happens only when you have lots and lots of users. Which is certainly not when you start the site!


Case 2

Validating the user's email. To do that, you send an email to the user, with an activation code. The user opens his email, clicks the activation code, and there you go.

First, this is a lot of code from your part. Then, it puts a burden on the user - he's using your site because he needs something. All this mambo jambo, and he can lose 10 minutes to one hour or so. Not to say that he might just dump your site and go elsewhere.

On Night Buyers, we don't have email validation. We trust the user to provide us with a valid email when he registers - we send him confirmation of his order via email. If he doesn't need confirmation, fine, let him provide a dummy email address.

But, when you develop your site you need to answer 2 questions:
  • Do I need email confirmation? Why do I need the user's email? To send him what?
  • Do I need email confirmation now?
To the latter question, what if you can wait, lets say, one week, for the user to confirm his email address? If so, you can allow the user to use your site right now, and if he finds the information there worthwhile, trust me, he'll be more than glad to register.