I just want a professional advice on how should I begin my game designing?
Game design is the specification of the gameplay, the assets, the scoring systems, etc - these are not software-specific. As such, UML is the wrong tool for that task.
When it comes to designing the code to implement these systems, UML is a good tool for the task, providing your team know it, and stick to the more common diagram types. Normally, when trying to design a feature, you will know whether you need to use a description or a diagram. If you do need to use a diagram, UML gives you a standard way of drawing it, which is a good thing.
After coding for a while, things start to break down due to poor planning (When I add new feature, it tends to make me have to recode the whole program).
That is generally a problem with the way you program, rather than how you plan. Good software usually is easy to extend and reuse. If you stick to good programming practices, this problem will decrease. But better planning will help also, and you don't need complex diagrams for this. Just having a list of features will mean that when you code one thing, you have the other features in mind and can consider them as you code.
Therefore, any advice to how should I plan my game? How should I put it into visible pictures, so that me and my friends are able to overview the designs?
It sounds like you're mixing 2 problems here, the game design, and the code design.
I suggest first writing out a basic game design, specifying the features you need, the graphics and sounds you need, how the game is won and lost, etc. Look up 'design documents' if you need some help there.
From there, you will have an idea of the features that you need to code up. You can look at each feature in turn and try to think about how to implement them. Diagrams can help to show the relationships between different classes and objects in your game but the skill of knowing which objects need to exist is something that you have to learn through practice and/or further reading.
Also, try working on smaller, less ambitious projects. That will get you used to writing good, working code, without needing extensive planning or rewrites.