self-organization in to silos

A few things stand out to me.

I don't think the designer should be part of the Development Team. In my experiences as a software engineer, UX/UI designers are a source of requirements for how the application should look and feel through the design system. Other stakeholders may understand the functionality that they want, but studying and finding the most effective ways for users to interact with a system is specialized knowledge. The work of creating user flow diagrams, storyboards, wireframes or prototypes, and sitting down with potential users and evaluating those and coming up with what user interface needs to be implemented is necessary to appropriately estimate work. Of course, the designer may need to work with the Development Team to understand how the system will be developed incrementally and perhaps drive intermediate states of the user experience.

By moving the designer out of the Development Team (but keeping them closely aligned with the Scrum Team), you're now freeing up someone else to work on something else. That something else could be working on further refinement of Product Backlog Items before the Development Team works on them. Or it could be a more general research of the target audience, business goals and objectives, and how to align the design of the interface with the needs of stakeholders to achieve the business goals. The person can still work on the Sprint cadence, but they may have a different set of deliverables to the Product Owner or the business to facilitate user testing, A/B testing, or simply a greater understanding of problems users are experiencing and how to solve that through the product under development.

The balance of work between the other three Development Team members (the front-end dev, back-end dev, and tester) is still a problem.

Consider this section from the Principles Behind the Agile Manifesto:

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

And this section from the Scrum Guide:

People personally commit to achieving the goals of the Scrum Team. The Scrum Team members have courage to do the right thing and work on tough problems. Everyone focuses on the work of the Sprint and the goals of the Scrum Team. The Scrum Team and its stakeholders agree to be open about all the work and the challenges with performing the work. Scrum Team members respect each other to be capable, independent people.

Unlike my experiences in a more command-and-control environment, instead of building bars to set to people to minimally meet, the agile methods encourage people to continually improve and push themselves and the teams to a better place.

Assuming that the members of the Development Team are qualified to do the work (and it sounds like they are), I don't believe that the Product Owner should be reshaping the Product Backlog to meet the needs of the Development Team. But that doesn't mean that the needs of the development team are ignored.

Wearing my Scrum Master hat, the only thing that I can do is coach.

I can coach the Product Owner.

I would make sure that the primary focus is on delivering value to the business and stakeholders when deciding on the order of the Product Backlog. But I'd also advise considering the skills of the people. I'd recommend trying to bring in (preferably something small) for everyone. In the example case with very little front-end work, maybe there are some small (in terms of effort) front end changes that need to be made that can keep the front-end developer working in his comfort zone a little. Maybe there are some stories that need effort put in to better understand them before they can be fully refined and ready for a Sprint that fall into the area of expertise. Prioritizing this work may be good for team morale overall and worth it. The only thing to do is to limit this work and not let it consume this person's time over the Sprint - the work should only be a day or so per week of the Sprint.

I would also coach the Product Owner on how people's strengths affect planning. Just because the front-end developer can do back-end work, the work may get done slower. Depending on the complexity of the work, there may also be risks to product quality. There may be less familiarity with the product, how different portions interact, or the frameworks or tools used that could lead to something being missed. It's incredibly important that the Product Owner understands the strengths and weaknesses of each member of the Development Team and the risks when a person is asked to work outside of their strengths.

I can also coach the Development Team.

Outside of the Scrum framework, I would coach the Development Team about their obligations to different stakeholders. The obligations to one's employer and clients is relatively high. The only thing more important than satisfying the needs of the employer or client is satisfying the needs of the general public. I can teach them how Scrum helps to make this a reality with how Product Backlog Items have an associated value that is one input (along with technical dependencies, estimates, and other factors) to the ordering of the Product Backlog.

I'd also want to better understand why the team doesn't want to better cross-train their skill set. Do they perceive a risk or threat if they were to? Is there some kind of impediment to them cross-training that can be resolved, on a team or organizational level? I'd want the Development Team to cross-train and can make a case from a number of different perspectives on why cross-training will benefit both the individual and the team, but I don't know which approach to take until that is understood.

In the spirit of self-organization, I'd also have an open conversation with the team. Based on the current state of the Product Backlog, the next Sprints will be extremely light on front-end work. I'd bring up the converse, as well - there may be stretches of two or more Sprints that are light on back-end work. I'd go full circle with the team's obligations - how does the team want to ensure that they are delivering things that are important to the stakeholders quickly, efficiently, and with quality. I would hope that previous conversations around obligations and cross-training would set the stage for the team to figure out solutions.

Personally, I find the reluctance to want to cross-train and focus on the highest value work for stakeholders to be against the values of Scrum (and, even more broadly, software engineering) - it goes against the commitment of the Scrum Team to satisfy stakeholders through the delivery of valuable software (to paraphrase one of the principles behind the Agile Manifesto) and having the courage to do the right thing for the stakeholders (including the Development Team).

There's insufficient information about what's going on at the organizational level. If there are multiple Scrum Teams, perhaps the teams should be given the opportunity to reorganize around different products or types of work. Maybe there's something culturally that is limiting the desire to cross-train. But looking at what is happening outside of the Scrum Teams may be interesting.

The Product Owner would prefer more of the highest priority items are done, rather than delivering more items from further down the backlog.

Should the will of the Development Team be respected? What might be a reasonable way to challenge this?

Has the Development Team satisfied the PO that value would be best served by reprioritizing items differently? Can they explain their reasoning, however technical it might be, for why value would be maximized if work were re-ordered?