Sometimes, you can provide too much detail.
What? Rick? Mr. Over explain everything? Surely you jest.
No, I’m serious. (Re-reading this post, I realize I have committed this sin, yet again.)
Let me give you an example.
If you are around me for any period of time, you’ll hear me utter a common phrase.
“I’m not a designer.”
I realize that I’m not a designer. I don’t pretend to be. And I try to be as forthright about that as I can.
I’ve worked with designers and other creatives for a long, long, long time. By comparison, the fact that I’m not a designer has been reinforced, time and time again.
So, I’ve learned to work with creatives in ways that get us both producing the best results possible. And I like to think that I tend to do a pretty good job. Usually.
But I also makes mistakes.
As we’ve been developing Kumquat, I’ve made this “too much detail” mistake a few times.
I’ve been trying to be helpful. I’ve been trying to provide analogy and construct in the hopes that it could be something upon which to improve. A starting point.
But it hasn’t. Instead, it became a template.
Admittedly, Kumquat is truly a labor of love. And I’m emotionally tied to it. And I think about it. A lot. (Yes, I’m too close to the problem.) So, I might provide my recommendations with a bit of fervor. But I always try to couch them as suggestions not dictates. I try to provide concrete examples or specific features or interesting functionality that would make it better. And when I do, I provide it with the caveat that it is not the solution, rather it is a potential solution to the problem.
I know it may not be the best answer.
But I feel obligated to provide explicit detail to describe a problem. To give the recipient all the facts. To help illustrate one possible solution to the problem.
In doing this, I hope to receive feedback along the lines of “That’s an interesting (ahem) take on it. But maybe we could think about it this way…”
I always expect people to be looking for a better way.
Best laid plans.
The truth of the matter? We all deal with bad clients who provide specific detail and don’t want critiques. Who don’t want a better solution. They want you to do what they say. What’s more, we’re all exceptionally busy. So, bringing an existing idea to fruition–without a great deal of additional questioning or reframing–is often the most efficient way to complete the task, for everyone involved.
But when you’re expecting creativity–as opposed to production–this type of response can be frustrating.
And that’s where my “too much information” mistake exacerbates the problem. You see, that explicit detail impairs creativity. Rather than enhancing it.
It provides an answer, instead of a riddle. It provides an end, instead of a beginning.
So the next time you’re working to solve a problem, try asking the question. Instead of providing the answer. You’ll not only get the type of feedback you’re seeking, you might actually get some really creative solutions.
Try eliminating some of the information. Too little rather than too much. See what happens.