…if you’re developing software, a service, a tool. Not that I made these up – this is very basic stuff. It’s supposed to serve just as a reminder to come back to if you’re stuck in the process. (And for myself, too, of course.)
In order of priority, from low to high:
- Networked rules over isolated
- Open rules over closed
- usability rules over everything else (yes, also over ‘features’)
If you’re developing anything remotely web-related, stick to those simple guidelines and you’ll be on a good track.
(I’ve been involved in developing a content management system for the last 5 years or so. And even now we’re nowhere near the usability I’d wish to have. It’s in my own hands, but restrictions (mainly of time, partly of coding skills) just don’t allow me to make it as axcellent as it could be. It all started out the usual way: We needed a tool to make our own work quicker and easier, and then it started growing from there, so… Anyway, we’re two people developing part-time, so we do have an excuse. And still: It drives me crazy. But it won’t stop us from improving until, at some point in the distant future, it’ll be as good as we envisioned it. So much for my experience there. To cut a long story short: I see these guidelines as a process that keeps improving our tool.)
Just ask yourself:
- Is the usability of your service/tool/software exellent? Are you looking forward to using it? Really? Then you’re on a good track.
- Is it an open system? More people (not just ‘users’) can – and will – join an open system. Also, it allows developers to build nice additional apps, plug-ins, mash-ups. That’s not only cool, it also enhances the range of potential uses. Most importantly, though: Open systems can link more easily into other (open) systems. Think integration. (Don’t forget that open-ness also includes documentation both inside and outside the code, as otherwise it’s unnecessarily hard to really access the code and tool. We’ve been struggling with this from the beginning, as it’s both time-intense and not even remotely as fun as implementing some neat new feature. But it’s no less important, really.) Your thingy is fun and open? Great, time to move on to rule 3.
- Does it network? Now, this is the only rule that might allow exceptions. (But then again: not really) We’re on the web. You’re going to be on the web. Your users are going to be on the web. It’s a network. Use it, and thoroughly. If your product doesn’t network, why is it online? Make it a stand-alone software. Good networking increases productivity and it’s good fun. Again: Thing integration.
There is, you could say, a fourth rule. But this is so general and all-encompassing i wouldn’t even list it above. It’s more like the basis for everything said above:
4. Listen to your users. Let them have a look at your product early. Ask friend. Yes, non-developer friends, too. Do they understand what your tool/service/software is about without much explanation on your behalf? No? Don’t try to make them understand. (a) They’re helping you out, so they don’t deserve to be bullied. (b) If they don’t get it, others won’t, either. It’s not their fault, it’s yours. Re-think all steps before you go ahead. Maybe it’s just the interface, maybe it’s the whole concept that’s faulty. I recommend the “mom & dad test”. Take your parents (or any other not-too-techy person you know who’ll tell you in the face if they think it’s crap) and let them have a look. Do not get in a fight. Again: They’re helping you out here, not the other way round.
If at any step your test users lose interest quickly, or if they get stuck, or if the let you know they don’t like some element or wish another one, fix it or build it.
If you stick to all these simple guidelines and don’t compromise on your users’ wishes, it can’t go too wrong.
