Contending with stiff constraints, often resulting in a watered down design vision, is a common burden all designers face. Itâ€™s a major source of friction, having to deal with the inevitable frustrations of hearing â€œNoâ€ from engineers ground down by “death march” schedules or nervous managers highly reluctant to address risks. Often the designersâ€™– themselves worn by frayed nervesâ€” respond with an impassioned, â€œWhy canâ€™t youâ€¦â€ or â€œWhy is this so difficultâ€¦â€
Such questions just persist the frustration and antagonism of an unhealthy conflict, perhaps even painting an unfair shade of whininess upon designers who simply wants a vision delivered per spec. I mean, is that so wrong?
Well, I have learned (quite painfully at times, I admit!) to handle such situations by raising questions that enable a more constructive, collaborative approach while poking into the flexibility of these constraints…
1) “Help me understand the issue”: I know, this isnâ€™t really a question per se, but itâ€™s an invitation from the designer to the engineer (or manager) to start a mutually beneficial, educational dialogue. Offered genuinely, it suggests a desire to want to learn more about the issues, conveying a sense of empathy, and strokes up the otherâ€™s ego a bit, now being seen as an expert whose knowledge is sought. Also, this phrasing gets everyone talking, thus listening and understanding, not accusing and defending, resulting in hostile vibes. A far more personable, complimentary approach than the accusatory â€œWhy canâ€™t you build thisâ€. Â Conducted well with healthy skepticism (the five whyâ€™s, etc), this dialogue can lead to discovery of underlying issues of a business or organizational nature, not just stubborn programming matters.
2) “What would it take?”: This is simply a re-framing that turns an accusatory, defensive questioning Â into something far more productive, as a problem solving exercise to achieve the implementation goals. Again, itâ€™s an invitation by the designer to empathize and learn about the details, encouraging everyone to brainstorm options to achieve a desired result. Then everyone can have a smart negotiation around precisely those success factors: schedule, budget, resources, skills, tools, etc. And perhaps even a revisit of fundamental purposes and principles, which is not a bad thing at all when tempers are high.Â
3) “What if weâ€¦”: Finally, offering hypotheticals shifts everyone into a mindset that is exploratory and optimistic. Of course, with tight schedules and related pressures, minds close down into deeply myopic views of whatâ€™s feasible right here and now. And there may be just resistance. However, a tentatively offered â€œwhat if” prompt opens up unseen options, shaping a problem solving dialogue engaging the team’s creativity. For example: Maybe we donâ€™t have to build everything this release but we can prioritize on two features, while we beta test a third next quarter. Again, this approach might involve a revisit of project goals and values.Â
As you can imagine, these tactics can and should be used together in various ways, for collaborative exchanges with the team. After all, not every denial is truly an absolute Â roadblock, but might be a desperate, hidden invitation to dig deeper into unseen issues everyone is simply too stressed to confront at the moment.
As designers, we can enable such crucial conversations that lead a more constructive relationship, ultimately for the customersâ€™ benefit! After all, isnâ€™t that why weâ€™re all working so hard on this project, for this deadline?Â
** Note, my assumption here is that weâ€™re all dealing with rational, mature adult professionals on a team. Seriously, if folks react badly to these tactics, there might be some deeper personnel or project management issues! ;-)Â