Convincing the organization to embrace a new IA is no small task. Effective communication with key project stakeholders is essential for winning—and keeping—their support in managing change. Cross-functional stakeholders typically present diverse and, sometimes, conflicting requirements that must be successfully reconciled. This presentation describes how the Mathworks Documentation Group engaged with various stakeholders across the organization to redesign and implement a new Help system over the past three years. Learn how our communication strategies and tactics helped us to build organizational consensus around requirements and structure design reviews to inspire support for the new IA across the organization.

1. BEST PRACTICES FOR
COMMUNICATING WITH KEY PROJECT
STAKEHOLDERS
A Case Study
ENA AREL
Information Architect
MathWorks 1

2. Overview
About MathWorks culture
Our project scope
Our stakeholders
Our communication best practices
Lessons learned
2

3. About MathWorks
MathWorks is the leading developer of
mathematical computing software.
Engineers and scientists worldwide rely
on its products to accelerate the pace of
discovery, innovation, and development.
3

4. About MathWorks Culture
We cultivate an enjoyable, vibrant,
participatory, and rational work environment
that
• Nurtures individual growth, empowerment,
and responsibility
• Encourages initiative and creativity
• Values teamwork (consensus building)
4

5. About Our Documentation Group
 60 Content Developers
 9 Editors
 3 Toolsmiths
 1 Information Architect
 1 Program Manager
5

6. This is a story about what worked
for us…
6

7. Effective communication with
stakeholders is essential to innovation…
7

8. The Project: Help System Redesign
Respond to customer feedback
Reduce waste
Innovate and position us for the future
(mobile, tablet, better integration with software,…)
8

9. “Let’s make
our
documentation
better!”
9

10. Project Challenges
 80+ highly technical software products for
engineers and scientists
 Stakeholders at various levels of the organization
with different priorities
 Products have complex and sometimes unique
documentation requirements
 Complex tools chain, delivering documentation that is
both on the Web (mobile, tablet, etc.) and tightly integrated
with installed products
10

11. What We Did
Dramatic redesign of current Help system
with significant impact on user experience
For example…
11

12. Transitioned to Browsing by Categories
Before After
12

13. We Had Book-Based Navigation
Before
13

14. Transitioned to Browsing by Categories (continued)
After
Reference
Category page
Product page
landing page
14

15. Forging a Stakeholder Strategy
#1 Who are the stakeholders?
#2 Stakeholder communication strategy
15

16. ICN Model Used at MathWorks:
Identify which Stakeholders are in
Inform vs. Consult vs. Negotiate
roles
16

17. 1. Who Are the Stakeholders? (continued)
Toolsmiths Customer-Facing Organization
Who Will Teams Who Will Leadership Team
Implement the Show Help to
Design Customers
Our Customers
Product Teams &
Writers Who Will
Adopt Design
Negotiate position
Consult position
17

18. 1. Who Are the Stakeholders? (continued)
When identifying Negotiate Stakeholders, consider:
 Who can assess the project against the overall
business needs of the company?
 Who will stop the new design from being built if they
don’t like it?
 Who can provide resources for the project?
When identifying Consult Stakeholders, consider:
 Who can provide additional and/or unique perspective
on the project?
 Who will be most impacted by the project?
18

19. Effective communication with
project stakeholders is essential
for winning — and keeping — their
support in managing change…
19

20. 2. Stakeholder Communication Strategy
1. Create a formal design review body consisting of
Negotiate Stakeholders
2. Get input from Consult Stakeholders early and often
3. Get Negotiate Stakeholders to agree on
– Customer and internal pains to address
– Design requirements
4. Keep Negotiate Stakeholders happy by
– Validating their feedback (e.g., via email)
– Communicating how you addressed each feedback point
(e.g., using Before/After mock ups)
– Providing clear rationale for each design decision
(requirements, user feedback, implementation feasibility)
20

21. Even with a good strategy,
effective communication tactics
are necessary to get from
prototyping to shipping…
21

22. 8 Communication Best Practices
22

23. 1. Recast design suggestions into requirements
“ Can you remove that Functions link from
the product pages?
”
It sounds like you want to de-emphasize access
to Functions…
Is it still a requirement for users to access
Functions easily?
Let’s explore ways we can de-emphasize the
link without completely removing it…
23

24. 2. Reconcile conflicting requirements
24

25. 2. Reconcile conflicting requirements (continued)
“ Remove all navigation aids from left
gutter! Keep it clean!
”
VERSUS
“ We’d like the ToC for navigation!
”
25

26. 2. Reconcile conflicting requirements (continued)
26

27. 2. Reconcile conflicting requirements (continued)
27

28. 3. Carry design alternative up your sleeve
28

29. 3. Carry design alternative up your sleeve (continued)
Bug Reports
29

30. 3. Carry design alternative up your sleeve (continued)
 Provide multiple designs for elements that are likely to
be controversial
 Design alternatives should meet the same requirements
 Present each alternative as a user scenario
30

31. 4. Build consensus offline, as much as possible
31

32. Ne-ma-wa’-shi (Japanese)
Technique for building consensus
in the organization
From “The Toyota Way”
32

33. 4. Build consensus offline, as much as possible (continued)
 Nemawashi is an alternative to standard Western style
meetings with debate and clashing positions
 Goal: Airing points of potential conflict “pre-meeting”
 Technique:
– Present proposal one-on-one or to small groups
– Methodically cover all likely key influencers
– Iteratively hash out controversial points
– Present proposal to all Stakeholder after offline consensus has
been reached
33

34. 4. Build consensus offline, as much as possible (continued)
Questions to ask during Nemawashi encounters:
 Do you completely hate the idea?
 Do you like some parts and not others?
 Do you have specific suggestions for improving it?
 What do you think is needed to improve the chances
that the idea will be accepted?
34

35. 5. If someone else speaks up for the design, let them
35

36. 6. If you can’t do it now, explore ways to do it later
Phase 1
Phase 2 … Future
36

37. 7. There is a Truth in every piece of feedback
37

38. 8. Take Stakeholder pulse regularly, and respond
38

39. 8. Take Stakeholder pulse regularly, and respond (continued)
39

40. Summary of Our Best Practices
40

41. 1. Recast design suggestions into requirements
MathWorks Best Practices 2. Reconcile conflicting requirements
3. Carry design alternatives up your sleeve
4. Build consensus offline, as much as possible
(Nemawashi)
5. If someone else speaks up for your design,
let them
6. If you can’t do it now, explore ways to do it later
7. There is Truth in every piece of feedback
8. Take Stakeholder pulse regularly, and respond
41

42. You have succeeded when your
Stakeholders and you feel like
there are no surprises…
42

43. Main Lesson Learned
Stakeholders in “Consult” role need to feel like they are
more involved in the design – especially the Content
Developers!
We gathered input from Content Developers through
Managers, which was not the best way to do it. Although
we incorporated much of their feedback, the writers didn’t
feel their contribution.
We should have gathered it directly from the Content
Developer so that they felt how we were directly
responding to their input.
43

44. Thank You!
Ena.Arel@mathworks.com
44