|MySQL Conference and Expo April 14-17, 2008, Santa Clara, CA|
Several years ago, I was doing Intranet application development on a contract basis for a large technology firm. In a meeting during the early stages of the project, one of the clients asked for "taps" in the interface.
"Taps?" I asked, unsure what she was talking about.
"Yes, taps. Like at Amazon -- zee taps across zee top of zee page," she clarified.
"Oh, tabs!" I said, relieved.
Her accent was confusing me -- she wanted tabs for the navigation. I said yes and without much more thought after the meeting, I implemented the "taps" and she was very happy. Because the client asked for something specific, I assumed she knew what she was asking for. I never paused to think about whether tabs made the most sense in the context of the application or what the user was trying to accomplish -- I just built it.
Later, when problems arose, I found myself biting my tongue in meetings as this same woman who requested the tabs complained of usability problems with the application. It became apparent that she hadn't understood the implications of using a tabbed interface when she made the suggestion -- she'd simply seen it somewhere and wanted it for her tool.
As the designer on the project, I failed in my role. I didn't consider the implications of her request and I just built what she asked for. Though in a million years I wouldn't dream of making suggestions regarding her business rules, I allowed her to make critical design decisions related to my interface. I allowed her to usurp the design process, without even realizing it.
Usurpers of the Design Process
All-too-frequently an external client or an internal manager or co-worker demands interface changes. They usurp the design process -- taking the decision-making away from the experts -- and deign the interface by dictum rather than traditional development processes, to the detriment of the product.
As developers, when we allow our design process to be usurped, we expose ourselves to potential problems:
Familiarity Breeds Bad UI
Many people are familiar with HTML interface elements these days because they spend time online. Every site we visit uses radio buttons and drop-down menus; the language of GUI Widgets is familiar to a much wider range of non-technical people than ever before. And therein lies a problem: many folks think they understand how elements work and what they should do.
This can lead to some strange requests that, when implemented, confuse the end-user and cause the usability gurus fits. In May 1999 Jakob Nielsen released a list of The Top Ten New Mistakes of Web Design. Number 3 on his list is: Non-standard use of GUI Widgets.
Nielsen speaks on behalf of the users' wants, and points a finger at us developers for using these elements in non-standard ways. But the blame does not lie solely with developers. Many developers do not choose to make bad design decisions; they are forced to because of circumstances.
Oftentimes it becomes impossible to say no or go back once a certain point in the project lifecycle has passed, or because someone with more power demands a different approach. When the VP of Department X wants the user to double-click in a
Being a "Yes (Wo)Man" Is No Good
By continuing to agree to implement requests without proper analysis and usability testing, we can become part of, rather than a solution to, the unusable UI problem. By using elements in non-standard ways, the sanctity of the elements is disrupted.
Each element has a role to play on the page (radio buttons have different roles than checkboxes, etc.) and when elements don't behave like users expect them to, the commonality of experience disappears. Each Web application becomes a brand-new interaction with elements behaving inconsistently.
Imagine if your car used a gas pedal to accelerate, but depressing the same pedal on your friend's car sounded the horn. That's a ridiculous example, but it's the type of thing that's happening on a less dangerous scale online everyday. And thus begins a precarious cycle: as more people see that online elements can be used in a flexible manner, they begin to request their use in non-standard ways.
So how do we stop the cycle? This is the tricky part, because it involves a lot more than experience and knowledge -- it has to do with power. If someone is your superior at work, it's often difficult to say no to a request, no matter how ridiculous that request may be. If someone is the client who controls whether you stay on the project or not, saying no could jeopardize your position on the team. This imbalance can lead to interface implementations for the wrong reasons. But it doesn't have to be this way, and with a few simple techniques, you can regain control of the interface without disrupting the project's politically charged power structure.
The Client Isn't Always Right
Don't Respond Immediately
By reviewing the suggestion after the meeting, then explaining your recommendation -- including proposed alternatives if the original request can't be implemented -- you set the precedent that there's a process to follow.
This can make the rejection of a suggestion or a request a process-based rejection rather than a personal rejection, and can prevent the politics that arise in such situations. All too often I've said yes to a deceptively simple request on the spot whose implications are far greater than I originally imagined. Taking the time to make sure the decisions make sense can prevent headaches down the road.
The suggestions listed above are simple client management techniques but they can go a long way toward making the development process smooth and productive for the entire team. Building a strong client relationship, whether you're working with an external client or you're an interface designer butting heads with someone from the sales department, will help you build a consistent and usable Web site.
Read more Megnut columns.
Return to the Web Development DevCenter.
Comments on this article
1 to 7 of 7
1 to 7 of 7