You build websites. It is a passion. You have taught yourself everything and continue to do so because the industry demands it. You wrangle code with the best of them. You design user interfaces to help users get things done. You document sitemaps, wireframes and workflows that will take the clients site to the next level and beyond. You know your craft well and you love it…
A Scenario
Company X, your average ad agency, wants to work with you on a website a client needs done. The budget is tight so you work a deal out based on the budget at hand and start the process. During some meetings with Company X, the client and yourself, crazy ideas are brought to the table. You cringe a little bit knowing that the ideas are above and beyond the scope of the project. Politely, you calm the ideas down and decide to work on what can be done within scope. After a few days of work, you send a mockup to Company X for review with their client.
A few days go by and Company X sends feedback along with an attachment. The feedback:
“We took a look at the mockup you sent, and decided to go in a new direction”.
After opening the files containing the new direction, you begin to cringe again. This “new direction” is extremely out of scope and will not work within the constraints of the system you had originally designed for. The design contains a Flash splash intro page, no solid navigation, moving animations everywhere and most likely funky sound effects. Oh yeh, the client also “loves it”.
The Problem
We are dealing with two clients: Company X and Company X’s Client. This scenario has many issues, but the big one is client education and expectation.
You have been hired by Company X to solve their clients problems. You attempted to do this within the scope of the budget, but Company X had their own agenda for the client. The lack of communication and education on how to solve both clients problems has turned the situation into a downward spiral. Company X, with what they know and understand, thinks they solved the client problem with their solution. The client loves it. You, with what you know and understand, see failure. What happened here?
The Solution
Communicate. Define the client’s problem. Solve that problem.
Design is about solving problems first; then, maybe, making things look “cool”.
Share your process with Company X and the client. Define the expectations based on the budget and make the clients feel comfortable. You are the expert at what you do, that is why you were hired. If you do not educate your clients on what to expect, they will want the world and/or something that will not help solve their problem.
I understand this is much easier said than done. I would love to hear what others have done to make this situation calmer, easier, or at the least less frustrating.
September 3rd, 2009
Hi Brian, I’ve never considered myself a “process” guy, but a process is what can help. Namely, write down the requirements with the help of the user. General business requirements first. Get those signed off, approved, and baselined. Then go to functional requirement, get them signed off and baselined. Then on to High Level Design, signed-off and baselined. Then Detail Design. At each level from general to more specific, after they are signed off, they can’t be changed except with a Change Request. Change Requests require more $. That’s it in a nutshell how we do it.