On compromise in product design
As a budding product designer still putting forth shoots in my career, my wrist found itself perpetually slapped for the same infraction: ~*compromising with developers*~. Ah yes, compromise, that proverbial wolf-in-sheep’s clothing plaguing many a well-meaning softy. After much rumination, however, I have found that compromise, while very occasionally weaponized by adversaries attempting to dodge the hard stuff (see: sandbagging), is an essential tool in delivering value to our end users (see: real people).
The presenting symptoms of imposterus defectus syndrome known colloquially as imposter syndrome, vary on a case by case basis. For me, assuming responsibility for the failures of others is one manifestation of the disease. Often times this is what triggers a compromise in the first place. I wrongfully assume it will be solely my fault if developers can’t build the designs I hand off, which will result in our company shutting down, everyone losing their jobs, and an angry mob throwing Molotov cocktails through my windows late into the night. As a result, I am often tempted to unnecessarily come up with something a little more, shall we say, simpleton. There is nothing inherently wrong with a simple approach. The issue arises, however, when this diluted approach no longer provides value to the user. On the flip side, by only serving up the end state of a design, we can potentially delay the release of value to our users.
Therein, folx, lies the crux.
While it is important as a designer to detach yourself from the outcomes of your dev team’s efforts (it’s not your fault if they fail a sprint, really) a lack of compromise smacks of waterfall. So, where does that leave us. Well, in order to magellenically navigate the metaphorical Cape Horn that is a compromise between design and engineering (okay, okay, it’s not quite that dramatic) I’ve created a simple framework. In order for there to be fertile ground for compromise, there are two conditions that must be met. Without these, you might be in danger of failing to deliver value to your users and might need to lean further into the work of inspiring your team to greater heights (which they are, in my experience, always capable of reaching). The framework is as follows:
In order to ensure we are delivering value to our users, these are the two conditions that must be met before a designer should pursue compromise:
- I have communicated a clear vision. As a designer, you possess the unique power of giving form to the abstract. Equip your team with the power of sight, a tangible vision of what something could be — not what it is right now. We can’t build what we can’t dream and your job as a designer is to be a dreamer, to see what others haven’t yet seen and open their eyes to what is truly possible. What does this have to do with compromise? This is a way to mitigate “sandbagging” (I hate that word btw), which is more likely to happen when product owners and designers fail to inspire and unite their teams around a shared goal.
- I’ve identified a way to decompose my designs and still provide value to our end users. The design can be broken down into smaller increments that will help us validate something (tech stack, integrations, product-market fit, etc) while ALSO providing value to the end-user. There is absolutely no point in releasing something that provides zero value to the people using it. However, if there is a way to break down your design into smaller, incremental states that will help the team validate something while also delivering value to your end-users more quickly, for god’s sake compromise!
And there you have it. As a designer, it can be difficult to detach myself from the outcomes of my dev teams, but the only tonic is trust — trust that they are talented professionals equipped with positive intent to deliver value to real people. For some designers, it can be tempting to succumb to cynicism, that developers are going to try to do the least amount of work possible to stay employed. I believe this outlook is not only grossly unfair, it is fatalistic and can become a self-fulfilling prophecy. By externalizing the product vision and appropriately decomposing your work, designers can create an environment where compromise creates more value for users instead of less.
