There is no fixed order. It is all based on what you think is most useful to you/your team.
Initially, there should be some collection of requirements. If you start with SW architecture once someone tells you to do a software for X, then you already missed the most important step there.
During the requirements engineering phase, not all UML diagrams make sense yet. But some do make a lot of sense, in particular use-case diagrams. I have often seen use-case diagrams as the basis for discussions from which the requirements are then determined.
Similarly, state machines are already popular on the requirements level as well.
Once you have a set of requirements and actually start thinking about your architecture and later the design, more and more diagrams will start to make sense. Obviously, the class diagram comes in handy on lower levels of detail, but others, like sequence diagrams, may also make sense if you have complex sequences in your architecture.
Are you developing a distributed system, or something where components have to communicate a lot with each other? Try out the communication diagram.
Unless your process somehow requires you to use a specific UML diagram, there is no one forcing you to do so. Always remember that you do not model your software in UML for its own sake. If you don't feel like it'll help you, then simply don't do it.
Obviously, it takes some experience to decide this. I suggest you at least invest time to try out state machine, class, activity, and sequence diagrams, as those are the most popular. If you have enough time, take a look at the others as well.
In a question is something should always (or never) be done, the only reasonable answer is: No, there are always exceptions.
Whether it is a good idea to start with a design in UML depends on the scale of the design, the ramifications if you get it wrong and your own comfort level.
If you do decide to start with an UML design, there are still two ways to use UML:
As a specification language. In this case, the UML diagrams are a direct representation of your code and contain the same level of detail. Often, you can use RAD tooling to generate code from the UML diagrams.
As a communication tool. UML is a powerful tool for communicating designs to others (or your future self), but there are no requirements that the diagrams contain all the minutiae in detail. For effective communication, it is often even better not to show all the details and that includes even stuff like helper classes or relations that are irrelevant to the point you want to make with the diagram.
If you use UML in the second way, then it is very much to be expected that the resulting code only looks like the diagram in broad strokes if you look from a mile away. Closer inspection will show large differences, but that does not necessarily invalidate the diagram.
Best Answer
The first thing you have to do, is to get an overview on the requirements. Two diagrams that may help:
The next thing is that you'll have to do is to detail the behavior. Typically, you'll do this with one diagram for each use case (or BPMN activity), for example using an activity diagram (or sequence diagram). In parallel, you'll also have to identify the business objects (entities) that your application will have to manage with some data modeling diagram (for example, class diagrams, or other diagrams suitable for database modelling, such as an entity-association model).
If your family is in the hotel business, the kind of diagrams that you'll produce with BPMN, will be useful not only for your development activity, but also for other managerial purpose, as the core is not the technical components but the organisation of business activities.