Design the stakeholder experience

To get the stakeholders on track for a successful UX project, use your skills and design the stakeholder experience.

Design the stakeholder experience

“Stakeholders” are business managers, developers, marketers, visual designers – anyone with a vested interest in the success of the product. Their involvement in the creation of the product is essential – without them, there’s no product. But when you’re doing user experience design, you’ll often find that these essential team members will boo your designs off, mess them up or just ignore them. Here are just a few reasons why…

  • People don’t understand your design ideas.
  • They can’t remember them.
  • They don’t know they exist.
  • They can’t find them.
  • Business reality means they can’t afford to implement them.
  • People don’t know what alternatives were considered.
  • They don’t know what evidence supports them.
  • They don’t know what criteria the designs are supposed to satisfy (what the product has to actually do).
  • They don’t know why the user experience matters.
  • People think the ideas are too difficult to implement.
  • They think their idea was better.
  • Their idea actually was better.

To help deal with these issues, think about the user experience you’re offering stakeholders. Could you design a better one that helps them do their jobs more easily, and participate in UX projects more constructively. I’m not advocating a huge meta-design effort.  But applying some of your experience design expertise in a fairly quick and dirty way seems to make sense. Here are some tactics to consider…

8 tactics for designing the stakeholder experience

Run a buzz campaign. Stick your work up on the walls of a war room. Yes, this lets you immerse yourself in user research and design ideas. But it also shows nearby stakeholders that you’re doing something. Something quite big and complicated and interesting. If people can see tantalising glimpses through war room windows, they’ll often invite themselves in to take a look at what you’re up to. Great.

Something interesting from a war room

Involve stakeholders in concept design. Start early in the design process. Let stakeholders voice their requirements, ideas and constraints in workshops where other stakeholders can hear them. Then everyone discovers the problem landscape together and sees the conflicting issues that will need to be resolved. The interaction designer becomes the facilitator (hooray), rather than the go-between (ouch). To make sure every stakeholder knows they have been heard, write each point on a sticky note and file it in the right place on the wall.

Listen. Developers have lots of wonderful ideas, often very pragmatic. Sales people and support people know your target customers. Marketers excel at articulating the vision for the product. Involving them all in concept design helps them to understand what you’re trying to do, and provides you with new perspectives on how to do it.

Communicate in digestible terms. Most people working on software projects are control freaks. Developers are among the worst offenders (right up there with interaction designers). It’s hard for a control freak to absorb complex, multi-part ideas, because they are tempted to dissect each component idea before the gestalt becomes apparent. The component ideas work together to make the user experience concept. Picking them off as they are mentioned means the big idea is shot to pieces before anyone can see it in its entirety.

You can prevent this from happening by communicating in the right order. When presenting formally or informally, always start with the 60,000ft view – what’s the big idea and what are the user needs that support it. Then go back over the ground in increasing detail, until you reach individual features. It’s only polite, really: your presentation should not be a mystery tour.

Improve findability with a UX wiki. Lists of files on a shared drive don’t cut it, because file names can’t contain enough information scent to make the right document easy to find. A wiki is quick to build, and can lay out the available information in a much more human-readable format. A wiki is also nice and searchable, and a decent wiki that supports tagging (or multiple categorisation) gives you semi-automatic cross referencing of pages.

Components of a UX Wiki

Wiki IA: Start with foundation pages including business needs, competitor products, personas, goals, key scenarios and design drivers. Next create pages to address the interaction framework and style guide, plus visual style guide. Finally pick off interaction design feature by feature (following the structure of your storymap, perhaps) and cross reference back to the foundations and the style guides elements. Pages should have comment threads linked to them so that people can discuss and evolve the ideas they see and so that the discussion can be preserved forever, rather than being lost in people’s mailboxes.

Help stakeholders to recall complex information. Rationale is the “reason why” a design decision was made. At the time a decision is made, the reasons behind it (should) seem clear. But it’s amazing how much the whole stakeholder group will forget, as the project rolls on. And so will you. Write down the why for every major decision, and keep a record of any rejected ideas that got drawn/written up. Revisiting old ground is inevitable, but make it quick and you will save days of time and lots of repetitive arguments. You’ll also look very impressive and well prepared when you bring out the rationale document at the right moment.

Create the right conditions for developers to solve difficult problems. “It can’t be done!” is the understandable cry of many a developer when first faced with the challenges that a user-centred design project inevitably brings. Typically this means, “I haven’t yet worked out how to do it.” Try to re-frame the statement as question and to encourage people to believe there is a solution (go from “It can’t be done” to “How could it be done?”). Imply that whoever could find such a solution would earn their colleagues undying respect. Then leave the topic open for a few days. Developers love to solve problems – that’s why they chose the job. More often than not, they’ll come up with an answer.

Allow for instructive failure. If stakeholders insist on doing things in a way that you believe will fail, step aside gracefully. Document what you think the right solution is and make sure you are on record saying that you disagree with the chosen direction. Then wait. If things go wrong, later, you are in a position to pick up the pieces, and earn some respect in the process. This one works well on agile projects, where there are usually opportunities to change things later. On waterfall projects it can take years.

More please

Experience design is about working with human behaviour to get favourable outcomes. You’ll get better results and a happier team if you can apply those principles internally to projects too.

What other UX design principles do you apply to the stakeholder experience? I’m collecting ideas so please post a comment.

One thought on “Design the stakeholder experience

  • October 15, 2009 at 7:02 am
    Permalink

    there’s a saying that goes – sell like you’re buying. I’ve always seen that as – If I were them – what would put me off – and what would I like. When I buy something I go look at the features, skip the marketing splurb and the go hunt for the bad reviews in order to make an informed decision. So I guess the same goes for when I try convince someone to buy in. I try and anticipate the shortcomings and be transparent about it from the start – which people appreciate and it also makes them feel part of the solution – because they have input all the time. They don’t feel like I’m telling them what to do – but rather start seeing the whole process as something collaborative. Also, from the start of each project I sort of do a little guerrilla inquiry by basically trying to figure out who’s who – preferences they have personalities, the interpersonal behavior and who’s really calling the shots. I try to pick up on previous projects and most of all what their personal experiences were – why they didn’t like things or what went wrong. I make notes of these and then decide on a strategy of how I’m going to best achieve what I want to by targeting or engineering for the people I know will have the biggest influence on the project. A lot of the time the boss is not the biggest obstacle. The dynamics on any project are driven by the people in the team and by truly understanding the people – and designing your own service around who they are and what they want make things go a lot smoother. With every presentation I do, I try to work up personas of the people that’s going to be listening to my presentation – these influence time, language, domain topics and content, what they’re trying to get from my talk (on a personal level and not just professional) – anybody in the presentation I know of that will be more resistant or influential – and if so – I want to focus more on that person whilst not alienating the rest. Nobody else sees my personas, so quick little notes and stickies which I add to my project folder and refer to throughout.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>