bridgebuilding 101 - part one
When a company is design-antagonistic or (more likely) unsure of how to work or utilize designers, it’s important to invest in building bridges with other parts of the organization. As a user-centered designer, my approach leans on the main principles and techniques of user research: (1) understand the underlying needs of your stakeholders; (2) by aligning needs of your stakeholders and the company, identify areas of opportunity that could remedy one situation; (3) bring the stakeholders into your process through co-creation.
Let’s walk through with a few different kinds of stakeholders with more specific examples and tactics:
In enterprise software, these should be the people that you’re incredibly close to. They’re the front lines of dealing with questions from customers and are likely internal power-users of your software. I’ve seen some of these relationships go awry by not including them in the process. The tack here is to treat them like analogous users (but don’t overfit here) that you could lightweightly ideate and sanity-check with.
Just start by picking one person that is a loud advocate - they have been finding patterns of problems, and are asking for X to be changed. Dig into the highest-priority request that they have (priority according to them) have why they think X needs to be changed. Their request is usually baked in some amalgamation of customer requests, but if it’s from the left field somewhere, then ask them to forward you customer call notes or emails that pertain to it.
Once you’ve gotten to a common understanding of a problem that is also a strong customer problem, lobby suggestions back and forth of other ways to do it (also known as brainstorming/ideating!). And then get it done (and rolled out to customers), and take on another problem. Once they see that you can help them solve concrete customer problems in a more systemic fashion and reducing customer calls, you have built trust! You can start pulling parts of what they’re doing into the product development cycle more systematically. For example, you can build in analyzing customer requests to help prioritize work, building relationships with customers to do contextual inquiries or other qualitative research, using some members for some kinds of usability testing, making sure they’re invited to some brainstorming sessions, etc.
This, of course, predicates on your stakeholders being aligned foremost on what the customer experience is (few calls to customer relations, in the example above). If their main concern is to create a cohesive experience instead of improving efficiency of their part of the organization, then your solutions may lie in the realm of voice and tone guidelines and providing systems for your stakeholders to use instead of fixing a particular customer problem. Get at the why, and make sure everyone is rowing in the same direction organizationally (if this isn’t happening, you’ll need to make sure to build bridges with the leadership team first).
To be continued with engineering!