The article does touch on points that help make a better design but doesn't link to the deeper meaning behind it.
Design is, in effect, planning. A good design is a good plan to achieve a goal. A good web design is a good blueprint for a website.
This is similar to code design. Ask yourself some of these questions:
- which is easier to read, a pyramid of if statements hacked together or a well factored design where indentation isn't excessive and modules do one thing well?
In visual design, this would be your grid system, consistent and readable typography and well thought placement of modules. Code smells bad when you've got no consistent styling in a 1000 line procedure - the rules that lead to good design are very similar.
- which will lead to a better end result? A problem explored on paper, with ideas bounced off the client and colleagues or something thrown together in 10 mins in code?
Getting your requirements down is just as important in design. From there, wireframes with client and colleague feedback is equivalent to a design document of some sorts (even if it's one page a la one feature in iterative development). Based on wireframes and requirements, a mock-up follows with more client feedback. Again, you can't produce good software without a clear idea of what's being built and so it is with design.
If designing for one's self, you are the client. In that case, get someone who will give you quality feedback at each step too.
The best way to look at design and "make things look nice" if you are a programmer is to learn the fundamentals of design and look for parallels in programming.
Certainly, there are exploratory designs too. These designs, like equivalent programs, are useful to find a good solution to a tricky problem. In that sense, these wouldn't be complete designs but ideas for a component you can use in a complete design.
Apologies in advance for rambling - I'm starting off 2017 with the flu!