As a side note, I think there are fundamental limitations to "solve entire problem in mind" - tooling, including written word, pens, pencils, crayons, paper, documents, diagrams, whiteboards, provide methods for expanding your working memory.
One other thing "just enough information" is a phrase that worries me. I've seen a lot of academically written papers that basically "by implications you should know that the resulting answer is X". I'm not sure this is your style or not, but it is one style that personally I believe has no place in the workplace. Convey your ideas clearly, and help your coworkers.
With regard to your other two points I either wasn't clear or you took my comments too literally. Be that as it may, let me clarify.
I do form my entire impression of the problem and various solutions entirely in my mind, without the aid of external memory. However, and this is important, that evolves out of research. During research I build something like an intuitive understanding of the problem. Along the way I consider possible solutions to the evolving problem, solutions by others or that happen to occur to me. Eventually, usually at night when it's quiet, I have an insight, which often turns out to not be quite right. Rinse and repeat until I have something that seems good. At which point I will sketch out some data structures (as struct or object like things, or simple diagrams) and some pseudo code to operate over the data. If that finds a flaw in my idea I go back for more rinse and repeat cycles.
When I say "just enough information" I mean just enough for any engineer with sufficient experience and background to fully understand the problem and solution. I don't leave anything out, I want feedback and I don't want the feedback to be "huh?". By "sufficient experience and background" I am leaving open the possibility that there might be someone in the group who doesn't quite get it, but to tell the truth most good solutions to most problems turn out to be reasonably simple, simplicity is one of my target criteria. Simple solutions are easier to implement, less likely to have bugs, and if the solution is both simple and good the performance is likely to be at least acceptable as well.
Better? :)
About diagrams.
I had the whiteboard experience once and will avoid repeating it.
When I get a problem I want to sit back and think about it. The interviewers kept insisting that I draw diagrams, and that interrupted my thought process, they were not impressed.
However that does not mean I am incapable of making diagrams once I've sorted the problem out in my mind. After I've arrived at a proposed problem solution I like to produce a written document with just enough information to convey the problem and the solution approach, together with whatever diagrams, data structures, and pseudocode are required to communicate.
That's how I roll. ymmv :)