Consistency in Web UI Design

How to keep your software's UI consistent when many programmers are working on the project.

In a development team with half a dozen programmers all working on the same project, creating a uniform user interface can be a nightmare. There can be problems ranging from inconsistent use of icons to language (e.g. formal vs. informal). So the question is, what's the best way to achieve a cohesive user experience?

Few would argue the importance of UI design these days, especially since companies like Google and Apple have spoilt users with dazzling almost joy-to-use interfaces. But a functional application is still more important at least initially, you can always pretty things up once your software actually works.

When working as a UI designer, it was my responsibility to create mockups for the application being developed. Once I had created the HTML and image files in Web Expression and Photoshop, all I needed to do was bring them into Visual Studio as Master Pages. This worked out great because the programmers would then come along and add the logic.

This turned out to be an excellent approach since it doesn’t require a style guide or volumes of documentation. It works because just one person was in charge of the UI design. The reality is most companies don’t hire someone specifically for a UI role, although more companies are starting to (compared to a few years ago).

Having worked as an IT project manager for a few years now, I have found there is another approach which works well for ensuring UI consistency. Personally, I don’t put much faith in writing UI guides and expecting programmers to follow them. There’s a few reasons for this: 1) programmers often aren’t good at UI design, 2) it’s a lot to remember, and 3) its counter-productive.

UI style guides slow down programmers because you are expecting them to be good at something which they aren’t geared for; they are good at coding, so let them code.

So what do you get when you let programmers do their thing and just code with no specific guidance on UI? Inconsistencies in the interface. This even happens when you provide programmers with mockups to work from. For example, your mockup might not contain the exact wording for an error message so a programmer, quite rightly, proactively puts one in (e.g. “Invalid input”).

What’s the solution? Easy, you have one person review the entire interface at milestones and log bugs in the issue tracker. These bugs would be marked as UI or low priority. If there’s a script error in the software, it’s obviously more important to fix that first before looking at a UI glitch.

The next question is, who should be doing the interface review? It should be one person only (for consistency sake), and that person should be whoever is the most talented with HCI/UI design.

My point is this, don’t make programmers try and be UI designers. When you log a UI bug, it’s there in the issue tracker, it won’t go away. The programmers will come and fix them when they are good and ready. UI bugs are generally easy to fix so they can act as a good break for a programmer. Imagine a coder has just spent 2 hours debugging a serious data corruption issue. Fixing a few UI bugs would most likely come as a welcome relief.

As far as language or wording in an application goes (e.g. error messages, online help, labels, etc), you wouldn’t necessarily need to log bugs for that. If you are using a string table, or some kind of configuration file like XML, then it’s easy for the UI person to tweak text by directly accessing the configuration store. For example, if you found "login error" in the configuration XML file, you could change that to "the username or password you entered is incorrect".



When things get written down they will be forgotten. This is especially the case when documents get long (e.g. 20+ pages). The problem becomes compounded when you realize that programmers could care less about consistent UI across all the screens of an entire application. Their task lists often say 'Code login screen', not 'Code login screen - and make it look pretty'.

As a side note, I should say I have written a massive UI style guide for an application I designed. It took me almost 2 weeks to write and personally I think it was unnecessary. It was basically a way for programmers to understand how to modify the interface once I finished my contract. As to whether they found the guide useful or not, I don’t know. I think design should be left to designers and coding should be left to programmers, it just makes good business sense.

Subscribe to RSS Feed.

Quality Test Plan

A check-list for common website errors.

"...if quality costs a nickel extra, you quickly see the true colors of those who would have to shell out the nickel."
- Peopleware, Tom Demarco

It never ceases to amaze me how easily errors creep into the most rudimentary of websites. Even more stunning is that I’m often the culprit (e.g. I’ve almost launched a website with the word Melbourne misspelt as Melboure). You would think that after years of experience within the web realm, I should be getting better at it right? I guess its a bit like taxi drivers, because they spend most of the day on the road, you would assume they would become excellent drivers (we all know that isn’t the case). Whatever the reasons behind these common errors, it’s a given that they will be there, so if you know this, what do you do? A Quality Test may be the answer you are looking for.

How is a Quality Test different to a System test plan? A Quality test is designed to check for basic mistakes common to ‘information driven websites’, mistakes such as; spelling errors, bad grammar, broken links, missing image ALT tags, etc. A System test plan is designed to check a web application for bugs. By ‘information driven website’, I mean your stock-standard web presence (e.g. a company website with sections like ‘About Us’, ‘News’, ‘Contacts’, etc). If you are looking for information on System Test Plans, please see the article Writing a System Test Plan.

One of the best things about a Quality Test plan is how easy they are to make (about 30 minutes or less for a 10-15 page website), there really is no excuse not to do them. The purpose of a Quality Test is to check for; script errors (e.g. a crash occurring on a fill-in form), usability best practice (e.g. showing the user what page they are on), and SEO (e.g. descriptive page titles).

The structure of the Quality Test is simple, its just a Word document where you list every front-end page of the website (i.e. anything which is going to be visible to the Internet public). As far as conducting the Quality test goes, I would recommend getting an independent QA tester to do it (programmers shouldn’t be used as testers). Any problems found during testing should be logged in your bug tracking system, assigned by default to the project manager who can then direct it to the appropriate programmer.



The break-down of the Quality Test document is as follows:

Page Title – you want to ensure each page has a distinct and descriptive page title (i.e. the title that appears in the browser bar). This has a very significant impact on search engine optimisation (e.g. ‘Products – Xbox 360 action pack’ is far better then just plain old ‘Products’).

Max. Data Length – this relates to the fill-in forms appearing on the website. You are checking that textboxes have had their ‘maxlength’ attribute set correctly. This is a danger because you may have a textbox called ‘Company’, and the corresponding database field may be set to hold a 32 character string. If a user was to enter ‘International Shipping Industries’, that’s 33 characters, enough to cause a nasty script error.

Hyperlink Check – you are just checking for broken links. I would recommend an automated tool like Xenu (there are also websites which will crawl your site looking for broken links).

Navigation Check – there should be some kind of indication of what page the user is on. Its very easy for a person to ‘get lost’ on a website, especially when many levels of sub-navigation are involved. Good ways to do this are to highlight the active navigation button and to show a big title on the page currently being viewed.

Image ALT Tags – at a minimum, pictures which aren’t related to the layout should have an ALT tag. This connects to SEO and usability. ALT tags like ‘Picture’ or ‘Photo’ are pretty useless, UI experts say you should put sentence-like descriptions. For example; ‘Photograph taken at base of Mount Everest showing light snow coverage’, but I can’t say I’m a big supporter of that, I would more likely go with ‘Photo at Mt. Everest’.

Spell Check – nothing smacks of unprofessionalism like bad spelling, and the real travesty is how easy it is to avoid. Copy and paste the site's text into MS Word, run the spell checker and you’re done.

Proof Read – checking for well formed grammar is a little trickier. For one, it requires someone with a good grasp of the English language, and secondly, it can be extremely time consuming if it’s a big site. There have been times when I have off-loaded this work to the client. Another alternative is to recommend a copy writer.

Browser Compatibility – an old favorite. Just when you thought your website is done, someone comes out with “hey, have you seen the navigation bar in Opera? Its all squished”. As to what browsers you should be checking, that is a matter of browser market share (e.g. check 2-4 of the most widely used browsers). As far as screen resolution goes; a few years ago we were checking at 800x600 pixels, now it is 1024x768 pixels, this will probably continue to increase in future.

Required Field Check – this relates to fill-in forms on the website. You are looking to see if fields marked as required are being checked by the system. For example, there could be a textbox called ‘First Name’ which the user must fill in. If they go to submit the form without entering their first name, does the system show an error message?



Can a Quality test plan be used on a web application in addition to a System test plan? For sure, and I would actually recommend it. The Quality test is so quick to make, why wouldn’t you. Some tests will seem odd though (e.g. checking for spelling and grammar), but chances are good it will still reveal a few bugs. A Quality Test is no substitute for a proper System test plan when it comes to web applications.

Writing a System Test Plan

Using a test plan to ensure your software really works.

"Extraordinary quality doesn't make good short-term economic sense."
- Peopleware, Tom Demarco

Imagine for a moment you’ve just finished a web application for a client. Swimming around within that application is 100 bugs. What proportion of those bugs would you say is acceptable for the client to find (e.g. 50, 30, 10)? The point is, those bugs are going to be found by someone, and its either going to be you or the client. You can think of it as a sliding scale, the more bugs the client finds, the more your creditability suffers and the more damage you do to the business relationship.

In the martial arts there’s a saying; “expect the best, but prepare for the worst”. The US Navy Seals have a slightly more gun-ho version which goes; “The more you sweat in training, the less you bleed in battle.” Notice how it says the ‘less’ you bleed in battle, implying that if you enter into combat, you are going to get bloody. Software development is like this too, if you’re going to create software, you are going to get bugs.

As a rough guide, you want to try catch at least 80% of all bugs. Ideally, you would go for 100%, a worthwhile but lofty goal. Your best bet for catching as many bugs as possible is to create a system test plan. Creating a decent system test plan is easier said then done. A good place to start is your functional specification (assuming you have one). In effect, your specification gets converted into the system test plan. What you are doing is checking to see if the things you said you were going to do have actually been done.

A test plan is nothing new, in fact, the structure I use was developed by Microsoft years ago. It’s a simple format, a test case has a title, some steps, and an expected result.



I write my test plans with the intent of having an independent QA tester run through it, so no prior knowledge of the system should be assumed. You want someone who has never used the system before because they will take a fresh approach. You’re counting on them to use it in a manner which was never intended (e.g. on the ‘My Profile’ page, they type in a really long name for the ‘Company’ field and crash the system because the database only has room for a 32 character string).



You should keep your test cases short, to the point, and self contained (i.e. they generally don’t link to other test cases). If you have a test case that goes over a page, consider breaking it into smaller units. The document itself should be self contained as well, that is; it shouldn’t require the QA tester to get up and ask programmers questions like “what’s the login password?”. Instruct your QA tester to log any bugs they find in your bug tracking system and also to write a proper description rather then just saying “Test Case 16 failed.” You may want to read my article on Logging Bugs Like a Pro for some suggestions on good bug logging practices.

Article reviewed by Alex Barclay.