Designing for all stakeholders
Understanding, prioritising, and balancing the opinions of all the key stakeholders in a product development process can be challenging. Here’s some of what we’ve learned about balancing multifaceted stakeholder groups over the years.
Developing a well-rounded understanding of the exchange of value for all stakeholders will provide you a foundation from which to create connected products that are valuable and desirable. But as with most design recommendations, this is more easily said than done. How can you arrive at an inclusive understanding of all the people and parties involved in a given user experience? How can development teams balance the needs of varied and disparate groups with often competing needs and desires from a solution? How can distributed teams weigh, prioritize, and leverage these insights once attained?
How round is well-rounded?
The first step to ensuring you understand all the relevant perceptions people bring to your solution is scope management. Your understanding of the exchange of value needs to be well rounded, not limitless.
In an ideal world, we as designers would be able to take every single point of view into consideration, to weigh everyone's opinion, to design every solution as universally accessible. But in the real world, businesses must pick their battles and prioritise their development efforts. When deciding how to divvy up development budgets, it's important that product or project managers have a confident understanding of who's perceptions will most affect the success of a product. For formative research during the development of visual brand expressions, it's important designers hear feedback from people who will actually shop for or interact with the products and services that brand offers. For concept development of new service delivery models, it's important the dev. team hear from people who will be responsible for making buying decisions.
The question of breadth versus depth will apply to any development process that doesn't have limitless resources (i.e. all development processes). When trying to determine the right mix of depth and breadth of understanding, it’s often easier to start with the breadth; how many different groups do we need to talk to, as this will limit the depth of understanding that can be achieved with each.
Here are two methods to identify and prioritise all the relevant stakeholders in a given experience:
Stakeholder ecosystem mapping
A participatory activity consisting of a predetermined canvas and notation system, Stakeholder Ecosystem Mapping, can be used to facilitate client, users, or project/product managers through to visualizing the network of stakeholders relevant to your experience domain.
Start with your own organisation, team, or product experience as a large circle in the middle of the canvas. From there use the notation system to build out the various groups and people types that make up your stakeholder ecosystem, using arrows, proximity, and size to indicate relationships between stakeholders.
Classic org charts
Or start with a tried and true method of visualizing the relationships between different stakeholder groups involved in a development effort: an organization chart.
If you don't have the time to commit or the moderation skills necessary to produce a Stakeholder Ecosystem Map, building an org chart specific to your project can go a long way to establishing shared understanding of who's at the table. A surprising amount of valuable insight can be gathered from creating these simple graphic models.
Whether it’s your own organisation, a prospective B2B customer’s organisation or a potential business partner, creating a relevant and meaningful organisational chart that identifies key influencers can be more difficult than you might anticipate. With that in mind, org charts should only be used as a starting point for further conversation as they only describe one organization and user experiences are almost always subjected to the perceptions of many individuals across multiple organisations.
What do stakeholders actually value?
Once you're confident you know which stakeholders are relevant to consider in the context of your development effort, the question turns to what those parties actually value. Rather than falling back on old internal assumptions, how can you really understand what a user finds valuable?
In the world of connected products, it's assumed that the value exchange starts when the user generates data for the connected product to process and is realized when the product leverages that data to provide an otherwise unattainable product function. But what otherwise unattainable product functions do users put a premium on? What about “dis-connected" products where the primary value proposition is less obvious?
The only way to understand how people define and perceive “value”, is to talk to them about needs and desires. It's often said that “people just want a faster horse”, implying users aren't aware of what they actually want or need. But before we can envision a new model of transportation (i.e. the automobile) we first have to hear people talk about how they aren’t getting where they want to go fast enough, how they don’t like shoveling horse manure, or how they wish they could retain visibility in inclimate weather. The broadest answer to this question is: Primary Research. Ask the questions you need answers to, from the only people qualified to answer them: your end users. But like our thesis question, that's more easily said than done.
Here are two tools you can use to gain an understanding of stakeholder definitions of value:
Value exchange mapping
A participatory activity that you can facilitate your project stakeholders, users, or product manager through to visualise the types and flows of value interactions between experience stakeholders.
A great build on the Stakeholder Ecosystem Map; once all the people and parties have been identified, you can now layer in the exchanges of value between stakeholders. Value streams might include the exchange of information or resources, interactions that inform known perceptions, or relationships and associations that generate (or erode) social capital.
Are there value streams that are being under-utilised? Where are there single direction flows? Where are there bidirectional flows? Is one party offering a value stream that the intended recipient doesn't actually find valuable? This tool can bring those questions to light and start to point to answers.
Another classic tool in the business world, stakeholder interviews are all too often carried out under the guise of fostering buy-in from executive stakeholders rather than an opportunity to actually understand what different parties at any level of an organisation find important about the product, project, or experience in question.
While it is important to communicate to the “high ups” in an organisation that their input is sought after and welcome in the ensuing development process, that is not the only value that can be gained from stakeholder interviews. These interviews are best undertaken at the start of a development process before resources have been invested in a given direction. Because this type of interview can be conducted via the phone with little to no loss in terms of quality of resulting information, it's best to carry out stakeholder interviews with as many stakeholders as you can.
Common questions you should ask of stakeholders include: “What does a successful product/experience look like for you?”, “Who do you think is the most important stakeholder for the successful adoption of the product/experience?”, and “What is the most exciting opportunity you see in the path forward?” Just like end users, the answers to these questions should be seen as representative and indicative of the ultimate goal, not a literal exposition of it. Questions like these begin to lay out the values and hopes that various stakeholders bring to the development process, which can significantly impact the course of your development efforts down the road.
Users aren't the only humans in design
At the end of the day the success of any design process comes down to balance. Human Centered Design is and should be the core of what we do here. But it is called Human Centered Design, not Human Dictated Design, for a reason.
A firm well rounded understanding of what users need and want is only one part of ensuring a successful product development process. Balancing the needs of the “User stakeholder” with those of the “Client stakeholder” and the “Manufacturing stakeholder” and the “Regulatory stakeholder” and any number of other relevant parties on the path to concept realisation is the real key to a successful design.
Hopefully the tools above can get you on the way to developing a well rounded understanding of the exchange of value for all stakeholders in your development efforts. If you get started down this path on your own and run into difficulty, reach out to us. Conversation is always the best next step.