All the task types you mention can basically be grouped into feature and bug.
Features are planned and (unless very small) usually take the shape of a user story. Documentation and testing are definitely part of the corresponding feature, and so are research and refactoring if they are the precondition to starting the implementation.
Bugs, on the other hand, crop up unexpectedly and cannot be scheduled, so I wouldn't try to force them into the backlog. However, you should take your current bug load into account when estimating how much time you'll have available at the beginning of a sprint.
Dealing with technical debt falls somewhere between these two lines. By this I mean things that are not strictly implementable features themselves but still need to be dealt with at some point: refactoring, tech upgrades, low-prio bugs, additional tests, documentation updates, but also independent research such as tool evaluation.
All of these can be planned and thus should be treated as tasks that, in turn, can be bundled in a story wherever it makes sense. (For example, you could create a story to add tests for big feature BF, then add one task per class involved in BF that's still missing tests.)
Rules of thumb:
- A story can be finished in a single Sprint.
- A task can be handled by a single person in a reasonably short time frame (around 1-3 days).
- If a task can be easily split and worked on independently (or even consecutively) by different people, it's still too large.
If a feature is expanded on after its initial completion, you can simply create a new story for the second iteration of said feature.
UX is a good example where you'll pretty much always need a second (or even third) iteration to incorporate feedback. Since you know this in advance, you could already take that into account when creating your backlog: Instead of creating a single story and expecting to be done with it at the end of the sprint, you could already prepare a second (presumably smaller) story for the inevitable polishing, bug fixes etc. Worst case, you won't end up needing one of the iterations and can delete them from the backlog.