Day 2-Documentation Your Team Will Actually Use

dy1

— Today’s topics is about documentation and what team will actually use, and will cover common pitfalls, what teams actually needs, process for documentation, delivering incremental value

 

dy2

— So I have a lot of things to say when we say docmentation
  • Two main types
    • The first is detailed processes and policies made by people managers or designops
      • How work done at organization
      • Playbooks, manuals, project templates

 

dy3

— The second of various projects
  • Why decisions made and researching findings

 

dy4

— We will focus on documenting process and policies, through the playbook artifact, but strategy is agnostic

 

dy5

— A playbook is a document to streamline process by having codified record of design practices, standards, and more
  • What is it made of?
— Typically organized in stages of work
  • Each stage matches org mental model
  • Plays will have relevant info like instructions template, and links on when used

 

dy6

— See example of playbook model created above
  • Can see org process like recruiting and analyzing and collecting data
  • Has clear navigation
  • Quick links
  • Next steps in process

 

dy7

— Zooming in to specific playbook, there is info on way to email participants and why this matters. Other items include:
  • Removing ineligible contacts from the link
  • Quick links for specific info
  • Explaining why info matters for users?
  • More detailed instructions later on

 

dy8

— Why do this?
  • Our teams do a lot, as average UXR toolkit has 13 tools and playbooks are useful to new hires and junior designers
    • Important for tenured designers as well
  • Unclear processes frustrating for all designers
    • 26% of designers said no clear process was one of top 3 frustrations

 

dy9

— There are common pitfalls though:
  • I have a history of failed playbooks, with four playbooks, two toolkits,
    • At consultancy I had repeatable work with designer and driven crazy by asking same questions over
  • Documents were put into SharePoint, which only I could find
— I changed the info into a slide deck, but meant no way to distinguish between usable slides and explanatory slides

 

— Contributed to research manual, which had a lot of words and hard to digest

 

— Most recently moved to Coda Wikis, but there I had too many documents to know where to look for which content

 

dy10

— So here are the common pitfalls
  1. In-actionable information
  2. Difficult navigation
  3. Cognitive overload
  4. Outdated content

 

dy11

— Pitfall #1: Inactionable Information
  • Have you visited recipe blog which has block of text before the recipe?
    • This frustration is what to avoid for the design team
  • This principle took the longest for me to learn
  • People want info specific to org, and grasp what is needed, i.e. how to share wireframes
— To avoid this irrelevant wall of text, leave out generic content, and link to external resources

 

dy12

— Pitfall #2: If folks can’t find info, doesn’t matter how well it is written. Lack of findability can manifest in the following ways:
  • People can’t find the doc to begin with
  • The document structure that doesn’t match processes
  • There is limited search functionality
— You need to match navigation framework to the team mental model and make sure they know who the doc is written for

 

dy13

— Pitfall #3: Content can be overwhelming in the playbook
  • A lot to absorb prior to research
— Avoid
  • Walls of text
–Instead
  • Create visual hierarchy
  • Cut off the fluff

 

dy14

— Pitfall #4: Old information can erode trust and is no longer relevant
  • Poor info in one area will erode trust area as people will think playbook info is not relevant everywhere
— Review content on regular basis as it is important to keep info up to date to keep trust with team

 

dy15

— So let’s talk about moving ladder to success
  • Approach documentation as design problem

 

dy16

— Here’s a description of the process from the Interaction Design Foundation
  • Emphatize — Research user needs
  • Define– State problems
  • Ideate– Challenge assumptions
  • Prototype — Create incremental solutions
  • Test- Test solutions out

 

dy17

— The documentation would be slightly different as we  would prioritize most important information and prototype with expectation of imperfection
  • There’s also the final step of circulating documentation

 

dy18

— The steps are presented in chronological order, but you might not follow it linearly and likely won’t do so at all

 

dy19

— So let’s empathize and grasp how team is currently getting info
  • Processes need to grasp reality of what it is
    • Don’t dicate process, especially if you are new to an org, and don’t deliver a playbook from ivory tower of DesignOps

 

dy20

— Grasp how people work and what they need help with
  • Ask ICs to walk through their documentation process in interviews
— Survey the team to grasp trends from interviews and  a baseline for future metrics
  • Create confidence in process and satisfaction in documentation
— Have desk research to grasp existing usage of doc you currently have and review messaging channels like Slack or teams to understand what people are asking about most often
  • Can do this 100% on your own

 

 

dy21

— Prioritize and find biggest impact of documentation

 

dy22

— Your audience can be
  • Individual contributors and those who do the actual work
  • Audience as managers of teams
  • Stakeholders for what team does
— But assume IC as most common audience

 

dy23

— After empathy building, you should have good idea of what is needed
  • Need to focus on biggest pain points of team experience
— If ton of things to prioritize, use design facilitation schemes or putting things on value effort matrix to find the biggest priority

 

dy24

— Deliver small but complete sections and deliver value immediately

 

dy25

— I’ll leverage the analogy of  incremental value for building a car
  • Using incremental approach to deliver value and lean delivery
    • Don’t hide to build perfect docs
  • Have small complete sections to team to get feedback and learn from it

 

dy26

— You don’t have to start from scratch
  • You can use CODA framework and few other resources to demo how people approached playbook
    • This needs to be actionable and match org needs and mental models
  • Inspiration, not a panacea

 

dy27

— Then test to make sure the solution meets process and mental models

 

dy28

— Have a pilot to refer people to documentation and ask about unanswered questions

 

— Have specific usability testing to complete with the playbook and one team
  • Observe team members and make adjustments based on pain points
  • Note: It’s a ton of fun to make these adjustments

dy29

— Finally encourage adoption through circulation

 

dy30

— 1. Share org channels, and refer folks to playbook when posssible

 

— 2. Set usage goal and track adoption (and learn why usage goal not being meant– no specific recommendation there, but important to measure)

 

— 3. Include documentation playbook in onboarding and training for accurate information and trainings

 

dy31

— You can then expand and document more things, and revisit what is the most valuable option
  • Playbooks are not static, and need to be continuously refreshed
  • Schedule reviews for outdated content
— Do quarterly reviews to keep content current

 

dy32

—  A well designed playbook can clarify and define design practices with procedures

 

— Focus on
  1. Actionable info
  2. Support documentation to be easy to understand and navigate
  3. Focus important info and cut fluff
  4. Review doc on regular cadence and add new things as adopted

 

dy33

— Success
  1. Empathize: How team is gettin info
  2. Prioritize: Start with biggest pain points and biggest impact
  3. Prototype (Imperfectly): Small but complete section, will delvier value sooner, and use templates
  4. Test: Test doc to meet processe s and mental model
  5. Circulate: Share completed page to meet adoption as much as possible

 

dy34

— Thank you, here’s info on sources I cited, and where to find me

 

FAQ
  1. How to convert PDF playbooks for digital format?
    1. Don’t necessarily have to ask, why teams are using PDF or InDesign format
  1. Advice to balance documentation with fast updates from tools that require updates to function?
    1. Ask yourself, are you creating a help document for the  specific tool, or playbook for the org?
      1. Tool probably has it’s own help documentation
      2. Rely on stuff actual experts built out
  1. Do you think should review Confluence regulary to make sure content updated? Should DesignOps be sole owner of  Confluence space?
    1. I like how product teams own their spaces within Confluences
    2. Once a month feels pretty frequent to me. Cadence may make sense but ask what specifically you document and how often you update
  1. How to track adoption? Any suggestions you have?
    1. Whatever tool you use, it should track usage and views
      1. Use whatever metrics are in the tool
    2. Sneaky way is having people ask questions, and see if other non-doc team members link to the metric reference material
      1. This runs the risk of vanity metrics, so be wary
  1. The Coda tool has metrics? What are they?
    1. See number of visitors and sessions, pages used most frequently
      1. Also seeing which videos were wached most often
    2. Basic adoption metrics, but stuff that could be helpful to start
  1. How can adoption be shared collaboration and ownership for playbook?
    1. Can totally be that, and can say individual contributors interested in DesignOps
    2. At least 2-3 UX designers on my team who wrote up  documentation process themselves
      1. Shared ownership to reference more often
      2. Documentation is not only group of people who care about process