This is the third of a five part series on system design, relying on my own experiences and knowledge from working both in the public and private sector.

I have broken down my thoughts on system design into five distinct pieces: user requirements; development standards; usability (this article), code-cutting, and testing and go-live.

Developer Styles

Bear in mind that each developer will use slightly different development methods and have a slightly different coding style, and that’s before you even consider the fact that different applications written for different platforms require radically different skillsets and can provide a radically different user experience.

So how can we bring all of these together in such a way as to draw any useful comparison?

Simple: I’ll generalise a lot, and make up examples to suit.

Usability standards ought to be mandatory: if whatever application you are designing doesn’t work in a logical and intuitive manner, it isn’t well enough designed. It really is as simple as that. Highly usable systems will result in less errors being made by the end users, they will result in less problems being reported with the system, and they will result in high levels of user satisfaction.

It’s always worth investing a little time in getting a couple of people to give your site or application a going-over: encourage them to try to generate errors by inputting junk data: after all, your users will be doing this at some point so testing it up front allows you to be sure you’ve covered all of the bases.

Things that look the same should behave in the same way

If you’ve got a series of buttons, or hyperlinks, or whatever else that look the same, they should behave in the same sort of way. If one hyperlink is going to take you to a new page, you wouldn’t expect that clicking on a different hyperlink would just refresh the values in a drop-down list, for example.

Things that behave in the same way should look the same

Exactly the same principle as the one above, just phrased the other way around!

Style things consistently

This one can be difficult, particularly if it’s your first application, or it consists of more than half a dozen pages or forms, because there is a natural tendency to want to differentiate between different sorts of forms.

This is normally along the following lines:

“Hey! Why don’t I make the forms or pages about people in green, and make the maintenance forms blue?”

And it deserves the response No; No; No; No; NO!

The reasons for this are two-fold: firstly, if your application is styled and designed consistently, the users only have to get used to a few different types of form, as they will be likely to assume that forms which look the same as one another will behave in the same sort of manner.

Secondly, we live in a time of multi-tasking now. If someone has half-a-dozen windows open on their computer, it’s going to be easier for them to locate your application if they can just think “that one looks like the application” rather than “that one looks like the administration part of the application; or possibly like the people part of that other application..”

Scrolling

As a rule of thumb, I’ve noticed amongst my users that users have an expectation that they may have to scroll down on web pages, but expect paging or tab-based controls on windows-type applications and are more reluctant to scroll down, although users appear reluctant to scroll horizontally.

That’s just anecdotal and I don’t have any statistics to back it up with, so don’t just take my word for it: watch your own users to see if they behave similarly.

If they do, then follow my scrolling rules of thumb:

• avoid horizontal scrolling on any system
• avoid vertical scrolling on windows applications where you can use tabs or paging controls instead
• feel free to use vertical scrolling on web pages

Focus on user tasks

Don’t add bells and whistles to a form or page just for the sake of it, if they will distract from the job at hand, but equally don’t be afraid of adding additional features to a page if they will benefit your users.

Remember to ask yourself on each page or form: why would the user have visited this form? What would they have wanted to achieve? How can I make that easier for them?

Plain English

Or perhaps I should request that you use simplified anglo-saxon verbiage?

Don’t use jargon, technical terms, management speak or legalese. Aside from making you sound like you’ve been developing with a thesaurus firmly implanted up your backside, they just make things more difficult for your users to understand.

If you can’t explain whatever-it-is in terms that a twelve year old would understand, give up on writing the text yourself. Either get an expert in to do it, or get that twelve year old to do it instead.

Validate User Input

It may sound bleeding obvious — and indeed it is — but you’ll get a lot less junk data submitted to your application if you check that the submitted data is valid. If you are using a web-based application, remember to ensure that validation is always carried out server-side (although you can in addition offer client-side validation) as you cannot rely on client side validation.

Summary

These are just some of the tips that have occurred to me through my time either developing or overseeing developments: if you want to look into usability in more detail, I’d recommend taking a look at Steve Krug’s book Don’t Make Me Think, which is an excellent usability primer, or if you want a quick checklist to refer to, remember Jakob Nielsen’s Ten Usability Heuristics.