Your question is quite representative of the kind of the initial challenges organizations go through trying to decide how to model and organize their kanban boards.
The best way to think about this is to see what the teams do. In general, a team works on multiple types of work (new feature development through user stories, issues and defect fixes, other maintenance requests, documentation, etc.) and might support more than one "service" - multiple products or applications, customers, business functions, etc.
You have the following to consider -
Each team needs to be able to visualize and manage their own work easily - so they can plan their own WIP Limits, replenishment cycles of new work, resolving bottlenecks, etc. easily. For this reason, it is better to have a dedicated kanban board for each team OR at least their own dedicated swim lanes where they can manage the different types of work they do, using different colored cards.
If external customers are involved, you might have the need for confidentiality and access control. People from other teams may not access data that pertains to other customers. In such a scenario, depending on the Kanban tool you use, you might HAVE to separate such customer-driven work in separate boards, and only the team assigned to that board has access to the work in it.
Dependencies across teams. This is a big factor in complex product/ application environments. Different teams might work on different components of a single product or multiple related products on a single platform or platform vs. front-end, etc. Each of these scenarios will result in dependencies between teams where at a minimum, you must be able to visualize the dependencies, and ideally, even have the kanban tool make it easy to determine if some work can be started or not, depending on the completion of work being done by another team.
In my experience, working with several organizations, even teams of 10-12 people (not very big) prefer to have their own boards with multiple swim lanes that allow visualizing the different types of work they do, with specific workflows for each lane. Here is an example -
It is possible to have a scenario where each team has its own board, and their work (such as user stories and defects) can be linked to higher-level epics (or grouped in a release/ sprint scope) which are managed in a higher level portfolio or program board. Here is an example of such a hierarchy - where each level of cards is on a different board -
It is also possible to show dependency links between cards that are on different boards, depending on the tool you use.
As Daniel said, there's no right or wrong answer. However, you need to give thought to what are the key "services" that your teams are performing. These services are business-relevant/ critical - and measuring and improving their lead time/ cycle time performance, their throughput and managing their capacity vs. the demand they face - these are all the aspects that kanban helps you with. So, ideally, your kanban boards, swim lanes within boards, the workflows and card types should reflect organizational priorities, and help you manage the performance of these services - and make their services levels more predictable and reliable.
This will also help them generate their own performance data in a manner that they can use to set more reliable forecasts of what they can deliver per sprint/ release or month/ quarter.
Your board organization needs to be able to support this. You have already made a start. Of course, it should be possible to make changes as you experiment with these designs. A great way for each team to analyze their work and design their boards is known as STATIK (Systems Thinking Approach to Implementing Kanban) - you can read up more about this here. Also, we provide a handy guide on things to consider while designing your Kanban board that you may find useful.
Hope this helps!
