How to handle other tasks than regular coding

There's nothing that says that the work must be coding. Within the Scrum framework, I see two places where work is done.

One place where work is done is Product Backlog refinement. Refinement, according to the Scrum Guide, "is the act of breaking down and further defining Product Backlog items into smaller more precise items". In my experience, some level of architectural and design activities are helpful to understand what those "smaller more precise items" are. Understanding the desired user experience can also help the team understand what is necessary. Finally, if you're following test-driven development (or acceptance test-driven development) practices, you may start to write test cases from the description of the work, so this could conceivably be done as part of refinement.

The rest of the work is done within the context of a Sprint and delivering the work. Even after refinement and any design that is part of that activity, more detailed design will likely need to be done as part of implementing. The team's Definition of Done should also be inclusive of ensuring that the work, after it is integrated, is usable by stakeholders. This would include testing, documentation, and other activities that may be required by the customers, users, or the context in which the system is developed and used.

You're understanding is correct, testers and UX designers are considered to have Developer accountability in Scrum. Developer accountability does not strictly mean software developer or computer programmer.

If your Scrum Team needs UX design work, testing, and documentation before the Product Backlog items are considered 'done' (in other words useful, valuable, potentially releasable), and can't complete that work in a Sprint and have to do that outside of a Sprint, they are missing what Scrum is all about.

All other types of tasks are considered as something which must be handled outside the sprint. 

There are no gaps between Sprints, so all work must be happening in a Sprint somewhere. This includes refining work so it is ready for future Sprints, and the design, testing, and documentation needed to craft a Done Increment this Sprint.

Anyone whose industry is needed to create a Done Increment of usable quality is one of the Developers on the Scrum Team, whether they be a programmer, designer, tester, or a technical writer.

Thank you for your comments.

This is more aligned with how I understand scrum.

A follow up to my intial question. 

On our team we often have "design" PBIs that only have a specific design as it's output. We will then have the implementation of that design as another PBI in a later sprint (usually the next).

I see that you could argue that the design PBI is refinement and should be done outside the sprint, but could you also argue that the design itself puts value to the business so it's a valid PBI?

Our developers do all the work related to design and implementation, so it's not a question of different resources doing the refinement.

Would splitting design and implementation (coding) in different PBIs and sprints conflict with the Scrum methodology?

If it takes longer than one month to frame and perform an empirical experiment, then the validated learning loop has become attenuated. You're doing something else, and the outcomes which might be obtained from the Scrum framework can no longer be expected.

Would splitting design and implementation (coding) in different PBIs and sprints conflict with the Scrum methodology?

Yes, because when the design PBI is done, no value which can be used by a customer has been created. Out of that, the design is as important the implementation, tests, documentation,... for the value creation. 

No, because Scrum does not mention how to organize the work. The question is, why do you want to split the design from value creation. Is it for reporting what the team is doing/for collecting ideas/...? 

On our team we often have "design" PBIs that only have a specific design as it's output. We will then have the implementation of that design as another PBI in a later sprint (usually the next).

I see that you could argue that the design PBI is refinement and should be done outside the sprint, but could you also argue that the design itself puts value to the business so it's a valid PBI?

Our developers do all the work related to design and implementation, so it's not a question of different resources doing the refinement.

Would splitting design and implementation (coding) in different PBIs and sprints conflict with the Scrum methodology?

Yes, splitting design and implementation into different Product Backlog Items is inconsistent with Scrum. A Product Backlog Item that only results in design often doesn't add value to stakeholders - that is, they cannot use your design to help them with whatever problem your product is designed to help them with. The analysis and design activities are only directly useful to the people doing the work, not to the people receiving and using the product.

It's not a clear split in a way that you can say that all design is part of refinement and all implementation is not. There's a fuzzy line that's very context sensitive.

Refinement is about breaking down Product Backlog Items into smaller, more precise, more detailed items. The result of refinement is a Product Backlog Item that is ready for a Sprint. The minimum criteria for a Product Backlog Item to be ready is that it can be done within a Sprint, but the team may add other criteria or expectations. In my experience, what the team considers necessary is related to the risk tolerance of the organization and stakeholders. When the risk tolerance is low, the team needs to spend more time in refinement activities to reduce the chances of other work emerging. However, when the risk tolerance is high, then the team may be able to tolerate unexpected work emerging and the likelihood of not being able to complete Product Backlog Items or missing their Sprint Goal.

Would splitting design and implementation (coding) in different PBIs and sprints conflict with the Scrum methodology?

This would go against Scrum if you do only the design PBI in your first sprint (and nothing else). As per Scrum, design/architecture should emerge along with a valuable increment. But I have come across some cases where this happens like in a Sprint there is no work for the UI designer and hence to keep him occupied some design related PBI is picked up and worked up (splitting design and implementation from an item in the product backlog). This is fine if you have other PBI's which deliver value in the current sprint. Infact UI mockups can be shown in the sprint review to get early feedback. In the next sprint your design PBI (from older sprint) and the corresponding implementation PBI would together produce value.

Just my thought :). I would like to hear from others too on this.

I agree with the folks above.  Typically design is either done as part of refinement or at the time of the solution being built.  But I will add one small caveat. 

I have had teams use what they called "Spikes".  These were research/experimental efforts to gain more insight into the problem that they were trying to solve.  They were typically created when during refinement discussions, the team still had some answers around the problem and whether it could be solved.  So they would create a "Spike" in the Sprint Backlog, add a timebox limit on how much they could send working on it (i.e. 4 hours), and then do that work as part of the Sprint.  We used these sparingly but the team found them useful for being able to focus.  By putting them in the Sprint Backlog, it was transparent to anyone that they were directing some time away from the Sprint Goal for a specific purpose. 

I am not sure if your design PBIs are like our Spikes but wanted to add this little wrinkle to the conversation.