The Creative Process, Know when to say no.

Wood Shop

It seems to be more and more common to self diagnose issues, weather its because of the time it takes to have a professional do the work or because information is so accessible.

The problem with this self diagnosis is that people are generally not experienced enough to make informed decisions with the information they find.

Most people will go to a doctor and trust they know what they are talking about. Many serious illnesses have common characteristics and a simple Google can easily lead you astray. It would be strange to Google your illness head over to the Hospital and give them a printed report with your symptoms.

A doctor would never work this way, They have to figure out the cause them selves.

Case in point more and more clients have a better understanding of the web and how it works. That a lot of clients still don’t have all the information and typically have learned from frustration or have been pushed into that by necessity.

I have been been given client requirements numerous times and told that “This has to be done!”, without any regard to its implications. Due to rushed time lines or a lack of understanding the Get-er-done mentality is dangerous.

There is always a struggle to meet deadlines, manage the client, manage the developer/designer and in the end I feel that a good project manager knows when to say no.

A good designer or developer should also have a good and clear understanding of the project goals before work gets underway and they should feel comfortable saying no.

Nothing kills the creative process faster than confusion and unnecessary revisions.

The ability to say no is probably more important than saying yes. Saying no means you have an opinion or a reason so make sure you sell it. At the same time, to say yes make sure the client can sell you the reason why. Make them look at the implications before you cave in and say yes.

In the end you will end up with a better product, it wont be mottled with bits of last minute changes.

Some of the best working relationships I have had stem from the back and fourth communication (arguments) trying to remove or add features.

Take pride in the fact that you were hired to solve a problem, If you feel that you were hired to execute some one else’s solutions then you are only the tool and not the skill behind it.

Signup for my mailing list

Receive other rambings like this on design, code, and some times food.