How to have an approach within LLD

Hey Developers, I know you have a very passionate interest for building something up, to create the new system, but let's take a pause.
Also have such a framework below, this indeed might not be the best framework known, but this works great for me and keeps me productive often.
(Caution: this might seem boring to some 😴💤). Well this can be showing within few steps, I'll keep this simple as A, B, C's

1. Understanding the requirements (Actor)

While approaching an LLD (Low Level Design) you need to wait for a moment, understand the situation and think for a while what are the requirement asked over here. The best way is to get the Actors who are interacting with the system. You can jot that down, or the best could make use of a use-case diagram, as mentioned it would give you an idea about what use cases you might be facing and the mist ahead would get clear while implementing the logic.

If you are within an interview, the interviewer might intensionally not disclose this step, wanting you to ask him what are the requirement's. This is debatable topic that whether this is a good or bad to do so with the candidate's, but I personally feel's it gives a space to the candidate as well in what order he/she needs to proceed further.

Tip for candidate: You can explicitly showcase your skill's within this manner.
Let suppose you are asked to design instant messaging app WhatsApp, you can ask if you are a database expert then, you could say so WhatsApp a ton's of data need's to be handled which has a quiet relationship do you want me to develop the database, and it's interaction's? Or you are into networking and request handling you might twist it and say load's of folks transfer messages now and then do you want me to design a communication mode, medium?

2. Identify State and Behaviours required.

State and Behaviour are the core components about the system, while entering within this step you have taken the first step within your system and started to identify state and behaviour upon the action(s) which we earlier identified.

On a high level State is the variables you usually have within a class or the data entries within the database, it could also represent the state of being within which the system is or would be, which indicates what is the system undergoing, for example: if the routing network is flooded with loads of request which are waiting to serve we could say that it is in congestion state.
Similarly, Behaviour is the things you do with the state it can broadly be classified as the method or functions when choosing the programming analogy.

For example, in an equity broking firm

State would be: numberOfShares
And Behaviour would be: sellSecurity(sellingQuantity);

It is important to capture such kind of details as these posses an essential insight within the code, acting as a blueprint what kind of code you would be cooking. Keeping the data of such details is important and could be done with help of Class Diagram.

3. Defining Complex behaviours

This is an optional step for such systems which has few complexities present out of the box, or associated with it, may or may not be as a part of your solution. Sometimes this step is not even necessary, and may not be considered. Having said that, it is still better practice to take this case into consideration only till the fact that you don't complicate (or overcomplicate) your solution for fitting into this. To trace such complex behaviours we need to have yet another UML diagram known as Activity diagram, which would show the insights, (or sequence diagram if we are dealing with the critical bits as latency and multiple systems).

Post identifying it may be possible you need to change few of the behaviours or state of your design, do not hesitate to do so, acknowledge that due to such behaviours it is better to modify certain bit of the code. You may go back to step 2 and re-run through it, and come to step 3 next to it.

Start to code </>

When you have all the complex patterns modelled out, you can now start to code.

Within code, you now take help from all the three A, B, C's, but mostly you are helped a lot by the Class diagram as it directly indicates the blueprint of the code itself, and you would notice that if you follow this process you will code:

1. Much better
2. Much faster
3. Much cleaner

This is because you have planned your way through and came forth.