Ambiguous Constraints

I saw this tweet yesterday and it has been in my head ever since.

This is a major problem I see in both new and mid-level designers. In new designers, I understand how ambiguous constraints and ambiguous goals could be problematic for them as they don’t have the experience to break a problem down or, more difficult, begin to see what the real problem is.

Mid-level designers that have this problem disappoint me. If you’ve done this for more than three projects, you know that nothing in constraints or requirements is unambiguous. In fact, that is where a good designer is separated from a mediocre one.

I have a few thoughts on why this happens. The most obvious reason is due to that designer’s training. Boot-camp style and for-profit groups like General Assembly teach a very specific form of design. They templatize solutions and teach those solutions to their students. More than likely, students in these learning environments don’t get enough “messy” design problems to work through and see ambiguity, nor do they get a lot of experience in looking at case studies that might inspire. Instead, they look for a defined list of problems and anything outside of that or any talk of those constraints not being accurate is not discussed.

Good designers are trained not only on tools and techniques but also the history and theory of their specialty. Without turning into an ad for my day job, good designers come from training that takes time and is holistic in both tools and theory. It’s only when designers can sift through ambiguous constraints, ask questions, understand their users, iterate through solutions, and execute those findings does success follow.