TL;DR
There's no right or wrong answer here in terms of what activities, columns, and swimlanes belong on a given Kanban. However, it's likely that your process is being driven by a software tool choice rather than reflecting the actual workflows and working agreements in your process.
You should carefully evaluate whether you have captured the right abstractions for your process. You should also ensure your Kanban queues effectively track flow and continuous improvement for each team rather than work done by other teams.
Analysis & Recommendations
Kanban is based on queues and flows, but it is based on your queues and flows. It is arguably inefficient to have pre- and post-queues or multiple state transitions for each activity, so many experienced practitioners omit them when they don't add measurable value.
In addition, many Kanban practitioners today are doing so within a more agile context. Kanban-the-framework (as opposed to various Kanban practices, artifacts, and methodologies that are more widely adopted) is often more aligned with Lean Manufacturing than with small-team agile frameworks such as Scrum. As a result, the columns of a single board are generally aligned with activities directly performed by the team, rather than holding all possible states extrinsic to the team's internal flow.
If your team handles UAT, staging, and production deployments directly, then you should certainly reflect those flows in your Kanban. However, if those activities are externalities handled by others, then the work should be moved to the appropriate Kanban (e.g. not yours) when the team is done with it. In such cases, it's often more appropriate to mark the work as "done" by the team, and then get fed back smaller items such as next-stage deployment tasks (perhaps handled by a separate swimlane with its own WIP limit) rather than continue to track work that is performed outside the flow represented by the team's Kanban.
With Kanban, one size definitely doesn't fit all. Without knowing why you've chosen the level of abstraction that you have for your workflows, and understanding all the metrics that you're tracking to determine whether or not that abstraction is useful to you, then it makes no sense to compare your abstractions to someone else's.
All models are wrong; it's just that some are useful. What you need to ask yourself is whether your model is useful. If not, focusing on diseconomies between processes (rather than treating all activities as internal, especially when they aren't) is a good use of your team's inspect-and-adapt loop.
