This is part of an ongoing Series, “Joel Of All Trades”. It’s named after a little-known guy, Joel Spolsky, who has some kind of online journal or something.
In addition to the core functionality of your product (You know, the important bit like What It Does) there are a number of questions that must be answered.
For some Products, the answer might be a flat out NO, but they should all be at least considered.
These questions are vital for both Desktop and Web systems.
1. Registration
Can the User Register themselves with you?
This means asking yourself if you care about tracking Users. There are some situations where you might not want to, but I’d reckon most of the time you definitely want to be able to have some kind of User database.
Reason not the least of which is that you can strike up a conversation with the Users, on an individual level, given that your Registration functionality should capture their email address.
2. Activation (Trial/Full)
Does your Product need to be Activated?
If you’re selling a Product, you probably want some kind of Trial version. This helps the User figure out if they want it. Course, you could be awesomely popular and not have to worry.
For the rest of us Trial versions have to be Activated. And you should definitely have Internet (in addition to the User entering a code from an email) Activation.
3. Security
Can the User login to your Product?
The real question here is whether your Product is completely open, or not. If not, then you need User Login functionality.
A problem with having User login functionality is that it creates a sense of Security in the User. If they use a really simple password, this is bad.
Making the User more aware of the need for a really secure password is paramount. You don’t want to force them (maybe), but you want to make it very clear (and not just when they create their password, but at regular intervals) that their password is lame.
4. Data Encryption
Do your data files need encrypting?
If your program contains any kind of sensitive information, you should be encrypting your data files. Even if not, you should consider doing so. Your Product is Your Product. Don’t give away anything you don’t have to (like structures and wotnot).
To protect data structures you obviously have to encrypt the entire file, as opposed to just certain sensitive fields. Really, if you have the ability, do the whole file. Can’t see any benefits for certain fields, unless it’s for human readability of the raw data.
5. Backup
Can the User back up their data?
This is a big deal. Giving the User smart backup options means less outlay for you at Support time. I’m not just talking about zipping up the data files when they press a button (not that there’s anything wrong with that, heh).
Backup and restore should be seamless. Corruptions will happen. So plan for the eventuality. Charge the User another $x/month for the Product to send backups periodically to your “Backup” servers. Ask the User if they’d like to backup at certain points. Find some external hardware backup options, or at least put up some Help articles (videos) on using other methods of backup.
Users will not backup on their own steam. That’s a general rule of thumb because it’s true for the majority. So take the ability to decide out of the User’s control. Or rather, give them one decision to make (like When is the program going to backup, or Would you like to send your backup’s to our secure off-site servers?).
6. Import / Export
Can the User Import/Export data?
Are your Users coming over from other Products? Would they have a big Excel spreadsheet chock full of data? Can they get their data out for further Services that your Product doesn’t provide?
When you start talking about Development APIs (which are all the rage with Web Services like Facebook, Twitter and FriendFeed) it’s really just giving this functionality in another form.
Put and Get.
7. Support
Really a no brainer. Every single Product should have some Support system. Whether it’s an email address or a big system (like Kayako), you need to Support your Product.
If for no reason other than to give a better understanding of how your Product works out in the wild. Users will always find ways to push your Product that you have never thought of. Just is.
With my new Product I’m using Get Satisfaction. It’s a web service, off-site (I’m not in charge of the data, or functionality). I’m trying it with this Product because the Product is small and I don’t have the time to put together a system with the same level of functionality.
I want my Users to be able to search for questions/answers other people have asked/given. I want them to be able to suggest new ideas for the Product. And I definitely want them to report issues.
8. Help
In addition to Support, do you have Help? Pressing F1 is pretty much ingrained into our consciousness.
So make good use of that pavlovian response. Start putting together a simple Help file. Screenshots and instructions. Having a good Documentation tool like Help & Manual or Dr Explain goes a long way.
But more, you can meld your Help together with Support, so that for a User finding the answer to a problem is done in the same place as getting instructions of doing a certain job.
Wow. That’s quite a number of important questions. It always amazes me how much I forget in the process of developing my own products.
Thanks for reading!
Which of the above Questions do you think have no relevance to your Product (and Why)?