"Stupidity" from Wordnet:
- a poor ability to understand or to profit from experienceDesign is the process of taking a set of constraints, and make something out of it. These constraints can be a number of things, from trivial wishes to strict rules. Sometimes it's about a color, other times about functionality, and then again about its basic concept, maybe a marketing angle or perhaps changing some stuck process. It could be anything.
- a stupid mistake
However, a lot of the time you're left with that compelling feeling of "Qua?" while reading through your constraints; he wants me to do what!? They think we should put in that!? She likes what color!? marketing wants to sell this to whom!?
One definition of something stupid is when you can't see what is obvious to others. Sometimes this can have as much to do with your definition of a problem as a personal viewpoint, but quite often this "stupidity" certainly points to things we overlook or just plainly can't see but what we certainly should address.
Good design is about seeing things from as many angles as possible, and find the best possible compromise between them.
"Ignorance" from Wikipedia:
Ignorance is a lack of knowledge, or a willful lack of desire to improve the efficiency, merit, effectiveness or usefulness of one's actions. Ignorance is also a "state of being ignorant" or unaware (not knowing).Building systems (applications, processes, buildings, societies, anything) is a complicated thing, relying as much on the goodness of the designers as the intelligence and skill of the builders.
Some people willfully ignore things. Maybe they feel they know enough, or maybe there are fears involved. Whatever the case, you see it all the time; people walking on a red light, smoking where not allowed, slightly speeding while driving, daydreaming while in meetings, outsourcing for the sake of instant capital gains, eating unhealthy food, not practicing what you preach, ignoring global warming signs, keep investing in oil consumerates, draw red buttons for safe functionality, never test your assertions and so on. The list is endless. People ignore things because of the normally low frequencies of events.
When builders ignore the time effects on setting concrete and make a too thin layer for your foundation, a layer without skeleton, and a few years down the track the building may simply collapse. If you don't fully understand the difference between alcohol and methanol it just might be the difference between life and death. If you ignore warning signs, whole cities might be flooded, or buildings blown up, or kids will use guns on other kids.
Good design is to preempt what warning signals has taught us.
"Incompetence" from Wikipedia:
Incompetence is the condition of a person who is unable to properly perform his assigned duty. Incompetence is the essential ingredient of the Peter Principle, which states that in a hierarchical organization, every employee tends to evolve through promotions towards a position in which he is incompetent.Approving systems tends to happen after it has been built as opposed to something that happens in parallel. That being a flawed strategy from the beginning I guess is hard to overlook, but let's focus more on the common way we approve the systems we design and build.
First, approval is mostly a binary thing, no matter how much history teaches us otherwise. If it still is running and does what it says on the tin, that's considered a success, even if you don't fully understand why it was written on the tin, nor what the tin was supposed to contain or should contain.
Then there's approving things because your job is to approve things instead of guiding things or cancelling crap things. If you and your team spent months on a project you're not going to be self-reflective enough to call yourself out in public.
Good design is to allow for failure.
To shift things around
In order for us to shift things around when they are going pear-shaped (hang on, what's wrong with pear-shaped? I love pears, and I love pear-shaped women, what gives?) we must focus a bit harder on design from the middle principle. I'm a bit tired of both top-down (we know upfront all there is to know) and bottom-up (we know only know so little) approaches. Could we please start somewhere in the middle, and work ourselves out from there? Thanks.