Sketch First, Colour Later

As the year was drawing to a close I tried drawing something close to a portrait of my daughter.

As expected, the result does a huge disservice to her. She is way cuter than the monstrosity I created. But the whole exercise turned out to be a good metaphor for project delivery.

This is the piece that went into production.

I started from this pencil outline.

And progressively added colors.

Finally though, I decided that the colors made my lack of skills pop out too much, and used a filter on the phone to decolorize it.

A Different Way?

But that’s just one way to do it. I could have made it slice by slice too, finishing the left most piece first, then doing the next and so on.

Right?

Something seems off about that though, doesn’t it?

All sorts of problems lie that way. Maybe I run out of color. Maybe I just am too bad at drawing an eye that matches the nose. Maybe I lose interest. Maybe the colors don’t mix well at the seams. Maybe I run out of space and the only way to complete it is by squishing the image.

If you think about it, those problems have project delivery equivalents too. Maybe the priorities changed and the project was stopped. Maybe the budget ran out. Maybe the pieces don’t work well with each other. Maybe the only way to finish is to rush and sacrifice quality.

Yet sometimes, we slice work this way. We have all heard the glories of AgileTM, and want to iterate with chunks of work. We have heard something about vertical slices so we look at the architecture and start building one component at a time.

The Slice Axis

The axis you slice the work in is important. Architecture diagrams come in various styles, so vertical or horizontal run the risk of misinterpretation.

Variants of this picture where a car is developed by evolving from a skateboard are all over the internet. While the explanation is correct, the image and its story seem to not click with some people. My guess is that the stages of evolution look too different to understand intuitively as incremental delivery.

How not to build a minimum viable product h/t @UdiMilo #leanstartup #product #ux pic.twitter.com/tef838sZBS

— UserTesting (@usertesting) January 2, 2016

The idea is simple: Slice the work such that the resulting slices are usable. But maybe we need new metaphors. And even if we don’t, some things are just worth repeating in various ways. So here’s my candidate metaphor. The slices are these layers.

Notice that at each point, I could have stopped and used the result. And while only the last version remains on paper, digitizing the steps means I can still use any of the previous versions and build on top of that. Essentially, what you see above is the commit history of the master branch.

The Nature of Feedback

Let’s look at the “wrong” approach once more. There is a deeper problem in addition to all the ones mentioned above. It undermines the purpose of learning while iterating. We can go about our days getting feedback and doing showcases, planning sprints and doing iterations, and yet not go anywhere.

Imagine what feedback would be like for piece-wise development. Going back to portraits, suppose we drew a smile, and asked for feedback.

The correct response is that one doesn’t know what to make of it without the rest of it. But this is extremely uncomfortable to say. Everyone wants to feel useful and helpful. So they say that it’s too big, or it’s too brown, or some other such thing. On our part, if we act on these comments, we will forever be stuck making useless changes.

Feedback on the smile is useless without its context.

The smile is completely out of place here…

…while being perfect here.

If you aren’t slicing it right, you are better off not gathering feedback.

Accept that you are doing a waterfall style project where these rituals do not fit. There are good reasons to do such a project. For instance, when sending a space probe, we aren’t flying out MVPs that keep exploding mid-air. Instead it’s a big bang release of the machinery which sometimes fly out and follow plans laid out decades in advance. Just be mindful of the type of project and intentional with the approach.

To round out the art metaphor, there’s an analogy for such projects too. It’s what I used to do when I was a kid. Make a grid, and copy. Worked perfectly for the cartoon characters I wanted to draw. Just two conditions for this to work: know EXACTLY what the output is, and have the skill and resources to execute each piece. Only problem is that most projects don’t satisfy these conditions. Hence the need for other approaches.

Implications

If all this makes sense, maybe we shouldn’t focus on the perfect data cleanup because perfect can only be defined within the context of the rest of the project. Maybe we shouldn’t focus on refining a model’s metrics only to later discover that for various reasons it won’t be used anyway.

Maybe we should sketch instead, build lightweight versions of each of those stages, and focus on getting the API/dashboard/webapp out first.

This is hard to do. It is normal to want to get each of the steps just right. Somehow, when dealing with abstract things our minds lose the intuition of the physical world.

The API would, of course, use the most basic model or even a hard-coded rule for now, but you would discover the shape of the problem better. You would discover if the puzzle piece that your solution is, is of the right shape.

Maybe you will discover that this isn’t really what was needed, and maybe you will discover that this is all that was needed. Either way, you are better off learning this sooner than later.

Sketch first, colour later.