Oh hush, the title is just for fun.
I am happy to write this post as it crystallizes the approach I take to problem solving; an approach that until recently I had trouble expressing. To bring the approach into clearer relief we can take a hypothetical project example: updating a product support website.
Their Approach
The standard approach is to first assign a team to the project: a project manager, someone in charge of strategy, a client-facing manager, designers and UX reviewers, perhaps a data analyst and maybe a web engineer.
Next a framework of some kind is applied. Perhaps there are five phases, most of them sequential, each depending on the completion of some prior step. The phases in turn have many sub-steps to be completed. Team assignments are made as to who will do what. The project manager is certain to require status checks and keep track of logged hours.
The phased approach is sure to contain a structured research component, the creation of personas, a stage involving a careful UX audit, long discussions with the client about KPIs and getting really specific about their needs. An initial presentation of the phases will be made as well as follow-on presentations about how each of the sub-processes are progressing.
The approach aims to present a carefully crafted final product by moving slowly one step at a time in progression. The project phases, structure, and path are more or less laid out from the beginning. This is the approach everyone seems to take. It is taught in business schools. Questions are asked about it in interviews (“Tell me the approach you would take to solve this problem. What steps are needed?”). It is often encouraged by the client (because, after all, many of them went to business school). But it is a process I deplore. To say it does not come naturally to me is like saying flying does not come naturally to a fish.
My Approach
Instead of aiming to minimize errors by completing the project once carefully, I aim to minimize errors by completing the project quickly multiple times. Each time I learn from my mistakes and find out what is missing, gradually inducing structure as I continue to iterate. The word “stochastic” in the title wasn’t purely a flourish, it describes where I begin: anywhere I like; nor is the term “interrogative,” which describes in my process the act of putting on “the client hat” after each iteration and integrating myself about what is missing from the final output.
So how does it work?
The first step is to reduce the project down to the lowest number of dimensions, its essence. For the project above the assignment might be to “make the support site better and give me some wire frames.” And for my process that’s all the direction I need. What “better” means in practice isn’t so important at this stage, it will become apparent over time. Nor is a defined scope of work necessary, which I personally care little about. The scope becomes whatever I determine it to be as I iterate.
Next I pick a random place to start research. This might be to start looking at competitor sites, it might be reading about UX best practices, it might be examining academic articles in a business journal. Again, the starting point is stochastic. I simply start at whatever entry point seems exciting and relevant. I do some research for a while and if I don’t find anything or get tired of research I quit and start a new research thread. I take mental notes, begin inducing an organizational structure for the data I find and final client recommendations, and start thinking about what a wireframe might look like. I take screenshots and write down notes.
Then after some amount of research, whatever feels right (but in the case above probably a few days), I start to create a wireframe. I produce it as if I’m giving it to the client. As I create it my mind is filled with questions. Is addition X of the wireframe really needed? Why did I add it in the first place? What quantitative piece of data would support adding it? Can I get that data myself or does the client have that data? What if the data turns out to oppose my intuition? This begins the stage of interrogation as I aim to create a first draft product that withstands client review. As I play the role of the client I interrogate the output (the wireframe in this case). Can I truthfully say I did all the research I could in area Y to justify the removal of something currently on the support site? What are some of the themes that various aspects of the research fall under that would unify my approach? What KPIs would making these changes really drive? Do my changes work for all users or just a subset?
As my self-interrogation begins to make my output crumple and I begin to take notes about where it needs to be shored up, how I can shore it up, where I need to do more research, different conclusions I would draw depending on what various data look like, and so on. I have a list of things to tackle. What do I do? I start over. I pick a random item on the list that excites me. I again research, this time in more depth or in areas I know I’ve missed. I take new notes. A new picture is formed in my head. It’s not completely new, but rather a more robust and complete version. I remake the wireframe and re-interrogate myself. I continue the process until I have an answer for every question I can think of, until I pass my self-interrogation. Along the way I will have induced everything I need about how to structure the various aspects of the final deliverable and recommendations.
The Good and the Bad
My process is iconoclastic because I’m naturally a contrarian. I despise standard processes and opinions for no other reason than they are standard. I think it’s better to be interesting than right in almost all cases.
The process I just described did not arise from intention. It’s just the path I take naturally. My mind cannot wrap its head around what needs to be done a priori or how to do it without jumping in with two feet. Nor am I necessarily convinced I’m doing something new. The process I use is somewhat akin to rapid prototyping and has analogies to stochastic computer science optimization algorithms.
In a lot of ways I admire and am jealous of those that can clearly see the path set out before them and create the structured, phased, carefully crafted plan. But that’s not me. I used to want to imitate them, but I’m not sure I ever can. Perhaps it’s better to carve out a small space for myself using my off-beat approach.
My approach has some drawbacks of course. First, it takes a certain personality type (like mine) that combines intelligence, creativity, and impatience. To the outsider it seems as though I’ve skipped something, played fast and loose in an environment that demands caution and foresight.
Second, it’s almost impossible to use this process in a team setting. It creates a small space for a sole endeavor, which is why it doesn’t scale well. Medium-sized projects of the type I described are about as big as you can go (though often large tasks have small components which can utilize this process).
It can also be inefficient. Having to induce a new framework every time you start a project is perhaps not the most efficient way of doing things. Nor is stopping midway through a research thread and starting a new one simply because you were bored. There are very real switching costs to stopping your current task and starting a new one, only to later have to reorient yourself to the old task once interrogation is complete and you remember there are holes in your original research. And yes, you can miss things.
Because it has its own type of inefficiency my process benefits from soft deadlines. The process has no clear completion date, it’s done when you pass the self-interrogation and that can sometimes take longer than desired, so ultimatums like “Get this done by June 3rd” create artificial cycles and derail the process’s freedom.
Because it is less structured it can be hard to give status during the phase in-between draft outputs. Project managers are sure to hate it. In the standard approach we must all be comfortable all of the time, at the first sign of discomfort or ambiguity the project manager swoops in. We have to find out who is doing what, when they will be done, what resources they need, what the dependencies are, a list of next steps, ad infinitum.
But my process also has its benefits.
Just as surely as it is inefficient in certain respects, it is very efficient in others. It allows a single individual to do the work of many. In fact, it demands it. It takes a single individual with diverse thoughts crashing together in their head for the process to be truly effective.
As much as it seems unfocused from the outside, it is hyper-focused from the inside. It does everything at once — the UX audit, the data research, the competitive analysis. And as the one executing it, my mind is always on. I can work harder and longer than most people because the diversity of the approach allows me to stay fresh and hungry. I quickly begin to see the various strands of research combining in my mind and forming a unified story. I begin to see structure and patterns, which in turn combine with whatever new (or old) ideas I’ve encountered in podcasts, books, journal articles, interviews, movies, and conversations with friends; the approach has strong returns to analogy and rewards the combination of disparate thoughts and disciplines.
I’m bounded by no constraints and so can think more creatively and quickly than the alternative, structured path. The phrase “make the support site better and give me some wire frames” is enough direction because the process will figure out the details as it moves along. In this way it’s better at handling ambiguity.
My approach also better abides by Sister Corita Kent’s advice: “Do not try to create and analyze at the same time. They are different process.” The alternative approach fails in this respect because its goal is to simultaneously analyze the problem and create a path toward solution with predefined guardrails long before true creation has ever begun.
Because I don’t have to worry about process, I save up-front planning time. Because I work alone I save time on meetings and coordination. I get to a first draft product quickly, but one that is already coherent and rich with ideas; some of them are wild and may get culled out in later revisions. I can share these early versions with the client, and they are pleased with my progress. I can archive the wild ideas I’ve culled and present them coherently at the end of the project under the heading “Thinking Radically.” I go down dead-end research paths, yes; but so does the alternative approach. I get to fail quickly many times; the alternative approach can hardly afford to fail at all. And because I don’t start out with a pre-defined structure I induce only what I feel is essential rather than letting standard, business school-style frameworks dictate my path and thinking.
Just One Last Thing
Many will still view my process illegitimate, the ex-post justification of a hyperactive manic. I disagree, of course. They say that writing is thinking and I think articulating the process clearly here will only sharpen my skills at it.
The next step is to try to integrate my way of doing things into the standard business practices of my current employer. I will report back.
James McCammon 