As developers, saying “no” to clients sounds, on it’s face, like a bad idea. You want to do what the clients need, you don’t want to upset them, and, frankly, you want the hours. But the truth is, in order to build websites that are cost-effective and sustainable, you have to say “no” sometimes. First, you have to say no sometimes because, after all, we are the experts. Good IA, UI and UX designers know about what works on a website, and what doesn’t. What will confuse users, and what won’t. Generally, this is not expertise our clients have. They think they want the flashing red button in the middle of the front page, or the super-jazzed up photo gallery, but you know that won’t lead to good user experience.
Second, with any CMS/WEMS (Web Experience Management System) some things are hard to create. We exclusively use Drupal these days. Some things take weird and interesting combinations of modules. Some require custom coding. And the more complex the modules, the more custom code you have to include, the more likely it may break or become unwieldy in the future. For clients with deep pockets, this is not necessarily a concern (although I might argue it should be anyway). We generally work with clients that have very slim budgets, and we want to do our best by them.
It’s necessary to weigh the importance of a feature against cost as well as risk to long-term sustainability. The more customizations you make, the more brittle the implementation, no matter how good a coder you are. And the more brittle the implementation, the higher the risk that a module or core update will break something. This is not a risk most of our clients can take, especially for features that are not mission-critical. It’s important to weigh the risks and benefits. How much will this benefit the user experience? Will it really lead to more visitors, or more conversions (donations, sales, etc.,) or is it just some bells and whistles that won’t have that big an effect? How much risk is involved? Are there a lot of users of a module you are considering? What kind of risk might be posed by module or core updates in the future? We think of saying “no” as an important part of our toolkit leading to successful, sustainable projects.
Leave a comment