As developers, we naturally think only of the requirements, and not of how things will work in practice once the automation is in production. Once in production, chances are that you will encounter scenarios that were not considered when the requirements were written, primarily because requirements usually only consider what needs to be accomplished and they do not always take into account what might or could happen once in production. I personally have a lot of business experience in addition to my experience as a developer. As a result, I try to develop my automations in a way that anticipates scenarios that are not contained in the requirements. An example of this is the example I gave of having my Populate Queues process always be in a separate process, and my Write Report process always to be separate too. This is not to say that those tasks cannot be accomplished using a single process, but real-world experience tells me that there will often be times when an issue arises that is best resolved by having things separated.
So, how to decide what gets its own process. I've already mentioned Populate Queues and Write Report. I always separate them. Other things that should be separated will depend on the requirememts of the automation, so it is difficult to say what you should do. As a rule, I separate processes that can logically be separated based on the system(s) they will interact with, the need to pass data between the processes, and the timing of how the steps need to be run. For example, if you want to separate two processes, and the 2nd process needs to consume data from the 1st process, they can be separate if the 1st process is set up to store its data back to the work queue and the 2nd processes gets its data from the work queue. Those processes can be separated. Or, if a process interacts with separate applications (like Excel and Word for example), then it might make sense to separate them into 2 processes. If your automation will interact with the 2 applications multiple times during the process, however, then it might make better sense to keep them together. I could offer many examples, but the discussion would go on for hours. Just think about what you need to accomplish, the applications you will use, and the timing of how things need to fit together and eventually you will get it.
How to separate pages in a Process. A process represents a start-to-finish task. During the course of this overall task, you will find that there are some things that are done multiple times. For example, let's say that your task must do some processing, and then it will post an entry to some system, like an accounting ledger or a sales system. The steps for posting that entry should be on a separate page, and that page should be referenced in the process when it is time to do that task. This allows the posting task to be reused, and makes maintaining it easier in the future. You pass data between the pages using inputs and outputs. Hopefully, this example gives you and idea of the concept.
In an Object, each page should represent an interaction with an application. So, if you have to log in to that application, you will have a login page. If you have to then go to a Main Menu, you would have a page called something like "Navigate Main Menu" and that page will contain the steps for going to the Main Menu. If you then have to select an item from the Main Menu (like, say, Create an Order), then you would have a page that contains the steps for selecting Create an Order from the Main Menu. Maybe you will have another page for the steps needed to Enter an Order. Each page in the Object should contain the steps for interacting with the application screen in some way, and nothing else. Each of these pages is called an Action. Then, as an example, in your Process when you need to login to the application, you use the Login action and when you need to Create an Order you use that action. I hope this example helps you get the concept.
I apologize for the lengthy post, but it is difficult to describe a concept without first setting up a scenaro and then giving guidance.
I hope this helps.