User guidelines in the DoD?

As long as the Scrum Team has the knowledge, skills, and abilities to do so, I've found that ensuring that the appropriate documentation is up-to-date makes sense for the Definition of Done. However, when the team doesn't have the necessary skills within the team, then it doesn't make a lot of sense since there's now a dependency in order to meet the criteria for considering work to be done.

Since the Increment is expected to be usable each Sprint, if the users are having trouble understanding what has changed or how to use those changes, then taking some steps to ensure they can effectively use the Increment would be something the team should take on. There may be many ways to achieve that, though - it may be necessary to have conversations between the team and the stakeholders to understand the best course of action.

I am reflecting upon if adding the creation/updating of a user guideline in the DoD could be a step in the right direction. 
What do you think about this?

It could be a step towards having increments that are truly usable each Sprint.

What do the Developers think of this proposal? They are accountable for meeting the Definition of Done and creating increments of work that are of truly usable quality.

What else do they believe should be included in the DoD, but isn't right now?

My first reaction was that if the users are having a hard time understanding how to use the new functionality it is obvious they were not included in the decisions on what to build.  Who is actually making the decisions on what is needed and how are those decisions being made?  In the Scrum framework, this is the responsibility of the Product Owner.  They use their relationship with the stakeholders to determine the needed product changes.  They involve the stakeholders in discussions and they include the stakeholders in the Sprint Review in order to get feedback. 

Yes, documentation intended for the users should be updated if the product is changed. Especially if that is the only communication that is provided from the Scrum Team to the users.  But you can make a huge difference in this by using good User Experience practices.  In many of the companies that I have worked, the User Experience teams are actually extensions of the Product Owner role.  They provide details for the development that are gathered by doing UX focus groups with the end users.  

Your team may be consistent in delivering new functionality to the end users but it doesn't seem like they are doing a great job of adding value if the uses can't understand how to use the new functionality.