I did see a lot of nice and informative questions, articles on inter-net and on StackOverflow itself, of-course. But I found all the questions or articles following a specific rule or a pattern to explain the topic. I mean, when a question was asked on NFA, DFA or Regular Expression, a solution was presented to the question abiding by the theorems / rules of these topics (Theory of Computation).But what I feel is that, as most of the questions on DFA/NFA are of the type Design an NFA.... or design a DFA... , I feel that developing/Designing DFA/NFA must be an ART. And where there is ART I feel there is an intuition. If these problems involve DESIGNING something ,then everyone must have their own way (of-course not going out-of-the-way of theorems or rules as such) of solving or attacking these problems. One should have developed a thinking process (over the years of practise) to solve these problems.So I would like all the experts over this Site to share their knowledge (preferably in simple words) how they think over the problems (simple ones) of these topics.I would like to elaborate the question with a simple example.Let F be the language of all strings over {0,1} that do not contain a pair of 1s that  are separated by an odd number of symbols. Give the state diagram of a DFA with  five states that recognizes F . Or maybe this:Design an NFA to find a 4-state NFA for the complement of F.These questions are from the Sipser's book and I have also found the solutions for them myself. I just want to know , how one can develop an intuition for solving the problems?
How to approach NFA design questions intuitively?
regular languages;finite automata;education
There is one sentence in your question that is worth answering:I just want to know , how one can develop an intuition for solving the problems?Same thing everybody does, be is musicians, crafts men or scientists: exercise. There is no shortcut.You can certainly use the growing database of finite-automata questions we have here. There is little use in repeating techniques here as they more often than not depend on the concrete example.For regular languages in particular, you can devise any formal representation of the language as long as the model is equivalent to regular languages. There typically are (computable) methods to transform such representations (e.g. regular expression) to finite automata.