As a web developer I notice the flaws in websites more than most. Unfortunately this makes 90% of the internet painful to use, and nowhere is more painful than bad forms.

Today I tried to sign up for online banking with RBS. It was a failure in every way.

Let me start by saying that good online banking is possible. I used Wells Fargo's online tools, and, like pretty much every aspect of Wells Fargo's service, it was done impeccably. RBS could learn a lot of lessons from them.

So let's walk through the recommended steps to sign up for internet banking (I know they're the recommended steps because I phoned the helpline after the form had broken several times, waste of a £5 phone call). Navigate to RBS.co.uk, then click the 'Tell Me More' link underneath 'Log In'. Not an ideal start from a usability stand point — I don't want either of the options and the 'Tell me more' page requires a scan through to find the sign up link. This button doesn't take you to the sign up form either — there's another whole page of marketing text to wade through.

Rule 1 in designing a web form — don't put any barriers in a users way. Marketing text is designed to attract people to the form, not prevent them filling it out. Every extra click you require is business lost.

And then the fatal error: Using your browser navigation tools within Digital Banking will prevent your details being submitted. Please use the buttons provided in our web pages.

So following the recommended steps results in me being reprimanded by the site. Not only that, but the telephone representative reprimands me as well, telling me I 'must have clicked back without realising it'. Even if I had clicked back, I am not at fault. The fault lies with the website's terrible sessions implementation.

Rule 2 in designing a web form — the user is not responsible for your lack of foresight. As a developer you must make your system resilient to different forms of input. Should a user enter a page in a manner you have not anticipated, you are at fault, not them. Error messages should offer apologies, and notify them that the problem will be dealt with. You should not alienate your customers by holding them accountable for the failure of the system.

Rule 3 — Design with knowledge of the domain you are working in. If you are making a website, surprise surprise, your users will have back buttons in their browsers. If you cannot deal with the result of this then you have a terrible bug.

I spent a good 20 minutes on the phone trying variations of the sign up. During this time I had a page timeout, was put on hold three times, and had to wait while the representative checked something with a colleague.

Rule 4 — if your site is not intuitive enough that a representative whose job is leading people through the site cannot immediately tell you what to do, then it is not usable. You are losing money by confusing your users.

At this point my phone died, and I gave up, but previous to making the call I had managed to get through the signup. One thing that irked me was password was required to be letters and numbers only, and shorter than 20 digits. It's a minor thing, but there should be no reason why you should limit the security of the user.

RBS have made the short—sighted decision to identify each user with a number — the users date of birth followed by four random digits. This is terrible usability. Users are people and people are terrible at remembering numbers, additionally by requiring that users use a number to identify themselves, you are indicating to them that they are just a digits in a database — you are alienating them.

Rule 5 — Don't alienate your users. If you have a pressing need to identify users by an integer, then do it on the back end and map a username to it.

As security, RBS require a four digit number along with the aforementioned 6–20 digit number/letter string. I am unsure as to the reasons behind requiring both. Four digit pin numbers, while barely sufficient for ATM use, are completely inadequate on the open web. Keeping them seems like the bad decision of an executive uncomfortable with this new 'web thing'. This also means that there are three hopefully random pieces of data that need to be remembered by each user. I'm usually pretty good at remembering random sequences of alphanumerics (better than with names at least), but faced with remembering three fields of data I reached for a pen.

The more memory you require of a user, the more likely they will do something insecure like writing it down. Although you may have warned against this in the small print of the user agreement, that all of your users will ignore, requiring users to perform memory feats not only reduces the security of the system, but makes your users resent the security system. And users who resent your system are more likely to do something stupid like use a password like '1234'.

Rule 6 — Don't make your users think. If you do, they'll probably repay you by doing something stupid like writing their password down.

What's more, RBS stores the entire password in their database. I know this because on their login page they require certain digits from the pin number and the password. This is wrong in two major ways. Firstly, by requiring random digits from the password, you are further increasing the user's mental load. I expect there will be few users who do not at least mouth the letters of their password as they work out which letter is which. If you only wish to transmit certain digits of a password, then that's about one line of javascript. The argument to do this, I expect, is that it means that there is less chance of a spoof site gaining an entire password. But really, it would take about 3 tries to capture enough data to get in (especially as RBS seems to only query the first 6 digits of the password), and if you capture enough data, brute forcing the entire password is trivial.

Additionally, and more importantly from a security point of view, you are storing the user's password in the database. This is so wrong, it would be bad for a simple web app, let alone a bank. Storing a user's password means that if that database is compromised, you have effectively lost control of every user's account, at every step of the stack.

The currently accepted solution is to only store a salted hash of each user's password, and a user specific salt, meaning the only attack vector is the time consuming re-encryption of the data. Additionally this means that you only ever have to transmit a hash across the wire — the users password never leaves the computer.

One would think that an industry such as e-banking where security is paramount, and maintaining the trust of users a vital requirement, up to date security would be an area of interest. RBS ignoring this is unforgivable.

Rule 7 — Use up to date security. Really this should be common sense. You are not smarter than the security experts, and your pet scheme of requiring certain letters or numbers is almost certainly insecure.

I could go on and on. I've picked on RBS here but many sites are equally bad. As a web developer I'd like to say the moral of the story is that web development is a difficult task, and if you hire incompetence you will be repaid by lost business, an insecure system, and annoyed users, but really I only wrote this article because browsing the net when your job relies on you knowing these things is a painful painful business.