Experience Design: Meeting Stakeholders Where They’re At

Communication is at the heart of designing and building software.

When undertaking a software project, it’s often necessary to build a consensus around critical decisions with a group of stakeholders. At Don’t Panic Labs, we use communication and design techniques to co-create a shared understanding between a client’s stakeholders and our development team. It’s a process that starts way before a developer writes a single line of code.

Our collaborative team focuses its attention on delivering maximum value for the business, its stakeholders, and its software users. Our design processes mold to the needs of each project, but we document our learnings in the form of conversations, whiteboard drawings, sticky notes, wireframes, mockups, and prototypes. Often our most important design tool is direct interpersonal communication. To meet stakeholders where they are, I use a few guiding principles.

Participate Actively in Conversations

A stakeholder is an expert with critical knowledge and insight. There is a reason they are in the room. It’s our job to find out what they know about the project’s objectives and critical pieces. Actively listening helps us consider the stakeholder’s words with their body language and actions. When considered together, these verbal and non-verbal signals help us gather additional hidden concerns. Two of the most important questions to start with are:

• What are the project requirements?
• What outcomes are desired?

Each stakeholder and team member might have different answers to these simple questions because they also have different roles and needs. We listen, understand, respond, and record. By creating space for each participant to speak, we open the door to probing for hidden, critical insight. When we ask contextual questions, we can build a more accurate understanding, which in turn helps to build a better-fitting solution.

Build Empathetic Understandings

On our quest to define a sharable project understanding, we need to understand the problem from each stakeholder’s perspective:

• What does this product have to do with the stakeholder’s role in the company?
• What desires are they expressing?
• What pain do they want to alleviate?
• What value does the product create for the business if this stakeholder’s pain is minimized?

Some of this information will come from what isn’t said, or by inference, rather than direct questioning.

Even when these reflective questions are not useful in building the definition for an end-product, they are helpful. When we have a sense of who each stakeholder is as an individual, we can better create buy-in when talking through problems or explaining proposed solutions. The most important practice is to build curiosity about the distinct kinds of needs your expert stakeholders may share and what might make them differ.

Create Feedback Cycles

Product design leverages a variety of methods and mediums to accurately convey ideas and discover issues within large groups. We strive to create an environment where all objections can and should be made. We use this feedback to improve design documents as an iterative, responsive process. Everyone should feel like they are contributing to the project definition. The important part is that we stop to share and reflect; we need to gather feedback from stakeholders at critical junctures.

The need for feedback cycles goes far beyond the initial definition and first build. Whenever possible, they should be baked into your product’s future by including opportunities for regular and robust feedback from the stakeholder and users.

Raise the Flag

Often there are unforeseen complications in a project. It’s imperative that our cooperative team identifies and shares these risks so they may be evaluated. If a risk can be mitigated, communication allows us to take corrective action before it becomes a problem. As new concerns arise, we must be permissive of them and encourage transparency, even if this is against our natural state. If concerns become disruptive in a meeting, a more passive channel could be opened for these concerns (like email, Slack, or a Teams channel).

Trust but Verify

One of the most critical parts of our job as professionals is to ask tough questions to help identify and mitigate project risks:

• What are we missing?
• Is this issue a problem we need to deal with right now?
• Have we considered these possible alternatives?
• Are there more urgent needs being expressed?
• Are we talking about separate but related problems?

As we add definition to the project, we apply the mindset of “Trust but Verify” so we can critique the project without assigning blame to individuals. It’s important to remember that no one person knows all the things or has all the answers.

At Don’t Panic Labs, we know meeting stakeholders where they are at can be challenging, but getting their participation is critical for the success of each project. Each team has its dynamics and knowledgebase. Each person has their role(s) and critical views. Ultimately, we are trying to cooperatively define and then achieve a set of feasible objectives (measurable goals) that everyone agrees to. As a design partner, we learn to speak your language, curate a shared understanding, and clarify a path to building a valuable product.