A while back I wrote about doing work I couldn’t explain while remaining confident I was getting intellectually rigorous and effective results. It’s been on my mind ever since. I don’t have an exhaustive explanation, but I think I have a general explanation for what’s going on while I work.
You can slice themes of work up however granularly you want, but I like to think of distinct progress bars. Much like this:
No progress made, yet.
Many management structures I’ve worked within over the years try to categorize large swaths of work that can, theoretically, be done in parallel or at different times by separate teams or individuals. I wonder how much of our understanding of roles comes from this thinking. They’re not separate because of different skill sets of the practitioner, but because of the presumptions they can be done in coordinated batches.
Two totally different areas of work... Right?
Once the work is separated, a more tactical executional plan attempts to cover the complete swath of work in the lowest reasonable fidelity. A stepping stone that can be evaluated and approved by a larger group. We like to give these a name and think of them as a single activity.
Wireframes, for example, can cover navigation, information layout, hierarchy of concerns, and much more. Mood boards can cover color schemes, imagery, illustration styles, typography … which is a big part of wireframes.
Hold on.
Why are these being done separately again?
Two totally different activities... Right?
This might be the most appropriate approach for group work and what I do can be “documented” in this manner. Although, I don’t think that’s what my brain is doing. I’m not trying to answer multiple themes of progress at the same time to the same degree of fidelity.
I do something simpler and more experimental to learn.
An intellectual exercise I like to perform is to take a specific question and go as far towards a hypothetical solution as I can. I try to find where this question comes into contact with external constraints. When and where does a solution break down? Not from my preferences, but from the world the tool or service will operate within.
My favorite example of this is Will Wright discussing game prototyping. Unfortunately, the only version I can find of this is behind a paywall. He talks about building a basic environment — think of hills as basic geometric pyramids and buildings as upright boxes — for a game he can navigate in with alternative controls. He wanted to answer for himself if the controls worked well in the imagined future environment. When he got his answer, he threw the prototype away.
He shares a few early prototypes for Spore. How cool is that?
Keep in mind these are not tested, supported or even easily explained.
Ha! I wish more people shared exploratory prototypes like that. It’s a fun way to get into someone’s head while performing an intellectual and creative activity.
One experiment moving one progress bar as far as possible.
While bumping into outside constraints it’s clear this experiment can’t be resolved. That wasn’t the point. It was to generate knowledge of the intended system. I scale back my attempt at a “solution” because I cannot argue for it outside my personal preferences. I need to make progress another way.
The funny thing is that through the experiment I learn, to a lesser degree, about many other things. In Will Wright’s example, while exploring the navigation controls I consequently learn about what the environment should and shouldn’t do. Not conclusively, but more than nothing.
A little bit of progress in many places.
Now that I have more knowledge of the system I can go further down the hypothetical solution path for the next experiment. The next experiment I perform is something close to what I was previously experimenting with, but still an unknown. I’m intentionally exploring new territory that will introduce new understanding that will likely collide with my existing knowledge.
Progress from second experiment.
Much of the same will happen again. I’ll come into contact with outside constraints. I’ll find understanding in part of the work, but not all of it. I’ll scale back to the defensible parts and work out what else I learned along the way.
A few new lessons learned from second experiment.
Here’s where it starts to get interesting. The adjacent understanding that came from two different experiments overlap. This overlap is always incoherent to a degree. Occasionally it’s downright contradictory!
**** just got real.
Part of this acquired knowledge is wrong or framed improperly. To the best of my abilities, I attempt to reconcile these bits of knowledge. I try to find ways both of them could be congruently applied. This leads to minor refactoring of the complete set of progress bars.
After this refactoring I have two separate and distinct reasons to believe one part of my knowledge of the system is more reliable. It holds up under multiple perspectives of critique. It’s been “hardened” in a way.
Full set of refactored constraints, one EVEN MORE refactored.
I continue to perform experiments that produce new knowledge and opportunities to refactor existing knowledge. Many areas a hypothetically fleshed out while others are further refined. More areas become defensible and others are shown to be unreliable.
Aww... The progress bars are growing up.
Eventually diminishing returns make further experimentation unproductive. To “prove” any part further would be prohibitively expensive. The best thing to do is to put it in front of people in the intended environment to see where it works, where it doesn’t, and everywhere in between.
Done... Kinda.
If you ever have the sensation of clarity in your work while feeling anxious about it being incomplete, this is why. You can do a good job, but you can never do a complete job. You can have confident knowledge about how parts of the system will work, but never all of it.
The only way to get that knowledge is to update the environment and see what happens. Then do it again. And again. And again.
Over the last few months of attempting to observe my behavior while designing things, this is what I see myself doing. I imagine it looks chaotic when you don’t understand what you’re observing. It’s difficult to make compatible with linear work systems. It’s holding many incomplete threads as potentially useful in the future. It’s weaving them together. It’s untangling them later. It’s weaving them together again in a different way. It’s hard and sometimes frustrating.
But… It’s fun. And a hugely social endeavor.
This is what Donald Schön likes to call “reflection-in-action” and I love it.
I hope this explanation resonates. Please send me a message or social me if you have any thoughts. I would love to dig into this more.
Good luck my fellow Reflective Practitioners!
≈