Why you should get stakeholders involved in the design process

During a recent stakeholder workshop (ok, I actually wrote this last summer but didn’t publish it. I know, I know) , when I asked them to do a Crazy 8’s exercise, one of the stakeholders said

But that’s what Designers do right?

In other words, that’s what I’ve hired you to do. Yes, he is correct. But there are a number of good reasons for getting stakeholders to go through these exercises during workshops.

As a consultant working solo, it’s all too easy to become subjective in your approach to designing a product and deliver exactly as the client has requested despite practical and cost constraints. Whilst a stakeholder meeting before the project starts to capture requirements is the norm, there are learnings during the research phase that need to be shared that impact the ability to deliver elements of the requirements that project owners, especially, need to be aware of very early on.

Below are the stages I like to bring stakeholders in (including someone from the Development team) and why.

  • User Journeys – allows them to see their product or service from the users perspective
  • User Stories – thinking through every step a user takes to complete all tasks within a product allows stakeholders to grasp some of the complexities and challenges that need to be overcome. This is when the creative juices flow with ideas that can be added to improve experience and address some of the learnings from the user journey and personas. This is also a time for reflect, what happens if the user doesn’t behave as expected, how do you design for that.
  • Sprint Development Plan – time to get brutal and separate the must haves from the nice haves and frivolous. The Developer is not surprised anything, making the creation of the product back log a simple process. Many of the features and associated tasks will be re-thought and justified with the project owner. The reality of building the product is made apparent and everyone is focussed on the practicality of delivering those lovely ideas in the User Stories. Kinks are ironed out, alternatives are found and the development teams are solidified.
  • HMW’s – this is a great way of unveiling things that you might not even have considered so far.
  • Crazy 8’s – it’s all too easy for people to say I want it to be clean, simple and intuitive but what does this actually mean? What I may consider simple may not be your idea of simple. By getting all the stakeholders to sketch solutions to the HMW’s, they can convey their idea of simplicity or cleanliness better. For me, it’s not so much about the actual sketches, unless they are great off course, but the interactions and features. These things allows me to get a better understanding of the feel and interactions that can I can apply throughout the product or indeed eliminate because it’s something they don’t like or explain why it needs to there.

I don’t how many conversations I’ve had with UX Designers who get frustrated with projects because they’ve gone through the painstaking process of meticulously researching, defining and designing a product or service only for the client to make requests post-design or be adamant about what they want because of things they’ve seen elsewhere but cannot work in the context of this product and/or user. Or the classic, the developed product is nothing like the designs. Getting key stakeholder involved throughout the Design process avoids fictitious conversation further down the line, design and technical assumptions to be confirmed one way or the other and for everyone to feel a sense of ownership over the whole project (not get all territorial over their bit).

More than anything else, this a great way of developing client/stakeholder relationships. It makes for such a better design, development and delivery process.