"Good judgement comes from experience, and experience comes from bad judgement."
I have noticed in the past that when designers ( and scientists ) get older, they start writing and talking about "meta" issues, rather than about hardcore technical designs and scientific theories that people expect them to solve. So when I noticed that the feedback I gave to students became more and more on the methods to achieve something than on the somethings they wanted to learn about, I knew I was getting old.
The meta level is where 80% of the result ( cost, quality, performance ) is determined, in 5% of the time that a project, product or service takes to develop. This is also known as the the 80-20 rule, but in design I think the ratio is more like 80 to 5.
It is very difficult to teach people how to go about the design process. It is easy enough to draw up nice flowcharts on a whiteboard, and point out the processes of fanning out, funneling, top-down or iterative development, plan-do-check-act cycles, and what have you.
It is important to be aware of such patterns and to lean back every now and then to consider if you are stuck in a rut, sub-optimizing, forgot to zoom out to a higher level of requirements, etcetera.
Zooming in and out occasionally is the best habit I know of to avoid driving too far into a dead end. Another trick is to occasionally ask yourself which part is doing what task, and briefly consider splitting a part if it has two functions, or combining two parts into one if the new part can perform two functions without extra effort.
There exist rather contrived, formal methods
like TRIZ to see
if a function which is now electrical can be done
mechanically, active versus passive,
rotation versus push-pull,
cause versus effect, etcetera. These methods
try to mechanize the supposedly "creative" process.
In my experience such methods are more suitable
to classify
Any effort spent on a complex framework is effort lost on the real design process, which is thoroughly iterative and conversational, and is not likely to stay within the clean, mutually exclusive boxes of a classification table.
The only way to learn design is by working with a real designer who is willing to share the art.
The professional way of organizing a design project is to set up a planning, and appoint a project manager ( not the technical design leader, but a separate member of staff ) to monitor progress, typically on a weekly scale. But as a rule it does not help much to set up a supposedly "first time right" scheme and start ticking the boxes.
A "tiger team" version of this is to use the SCRUM philosophy, where the team members converge in daily and weekly "stand-up" meetings, designed to be brief and effective ( no one wants to stand in a circle for long ). The good side is that at the meetings, new goals are set for the next two weeks, which gives frequent opportunities to "pivot", i.e. to adapt the design to growing insights.
This can work for website development, where functionality is relatively easy to break down in two-week "sprints" with a clear and testable result. However, it is just not applicable to large, integrated design problems.
Invariably, at the start of the design you will be asked to give an estimate of the time that the project will take to complete. The classical method, which has been found to work time and again, is to make your best estimate and multiply by pi ( π ≅ 3.14 ). Your estimate has to be honest. And then you have to add the extra factor.
An extension to the rule which I picked up in the space industry is : if more than one country is involved, then multiply by π 2, i.e. by a factor of 10. Trust me. It is a good rule.
A very useful variant of this last rule is : you make your best estimate, and then you multiply by the number of people in the room.
The biggest danger to the schedule is not lack of planning. It is lack of action. "Analysis paralysis" is very seductive. Think. But don't overthink. Make frequent small steps, with actual working prototypes for every design idea or design step. Do not try to take two steps at once, because the next prototype will become too nice, and take four times as long.
For "real" design problems, my money is not on project management or SCRUM, but on the Toyota way. This is built on a team dedicated to quality, led by a single, incredibly experienced design leader.
The team gives its inputs to the design leader in a strict format, with a solid motivation, or else they will be out of the game. The design leader is not afraid to pivot, even at a late stage in the design, if it is clear that someone found an alternative solution which will lead to a quicker or otherwise superior result.
The best book on this methodology is "The
Toyota Product Development System",
by Morgan and Liker.
Apart from being very instructive,
the book is also unintentionally comical,
because the authors are Americans.
They faithfully describe
the Toyota way, like an eight year old
would recount an erotic movie. All the
facts are there, but the story can only
be understood by an adult.