Category — Web Usability

Do you remember long ago trying to memorize HTML element variables? How about the endless cursing while attempting to allocate 640k of memory so you could run particular games in Windows 3II - having to modify the win.ini file until the computer worked again? How about installing Matt’s FormMail script and spending 2 or 3 days screwing with the config files to make a form bounce correctly? - or when wrestling with specific browsers attempting to get the css compatible and wondering why there aren’t stricter css handling standards imposed on the industry? Near the end of every development, do you say at one point, “Of course it’s f’d up in IE, why do people still use IE?” Being technically minded, these problems are quite easy to overcome and most of them are now well behind us - experientially speaking. No, the common obstacles I’m discussing here are human beings and how they can throw wrenches into what should be fairly straight forward development strategies.

First, let’s look at the myriad of ways that common user influence impinges upon developments - outside of dictating through observation what should and shouldn’t be present within a “usable” interface. The most common waylaying influence happens by way of employees involved in the initial planning stage who have little to no experience in developing a website. This is tantamount to GM or Ford executives designing their cars. If one’s profession isn’t user interface engineering, copy writing or graphic design, then there is little point in keeping them involved in the first crucial stages. It’s only logical that utilizing people for interface design and who also require weekly instructions on how to receive attachments, or open a spread sheet are not up to the task. I’ve attended more than one meeting where a participant suggested a web site open with a sound bite of a barking dog - something that is against all usability studies and proven design principles. Such suggestions are a definite waste of valuable time better spent on 2 to 4 experts in a room hammering out a site map that makes technical and creative sense. Another way “amateur creep” works its way into a development is management listening to critiques of the development from the custodian or from the office paper delivery person and taking them seriously. Another chief destroyer of any potential of success is the family connection, the son or daughter who requires employment and something to do ergo they becomes head of the web design committee and, your new boss. If one is forced to play by the corporate rules then at least make the meetings interesting complete with dire warnings against utilizing shiny gadgets, barking dog sound bites and logos created by the sales manager’s daughter. Another reason for wasted time through poor design is via underlings instructed to complete the development before presenting it to the principals for critiquing and approval. This stunt invariably causes much confusion and infuriating redesigns in a bid to placate the mile-wide gap in development knowledge - something that could have been avoided had the principals been involved from the first working mocks and not just 2 hours before launch. I call this scenario “back-to-zero” implementation. Basically its akin to completing the development twice; once for the employees and then again for the management’s educational benefit. Periodic updates presenting agreed upon functionality accompanied by design mocks can reduce the knowledge gap as well as can daily email reports accompanied by example links sent throughout the management hierarchy. Providing some commentary aspects on preliminary mock-ups can greatly reduce the approval time if dealing with many planning individuals.

A good plan will always outwit the witless.

The absolute best way to combat the intrusion of wasteful suggestions is to cut them off at the pass with an unbeatable plan. The only good counter to incessant and even ridiculous suggestions are inarguable and logical solutions. These may take a week, or a month, or longer to formulate but its better to go in armed to the teeth than appear even somewhat reliant on the wish-lists of those who are not well enough equipped for task of development. They’ll be required to perform usability testing prior to launch - IE: Finding the best position for the site search functionality by observing how the users navigate.
Give them options for every aspect from hosting, server OS, data base, programming language, usability mocks and graphic overlays and if necessary, usability reports and industry statistics to back up your plan. If you’re teamed up with other service experts assess their strengths and weaknesses in order to work with them as closely as possible - make them part of your team or conversely, should they be equally as professional, become part of the team fluidly, ninja style and fully-armed with solid and unarguable plans. Again, the more basic knowledge imparted to the echelon early on in the development, the better. No surprises means a smooth roll out.

The only good counter to incessant and ridiculous suggestions are inarguable solutions.

Keep your meetings on track and out of the wishing well.

Invariably there are folks who feel a compulsion to contribute due to the need to belong in a group setting. They were invited to the gathering after all weren’t they? Meetings can go one of two ways; 1. mildly successful or, 2. complete failure. When negotiating technical details like programming languages, database protocol, server latency strategy, caching templates and centralized CSS, the last thing any mired tech-head wants to hear is “What’s a latency?” Having to explain basic internet protocol to folks who’ll never, ever need to know the finer details to do their job is an absolute waste of time and money for business owners. The most common requirement among lower managers and office workers not ensconced in the technical department is a good internet connection, an office intranet with weekly updates on the company knowledge base. This is something that must be discussed with the principles well before the design phase to ensure that they don’t waste company capital, and you don’t waste your time teaching internet 101 to folks who require endless instruction on intra-office document work flow and how to get that annoying “paper clip guy” off of their screens.

…the last thing any mired tech-head wants to hear is “What’s a latency?”

Separate the Davids from the Goliaths.

Assuming that everyone in the company has been hired on good resumes we can be assured that they are well-meaning and genuine people we can then assume that there will be weak and strong individuals within these ranks. Separating them into two categories can help considerably. The first category I call the “Davids”. These are people who can rise to any occasion within the sphere of their knowledge and beyond. They can be counted on for strict disciplined teamwork during planning. These types leave their ego out of the mix and only bring their best game. “Goliaths” on the other hand will try to commandeer the meeting by rote snuffing any great ideas in the process. They will force their ideas, push their agendas and wrestle with the Davids for victory over some obscure egotistic struggle that only Goliath can perceive.

There also exists those with enough knowledge to be nearly useful, but due to an overbearing and insensitive nature coupled with a complete ignorance of their own behavior they remain suspended forever in “pest” territory. These types should be shunned from any serious development attempts and instead sent down fanciful garden paths in pursuit of “whirly gigs” and “backwards uppities”. They’ll be content with being treated as exceptionally important or… “normally” as it were. These types do a bang up job at what they do best and a top salesman or crack accountant will abhor having a tech head chime in on his Monday meetings. The only individuals required to be present in the initial (and most important) planning stages are those with the technical knowledge and creative experience, and if lacking in both these qualities, must provide a service that is crucial to the development. Lay down these laws before the development planning even begins and you’ll save your client time and resources.

Ask the right questions.

In the end the secret to making the client happy is not by doing exactly what they want, but by giving them precisely what is required to meet their expectations. The only way to achieve this is by listening very carefully to their requirements and more importantly, asking the right questions. The first question to ask the principles is a two-part inquiry, “What would you like to do? and, What can actually be done within the budget?” This will force your client to look very closely at their requirements thereby reducing future inevitable setbacks via the introduction of previously unvoiced requirements late in the game. By separating the wish lists from actual business requirements, true costs, anticipated results and attainable time tables can be calculated. Creating a marketing campaign for a product based on external observations of competing businesses may be adequately successful but for a truly effective promotional campaign, understanding the customer from the entrepreneurs point of view - utilizing information only they can impart - will surely help shed much light on the type of customer, the most advantageous market direction, and most effective promotional push.