HOW TO KILL YOUR DARLINGS? : THE STORY OF A UOCD GIT DIAGRAM

“Kill your darlings.” is admittedly a cliché phrase we hear all the time here at Olin, especially in courses where the spirit of continuous iteration is regarded as one of the key values. This principle sounds simple and straightforward, but how do we even realize that an idea has become a darling? How do we overcome our innate bias towards certain ideas? To illustrate how to systematically tackle this strategy of not getting fixated on one initial idea, I present the story of how I killed my darling by sharing the story of my darling.

Starring at the design review rubric taped to the whiteboard, the team begins to scribble down a series of potential frameworks on the sticky notes to figure out how to present and deliver the complex narrative of the conceptualize phase that would incorporate both a comprehensive story of idea developments and an exhaustive overview of the idea generation process. The 5-minute time-box alarm forces the team members to share the raw ideas, yet we find none of the frameworks satisfactory. I get slightly distracted from the seemingly unfruitful discussion and my eyes unconsciously scan the favicons on my Chrome bookmark bar back-and-forth. Then something hits me. Feeling enthusiastic, I proudly share my supposedly creative framework.

“Github! Let’s make a Git diagram of all the ideas that we have generated. It will show the complete history of our conceptualize phase along with useful commit messages that explain why we made such design decisions. It will eventually contain all versions of our ideas, all of the frameworks that we end up using, and all of the interactions including the co-design sessions that contributed to our design process”.

I successfully persuade the team to invest some time into creating the UOCD-Git-diagram. But as we cut down a giant sheet of paper and begin to fill out the content with a rainbow of sticky notes, the team starts to get confused and frustrated, partly due to the unclear image of what a Git diagram is, and partly due to the rapidly growing complexity of the diagram. Insisting that this work will serve as a comprehensive illustration of the team’s complex design processes, I repeatedly explain the overarching goals of the diagram to the team. Unfortunately, the team soon gets overwhelmed by the huge amount of work that needs to be put into this single framework. As a result, both the team energy and the productivity sinks to the bottom level. The team eventually makes little progress towards the proposed diagram, leaving me frustrated with distracted team members and unfinished work.

Next day, I stubbornly try to persuade the team to continue working on the Git diagram, only to face confused teammates again. But the team decides to move forward by sharing the struggle with one of the instructors, Marco, for a clear feedback on whether this framework would help us achieve the goals of the design phase.

“The diagram may perhaps serve as a good team exercise to explore but is not an effective tool for delivering the comprehensive story due to its inevitable visual complexity”.

It was this moment that an outside perspective objectively analyzed my idea when I finally became aware of my darling and identified it as the source of the struggle. So I killed it (finally). The team was eventually able to iterate the original framework into a Venn diagram of three different personas with potential directions color coded with various areas of opportunities, a concise and visually organized framework which achieved the same goals more effectively.

The moral of this story for designers is that they should always feel encouraged to share their ideas or struggles with an external audience outside the team. Designing is a subjective process and is never free from the implicit biases each induvial designers possess. In my story, simply sharing the story of the team’s struggle and asking a verification question to Marco substantially helped the team breakthrough a deadlock and make informed decisions about what to do. While external feedback isn’t always objective, it at least expands the boundary of thinking beyond the biased subjective self.

This method of actively sharing your potential darlings with an external audience would be particularly helpful for a group of designers that experience a lot of idea clashes that never get resolved easily due to the strong individual design-egos that each member demonstrates. Nonetheless, in a case where no knowledgeable professional is around to offer guidance, designers might not receive as much objective feedback. Another limit of this strategy is that the external audiences are also prone to the innate biases and might get attracted to your darlings, making it more difficult to kill the darlings!