Identifying Problems
In a recent blog post by Blue Flavor on Problems, Not Features, Tom Watson talks, in depth, about making sure you (as a designer/developer) don’t get caught up in identifying “cool” features on a project before identifying problems with a clients’ business. I’m sure that at some point we’ve all been guilty of this.
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. via
I have definitely been guilty of this before. A client will contact us looking for a redesign of their site, and upon the first glance of their site I start thinking of ways I would redesign it before identifying what their business problems are. We design to solve problems, and sometimes it’s hard for a client to identify what their business problems are, so they think adding “this feature or that feature” would help them grow their business.
In client discovery meetings, how you’re going to design the site should not be the topic of conversation. That stuff doesn’t matter at that time. What does matter is getting information on their business and see what is working and not working, the problems they are having, who their audience is, etc. In other words, just listen and stay focused. From that information, you should then have your work cut out in knowing what needs to be done (features) to tackle problems.