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.
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:
Without understanding the underlying issues driving the requests, we have no way of knowing whether the proposed solution will work. It's imperative to understand what the user's goals are to make the appropriate changes to our interface. If we simply implement what we're told, we may be opening ourselves up to a whole different set of user-experience problems.
The proposed solution may violate interface standards, even if it does fix the problem. By complying with this request, the developer becomes an unwitting agent in the construction of nonsensical Web sites. At the same time, the developer cedes control of the interface to someone who is not in a design role on the project.
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
<textarea> to spawn a pop-up window, it can be difficult to say no. But say no we must.
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
This is a surprisingly simple but important adage. When your client suggests cascading menus, do not assume she knows what she's asking for. She may not be aware of the platform and browser limitations of her request. She might not understand the increase in development time. She may even be wrong, from an information architecture standpoint, to suggest such an approach. Before diving in and coding her request, confirm that she understands what she's asked for and that it's an appropriate solution for the problem at hand.
Don't Respond Immediately
When a client asks if you can do something in a meeting or on the phone, don't say yes or no immediately, even if you think you know the answer. Listen to the problem to get a full understanding of the issue. Repeat the problem back to the client to make sure you've got it straight, then respond that you need time to review the request.
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.
Give us your insights, your tips, anything to help prevent customers from destroying their own sites.
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.
Start off the project by ensuring that goals for the site's success are clearly stated, e.g. "users need to be able to use the site as a tool." Goals help answer questions clients may ask, such as, "Why can't I double-click here?" and prevent you from always being on the defensive, answering similar questions time and time again and defending every design decision you make.
As the expert, you have a responsibility to respond with suggestions that make sense. Help your client or other team members understand why elements act the way they do; explain why it's important to have GUI widgets respond in standard ways. Many times people are making suggestions to be helpful and don't have the same level of experience as you. Just as a client explains his business rules to you, you can explain design constraints to him. A successful client relationship is founded on communication.
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.
Meg Hourihan is an independent Web consultant and freelance writer. She is a co-author of the book, We Blog: Publishing Online with Weblogs.
Read more Megnut columns.
Return to the Web Development DevCenter.
Copyright © 2009 O'Reilly Media, Inc.