Friction in the Design Process

On the heels of an article I wrote in 2021 on the topic of Design as an Influencer versus Design as a Stakeholder (which you can read here), there’s another aspect to this narrative, specifically centered on Friction which appears during the application of the Design Process itself (and which can take many shapes). One of the questions Designers always get asked, particularly in the context of interviews, pertains to how they react to blockers or impediments to the application of “their” process (as if the Design Process or Human Centered Design methodology posits ownership of the process and its outcomes solely on Designers, and not on the entire team involved on that journey). This article is a reflection on the different Friction types I’ve encountered and some tactics I’ve adopted, based on what I learnt from conflict resolution in classes, and from Organizing workshops themselves. As always, hope this makes for an interesting reflection.?

How does Friction Manifest itself in the Process. I’ll begin this part of the article by stating that friction will occur frequently during the entirety of the Design process itself. That is not a manifestation of some particular unbalance in the process, it’s actually a manifestation of the fact that the process itself involves a group of people with very different backgrounds and viewpoints coming together to generate a solution. Inevitably and as is the case when people collaborate, there’s friction that manifests itself. And by the way, friction doesn’t necessarily have to have a negative connotation to it. From friction productive growth can be experienced, both for the teams themselves and for the solutions that is being shaped. Here’s some examples of friction I’ve witnessed in the past, how they manifest themselves and possible venues Designers can tackle in order to overcome them.

The Servicing Experience, aka, still the most habitual perspective. Which is to say, Product and Development teams decide what they envision the feature/product/solution actually be, and eventually engage with Design solely to create the artifacts needed to manifest what they’ve outlined. This actually ends up being counter-productive, since it doesn’t account for research, problem and user definition, and invariably doesn’t contemplate iterations and testing. Needless to say this is a perspective that has grown progressively more outdated and worrisome, since it invariably translates into solutions that are a myopic representation of the people who have defined them, and not necessarily the users’ needs. Solution, typically involves explaining and demonstrating what and how the Design Process actually operates. It’s up to the Designers to demonstrate through strategy, data, artifacts, how the collective process actually delivers value and is cost efficient.

The Design Process is Cumbersome, aka, the process takes too long and we need something quickly. For some reason, and I’ve witnessed this across various Organizations, there’s this notion that the Design Process because it involves a considerable amount of research, it is going to be something costly and that will take months on end. Now depending on the complexity of the problem, resources (both human and material), that may in some particular situations be the case, but for the most part Designers are flexible enough where they can deploy lean methodologies and techniques which considerably improve both efficiency and outputs. The whole notion that because something is needed by yesterday, that it should curtail testing and research, is part of a bigger problem (and friction). Solution, independently of the time crunch I’ve been on in the past, the most successful solutions were always the ones that myself and my team were able to rapidly prototype, test and assess the qualitative and quantitative feedback that was provided. It ended up empowering a better solution and always resonated further with clients.

I already know the Process, can we get this going faster, aka, I’ve been exposed to some Human Centered Design training or product development journey, had a less than solid experience with it and want to quickly move through this with as little investment as possible. This is quite possibly one of the trickiest forms of friction that can occur. Some of the participants of the process, have actually been made aware of the principles of the Methodology, and understand it to a certain extent, but either through a poorly carried prior experience, or due to a certain bias, don’t really have much investment in the process and engagement itself. These situations have occurred to me in the past, and actually more than once. They have also revealed themselves to be the harder ones to solve for, firstly because the Design Process and Methodology has somehow been tarnished in these team members’ eyes, and secondly because as Designers, the path to gain credibility is that much steeper, since you’re basically stepping on the shadow of what others have possibly done, and sadly probably not so greatly. Solution, much like the first friction point identified and its respective solution, the goal here is to engage with the team members sooner rather than later, create a joint strategy that encompasses what needs to be done for all the team members, and outline dates, artifacts and outputs of the process itself. Establish accountability, not only from the Design team, but from everyone on the process. Only then can trust be built and reliability can be established.

Facing Friction. The reality is friction is part of any job, independently of the role being played (independently of the scale of the organization). The disparity between what is expected, general ambitions, and what can be effectively rendered and delivered, can at times be considerable. And friction most of the times is associated with either expectations not being met, or insecurities being brought forth, even fears of ambiguity, and ultimately non existent trust. Typically in well established teams, the likelihood of friction occurring is of course always there, but it’s something that is usually minimal, because trust has been established, habits have been made aware, and people know what they’re walking into, and what their role is going to be. The tranquility of knowing what your role is, who the people you’re interacting are, causes less anxiety and friction, since there’s the comfort of the habitual and of the well known. However when it comes to problem solving, and particularly for Designers, it’s important to remember, that often times you’re indeed walking into the unknown, that teams may not be that comfortable with each other. And that’s just part of the journey. Embracing friction doesn’t make it go away, but if defuses the fear that it may dramatically crack something beyond repair. It’s not the end of the world, and it’s not definitely the end of the process itself.

Reality Check. It’s important that Designers look at each challenge for what it is, and not for what they expect it to be. Friction is indeed associated with a plethora of reasons that have been expanded upon above, but they can always be ultimately traced to people themselves, and to less than stellar communication. Transparency about intentions, about journeys, strategy, outcomes, expectations, responsibilities, always allows for everyone to understand where they stand, and just as importantly, where their peers stand. This notion of roles, and just as importantly, of what lies ahead allows people to better understand THE path, and what the solution ultimately should be about.?

I’ll conclude with a quote from Confucius on the topic of friction:

“The gem cannot be polished without friction nor man without trials.”