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.
