Trust the process
Post
Cancel

# Trust the process

One and a half weeks of format development for the Hungary department. We were put to the task of developing a facebook video format that engages healthy online discussions — because Hungarians are so polarized.

This design challenge had been developed previously in-house and we worked as a group on this task. After seven working days, that is nine calender days there was supposed to be a result usable by the Hungary department. The goal was to develop a format so tangible that the next month the department can create full-fleged pilot of this show.

The development process we underwent was incredibly well managed, designed, and carried out. And it totally deserved the plea the instructors kept putting at us: Trust the process. If you ask me now, I’d say: “Trust the process because it delivers results through exploitation.”

## Design Thinking Goodies

The goodies described here may or may not have to do with design thinking. Since our process was a design thinking process these are the goodies I’m taking away from this process and they may relate to design thinking

There are many bits and pieces I am taking away from this time — gosh, after five days of intense labor, frustration, and hate against the methods used during this design marathon I even designed a workshop for a private project using precisely these methods. So, definitely valuable lessons learned.

Front and center: Constraints spurr creativity. A development workshop that intends to create a clear product with a clearly defined need but brings in 14 minds is only possible with clear, focussed, and hard moderation. Working in groups, moderators need to be on their toes, to intervene whenever the group strays off topic or looses itself in detail. It helps to have tangible moderation, i.e. some form of visualization of the process. Our workshop made good use of Miro to keep the process in shape.

Small steps: Boil your process down into small approachable and easy to fulfill challenges. Think in compartments: There is an overall challenge and there are several steps to take to get towards a result. Then break down the several steps until you are there with step-entities that can be as short as one minute. Set a timer for each step to (1) add creativity constraints, and (2) keep the group on topic. It creates stress and you may feel or smell it in your armpits but it is a killer feature to bolster a group process. Not everybody can work like this.

Use a variety of methods for the same task:

1. Some people are creative in very open brainstorming sessions.
2. Some people like to work independently but co-create in “yes-and” settings.
3. Some people work visually in mood boards.
4. Some people like abstractions like seeking the patterns in user-interviews (e.g. He says: “I like long interviews because you get behind the scenes info on a person” and he says: “With an audience present in the interview its not as intimate anymore” $\rightarrow$ he may like to feel special)

Iterate: Have an idea, spin it, develop it, deploy it, get feedback, spin it, develop it, deploy it, get feedback; keep repeating and then just stop. Your output will be a working snapshot.

Produce for purpose: Many people get stuck with creative processes because they want great output. For a design process this is the wrong approach. With an iterative process you don’t go for great output, you merely go for good enough. You will always be able to improve on your output. But if the goal is to produce a prototype that sort of shows in a tangible way what you’d like your format to look and feel like, don’t fret with creative video editing. Your purpose is to give a sense of how this is supposed to look and feel, not to gain additional viewership on your publication. Writing this there is a hint in the word already: Publication is public. But public may not be the purpose.

Lastly, user centeredness: The process began with interviewing possible Hungarian users and developing a collective user-persona with specific needs and traits. All intermediate and final results were checked against these needs and traits. I put this aspect last because even though I know this isn’t standard procedure in developing design it should be.

These steps and all the others I didn’t mention yield results. In just 9 calender days we were able to create a fully fleged format for a department that works in a language none of us speak. And while this development process isn’t finished yet — Hungary will now produce the pilot — I can see that this product may be successful. The process delivered results.

Badies are antonyms to goodies. However, with respect to the process we underwent my critique isn’t related to singular bits that didn’t work for me. Rather, I’d like to propose the argument that the process delivered results through exploitation.

There are four aspects that seem to have made the process successful: (1) structure[1], (2) time pressure, (3) competition, and (4) highly motivated staff.

I discussed structure and time pressure above. Both seem to be the important guideposts to channel all that creativity into a well defined river of output. What I am concerned with is both competition and the highly motivated staff.

79% of the workshop time our staff goup was split into either two or four. Initially this provided smaller groups to work in and allowed to recombine and thus iterate the findings of the results. This is helpful because each group may develop a specific and highly useful focus. Merging these foci generally allows to add onto each other in a substantial way.

At two junctions the split groups competed against each other, however. Each sub-group would develop their own idea and then pitch it to a jury. The jury then would decide which idea to pursue further. After each such decision the sub-groups not picked would then merge into the other groups.

Now, instructors would stress during each of these competing rounds that »all ideas are our ideas« and it isn’t about winning or loosing. But this is just words.

Now, the main point here is that merging into new teams after your idea wasn’t picked isn’t too bad. I think it shouldn’t be overdramatized or overthought. But I’d like to point out that it involves emotional labour.

How do you integrate new people into a team? You explain to them why you made decisions previously, you try to work on the knowledge hierarchies that developed. Positions are sticky though: If somebody drove an idea early on they develop ownership for it and will retain this ownership even if new people merge into this team.

Ownership is an emotional category, however and the only way to build ownership in a new arrival or transfer ownership to the new arrival is through emotional labor: People who initially held ownership need to let go, listen to the new arrivals, ask them for feedback, see what they need, and (this may sound crazy) tend to their wounds from the lost battle before.

A tight schedule as ours does not allow to do that labor. Positions within the process become entrenched, with some doing the shitty work and others sticking with the fun stuff, knowledge hierarchies entrench with the new arrivals not really voicing their opinions anymore and thus attaining no ownership.

Such a process is emotionally draining. Ideas one worked on intensely get ditched and adaption to the new standard, the idea one got merged into takes an emotional toll. This toll is the emotional exploitation necessary to make the process work. If you have highly motivated staff, they will plough through it. They may have a healthy way of dealing with it or they will ignore it and work hard even though they are drained. If your staff isn’t highly motivated there numerous ways of ditching the process. But of course its a group effort and you pay in increments of emotion to be part of the group.

Footnotes:

• [1] E.g. Clear goal, good moderation, precise methods
Contents