Clients have proposals. They come in all sizes and shapes, from formal RFPs to an idea hastily sketched on a back of a napkin. But there is one thing they all have in common: Requirements. And each of those requirements almost always calls for a feature. Like a blog. Tagging. sIFR. Some AJAX. These days, even a site that sells toothpicks seems to need a rotating AJAX-powered image gallery.
Often times, we web pros spring into action when confronted with this dilemma. We draft estimates, outline how all these “necessary” features might fit within a client’s budget, and use our design and development skills to build something that doesn’t look like a cobbled-together mishmash.
I understand why almost every client requests these intricate features. They see a site that does something they really like. They love how you can zoom in on Google maps or drag and drop things into a shopping cart, for example. It’s easy to make that leap from “they do that” to “we should do that, too.” Unfortunately, it’s also a fundamentally a flawed approach.
Designing for Features
When you’re confronted with a list of features, you immediately lose focus on the bigger picture. You try to accommodate all of this functionality without asking the most important question: Is it really necessary? So often we treat a particular feature set as our final goal. Instead, we should focus on problem solving. Focus on the problems first and the right features will follow.
Wasting Development Resources
Another unfortunate side effect of features-driven design is spending development resources in all the wrong places. Drag and drop may be cool, but “cool” doesn’t solve problems. If you haven’t spent the necessary time dealing with UI/IA design challenges you’re going to waste resources backtracking in the development phase. So draft the blueprints first, and then start building. Or inevitably you’ll end up with…
Scope Creep
Without that initial blueprint it’s far too easy to start tossing in a new feature during the project. Without the reference document, one feature becomes two, two become three, and so on—until you’re not focused on the problem at all. Instead, you’re focused entirely on (you guessed it) more features. But the cycle can easily be stopped if you stick to your initial plan and just say no.
Why Is It So Hard?
The web community loves new features and new technology. New is exciting. New is fun. New is challenging. And when clients come to you wanting something new, their enthusiasm can be really contagious. How many times can you remember hearing someone say “Oh, that’ll be fun!” when he or she learns about some new feature that “needs” to be in a site?
You want to keep your clients engaged in the work, but if they’re attached to a specific feature, convincing them they don’t really need it can be extremely difficult. Often, it feels easier to add that feature than to try to change your clients’ minds. But that’s a trap we all need to avoid.
Avoiding the Trap
Encourage clients to bring you a list of problems, not features. They’ve hired you to create this website or other web “thing”, and they’re looking for your expertise in solving problems. You were not hired as an expert in bells and whistles-building.
Listen. After all, clients know their business better then you do. But you know the web. Once you truly understand their problems, you can focus on adding features that really work.
Use the budget to your advantage. Clients always want a lot for as little as possible. Explain that by focusing on solving problems, they can accomplish their bottom-line objectives for less money and in less time. Additional features can always come later.
Treat features like a toolbox, not a roadmap. Decide what problems you want to solve, then consult your features tool kit to help you succeed.
The Bottom Line
Features aren’t bad, but being feature-centric is. As web professionals, we should tackle web work with a “problems first, features second” perspective. We’ve all learned how to keep the user at the forefront of our minds. Now we need to learn how to find the right features to solve their problems.
Good post — you can look at it another way, too, and ask for goals rather than problems.
You mention that “focusing on solving problems, they can accomplish their bottom-line objectives for less money and in less time” — agreed, assuming that solving problems will be an effective way of reaching the bottom-line objectives. Unfortunately, that’s not always the case.
For example, if the goal is to increase ecommerce sales by 50%, and fixing a “problem” in the checkout process increases sales by 0.0001%, there may be more effective and efficient ways to reach the objective.
I wrote more about this (and got a lot of comments) on my blog post: Get agreement on goals, not features.
Thanks so much for your post. It fit right into a conversation I was having with a collegue today. Recently I have been thinking about design more in terms of problem solving. This has been helpful to me to be more client-driven and more communication driven in my work. Thanks for the insights and for giving more fuel to my thoughts in this area.
@Jeff Lash Good point with goals. From my perspective, it’s taking even another step back from my post and looking at the goals and objectives for the product/client/company, and then thinking about the problems that are preventing you from reaching those goals. After that you can work towards finding features that will help solve those problems, which in turn should get you closer to meeting those original goals.
Tom, this is so right! I have had a few cases of this recently and it took a great deal of tactfulness to say ‘Wait a second, you don’t need that…’
This reminds me (a little bit) of Jeff’s article from Nov 13 2006 - ‘Bring me problems, not solutions’…which was also a good read.
Hi Tom,
From a project management perspective, you hit the nail on the head. Educate your customer and you will add more value than ever expected.
Great post!
Good post. focusing on the problem is an old school technique that we can all too often forget.
However this all falls apart when after focusing on the problems and delivering the said website, the client then demands that “exciting” feature at the 11th hour. Now that’s frustrating.
Amazing article. These problem has been at the forefront of everything our company does, but never before has it been so concisely defined and solved. Thanks for the great info and solutions!
Wow. This blog post struck a resounding chord with me… as a Director of Marketing for a successful web development company, responsible for client acquisition, I am faced with many of the problems you have just outlined. This has been very insightful for me. Thank you.
Hi, I’m no longer doing web pages but do keep up with the advances in language extensions and ‘toys’. I’ve been programming since 1981 and involved with the web since 1990. It has always been my ‘style’ that functionality is, by far, the most important criteria. I was doing pages back when the tools available really did require the designer to be extremely ‘compact’ in any code done in order for the site to load quickly. We had discovered that sites that loaded too slow were skipped or ignored. This often led to arguments with clients that wanted every new HTML trick they saw. Some of the ‘tricks’ dramatically slowed their site down. Or were not yet implemented with some popular browsers. Today, these same problems still exist. There are huge libraries of JavaScript and other extensions out there that are available server-side. But some are inherently slow or do not work correctly (or at all) with some browsers. It is still a battle (with the client) to convince them as to the proper utilization of these styles versus load-time and other considerations. Even the web designers billable hours may get involved. Some of the simplest looking ‘tricks’ may not be cost-effective to implement as the programming behind that trick is quite time consuming. The very worst clients I’ve worked with were ones who browsed a LOT and wanted every little ‘cute’ toy they saw being used, even if it had virtually no significance to what their web site was all about. My cure was usually to threaten some serious billable hours if logic didn’t work. That usually made them back down.
One of the main reason I no longer do web sites for a living actually was partially due to the stresses involved. I am retired from that, finally. But I do, still, want to congratulate those of you that do web sites and wish you the very best. It’s not the easiest way to make a living. Cheers