RESOLVE THE MERGE CONFLICTS OF YOUR TEAM

Here’s a scene from our UOCD studio where team Preschool Musical is struggling to consolidate the final idea to propose. While the team is eager to move forward and produce top-notch sketch models, the team members are upset because they had assumed that they’ve already agreed upon a bold idea of BuildingBlox, a digital station for preschool kids in which they can engage in various creative and artistic activities.

“The walls are supposed to be plain digital whiteboards equipped with physical sharpies!” says Onur.
“No, they are smart panels that have kindle-like texture!” says confused Seungin.
“What? I thought they were pure digital kiosk-like screens”, says even more confused Sam.

The team stays silent for a moment. What is all this chaos? Didn’t the requirements table already specify the details regarding the actual product? The team soon concludes that comparing quick 2D sketches (with annotations) of what each team member envisions as “BuildingBlox” is a good idea to understand this seemingly complicated issue. The team soon realizes what went wrong.

Below are the short descriptions of how each sketch looks like:

Seungin: Smart Panels(digital) with natural texture and feel.
Danny: Projectors shining beams on the walls that create an immersive learning environment.
Sam: Digital Screens(like giant TV screens) with an interactive touch UI
Onur : Walls equipped with whiteboards that consist of an automatic capturing system
Minju : Walls where children can easily create artworks that gets automatically shared with the parents

The team is now clear on at least one point : the team needs to resolve these merge conflicts apparent in these sketches. So the team decides to face this issue straight by going through an entire day of integration. The meeting soon turns painful because resolving merge conflicts is challenging and time-consuming. It is a process that involves countless clarifying questions on minute details, but in the end it rewards the team with a fruitful product idea that is very clear to each team member. Now the team is able to move forward with the actual product realization process that involves sketch models and UI designs.

The lesson that a team of designers should gain from this anecdote is that clashing ambiguities and conflicts are signs that indicate discrepancies and gaps in the communication within the team. Proposing an idea is impossible unless the team as a whole is able to convey a single consolidated idea uniformly. Minute differences should never get ignored or go unnoticed because these small gaps will quickly grow into giant miscommunication problems that never get resolved. Thus, an explicit sync-phase that forces the team to face and resolve these “idea” merge conflicts is key to proposing a tangible idea as a “design team”.

This approach of “explicitly resolving idea merge conflicts” is particularly useful for designers of a team of roughly 4 – 5 people where such approach quickly synchronizes the pictures of the product in each team member’s mind. Doing activities like 2-D sketch and noticing the similarities and differences in ideas expedites the integration process for a group of designers of an appropriate size. Nonetheless, this method will not be as effective for teams of hundreds of people where gathering all the interest parties would be extremely challenging. In this case, designating a small number (2-3) designers to draw sketches and iterating those sketches based on the community feedback would be a more effective and fruitful approach to reach a finalized proposal.