Shared resource

My advice is to recognize that this individual is not a "resource" but a person, as are other team members, and that two teams of empowered professionals will have the creativity and agency to self-manage without oversight.

Ian Mitchell's answer is a good start, but the next step is to understand why this person is shared between two teams. Understanding why can help narrow down options for reducing that dependency.

Thank you Ian Mitchell

Hi Thomas Owens, An UI/UX designer just left from the team due to some urgency personal reason.  In another team there is an UI/UX designer & more than 50% of his capacity is available.  Both the projects completing in another 6 sprints (3 months).  So, team decided to share this person between two teams.

Two Scrum teams sharing one person can be challenging for both teams and the person having to balance two efforts, as suggested. This situation is common especially amongst UX people as it is often a scarce skill. As Scrum Masters, we have an old saying "take it to the team". As Ian suggests, could the Scrum Master facilitate a conversation with both teams and allow them to solve the problem?

Scrum Masters should refrain from solving the situation directly, so when I mention facilitating I am implying staying neutral yet making the space for others to solve it. A Scrum Master might use open-ended questions to stimulate thought. People closest to the situation and context will be the most invested in solving it, and more apt to own a solution they come up with rather than a Scrum Master giving a solution to the teams.

In the case of a UX designer, I'd be interested to know how many products the teams are supporting.

If there is a single product, there should also be one Product Owner. Although it's contrary to other guidance, I prefer to align UX designers with Product Owners rather than Developers. This is especially true since products often need a unified user experience and performing user experience research, visual design, interaction design, AB testing, and creating/maintaining component libraries usually occurs at a product level and crosses team boundaries.

If there are multiple products, then it may be OK for a specialist like a UX designer to support multiple teams. However, it becomes more important to understand what level of involvement the specialist will have with each team. It's up to the teams to figure out how to share this person. However, training others in some aspects of UX design to alleviate the pressure is always a good idea. The other people may not become UX designers, but they can become more independent when performing certain aspects of the work, perhaps allowing the UX designer to focus on review rather than hands-on action.