This is a good question. I've been wandering if there is a better way to document interactions for over a year now and have been trialling a few different things. I've taken inspiration from a lot of different places and below are the different types of methods I've created/trialled in the past with some success. The images below show interaction with an image gallery for a retail tablet app.
Abstract diagrams

The grey panels represent a state (not differentiating between a page reload and asynchronous loading.) Only the elements that are involved in this interaction are illustrated and each interaction is depicted with a symbol to explain what input is used or in this case, gesture.
State Diagrams
Another attempt was using some inspiration from state diagrams.

I like this method because it's more methodical so quicker to create, but the downside is it takes more time to digest. I'm yet to try it with more elements, at the moment it only concentrates on the interaction with one element.
From this I've now been wondering if it's possible to draw some inspiration from how acceptance criteria is written within an agile team. Using the same example as the image zoom it would look a little like:
GIVEN, WHEN, THEN
Scenario 1: Opening image gallery
GIVEN that product page is open
WHEN user taps on product image
THEN resize image to viewport
AND show thumbnails and close button
Scenario 2: Swiping between images
GIVEN that the image gallery is open
AND zoomed out
WHEN the user swipes left or right
THEN the next image slide into the viewport
AND the selected thumbnail will update to the image in view
Scenario 3: Zooming in and out of an image
GIVEN that the image gallery is open
AND zoomed out
WHEN the user double taps on an image
OR pinches out
THEN the image zooms in
AND the thumbnails disappear
WHEN the user pinches in
THEN the image zooms out
AND the thumbnails reappear
I find writing like this easier to read and write but you do have to create a lot of scenarios to cover all the interactions and you soon start repeating yourself.
Either way I don't think any of these methods are substitutes for talking with people in your team and accompanying prototypes or videos of certain interactions.