Eliminate distractions to help your clients focus on the actual quality of your awesome programming

Definition of Perceived Quality:

Consumer’s opinion of a product’s (or a brand’s) ability to fulfill his or her expectations. It may have little or nothing to do with the actual excellence of the product, and is based on the firm’s (or brand’s) current public image (see corporate image), consumer’s experience with the firm’s other products, and the influence of the opinion leaders, consumer’s peer group, and others.


As a programmer you are blessed with a certain set of skills. One is the ability to visualize the final result of work-in-progress programming. A good example of this is when doing a Proof of Concept (POC). The very nature of a POC is trying to make something work without spending time on the details. You make it work, knowing you can clean up and trim the edges later.

This level of abstraction is a skill that most clients don’t possess. If you’ve ever carried out a presentational review with a client, you probably agree. Wishing everybody in the room was a programmer? You don’t have to if you just acknowledge and accept that most clients aren’t. But this needs to happen early in the process, or you’ll be spending way too much time explaining seemingly irrelevant issues rather than the actual solution. This is frustrating to you, since you deliberately did not pay attention to these issues, and the client is left with an unjust impression of the quality of your actual work.

There are different things worth paying attention to early in the process whenever a client is part of the equation. All these things may seem irrelevant at the time being since it’s just work-in-progress, but it could be what raises your client’s impression of your solution from a duct tape feel to a rock solid one.

Chekc you’re speling

Spelling affects people in very different ways. To most people, spelling may not be a huge deal, but to some people, bad spelling can be a tremendous distraction. There is a Danish Facebook Community called “I Judge You When You Misspell!”, which arguably is a bit harsh, but it does indicate that some people have strong opinions on the matter. In any case, spelling mistakes never really improve the overall impression of anything, and they are usually fairly easy to eliminate. Some may view spelling as a personal matter and be reluctant to point out errors spontaneously, but most people are happy to help when asked. So take the time to ask a trusted colleague to check up on your spelling and grammar. Even if you’re a grade A spelling wizard, you might have overlooked something.

Lose the developer lingo

Developers rely on naming conventions like camel casing for variables, values etc. This works well in a programming environment, but the end user most likely doesn’t know about these conventions and would always prefer a field label called “Page Title” over “pageTitle”. If the solution is in another language than English, you might as well translate the label to the correct language right away, so it won’t look alienated in context.

A little styling goes a long way

HTML elements rarely look good with nothing but the default browser styling. It’s probably overkill to aim for detailed styling fit for the final version, but adding just a touch of class will make a big difference. Changing the Times New Roman to … well, anything else really, adding spacing between elements and so on will make it easier to visualize the feature in a finished state. Also, you may have used Google Chrome in the development process, but if the client uses IE for testing, it may look rather different than you expect. A bit of styling will minimize any cross-browser differences. If you’re a frontend developer, apply Bootstrap or another framework – it only takes five minutes… and if you’re a backend developer, apply Bootstrap or another framework – it only takes five minutes.

Eliminate unhandled user interaction errors

If you’re presenting some kind of user interaction flow, where only a part of the flow is ready or if multiple flows exist as work in progress, you most likely know exactly which parts work and which don’t. The client might not have the same insight, and if the client tests the flow in a different way than intended or goes beyond the current scope, the system should at least fail graciously. Regardless of how smooth the system is running, if the client is able to provoke an unhandled error just by the click of a button, it may give the impression that the entire system is unstable. Removing unfinished or unrelated features and handling side-effect errors will definitely ensure a robust feel.

Leave a Reply

Your email address will not be published. Required fields are marked *