Ryan Singer in Identifying conflicts in a UI design:

When I’m working on a UI design I look for things that are wrong. I have to do that because ther’s no checklist of things that are “˜right’ that make a perfect product. You can’t check a requirements list and say “Yep, everything’s there!” and conclude that you made a good design. You have to look at the design itself and hunt around for problems: things that cause friction, things that aren’t clear, things that take too long, things that break expectations.

These conflicts are the heart of design. If we could just pile features one on top of the other, we wouldn’t have to do design. Design is what you do when piling elements onto each other doesn’t work. It’s the process of identifying and resolving conflicts.

This is so true. As the debate about unsolicited redesigns rage on (most recently on ignore the code), I often think about the dangers of pointing out the flaws in designs. I try to remind myself that there are most likely missing details and nuances behind design decisions that I don’t know about. As Rebekah Cox says:

Design is a set of decisions about a product. It’s not an interface or an aesthetic, it’s not a brand or a color. Design is the actual decisions.

That said, Ryan’s article reminded me that pointing out what’s wrong with a design (based on objective principles, not feelings) is the most effective way to figure out what’s right. And that process has to start at home. If we’re serious about relentless quality we have to be the biggest critics of our own designs.