Creating good software design is hard. You can read all the books. You can go to all the conferences. You can practice practice practice. But it all comes down to making judgment calls, millions of tiny, tiny judgments that all add up to create the whole design, which becomes so many particular experiences with your software, experiences that you can never fully foresee, kinds of people you never knew, contexts that fall out of the ones you were aware of. Show me a thing that is generally agreed upon as "great design," and I'll show you tons of posts on social media, forums, etc. where people are bashing, complaining, and scratching their heads in confusion. The old maxim really holds true--you can't please everybody, not even a subset of everybodies that fall into your neatly crafted target audiences or personas.
So what are we to do? Well, you just gotta keep trying. You gotta keep learning, keep practicing, keep prototyping, keep testing, keep iterating. Apply those good patterns where they make sense for your design space; keep a tight focus on the users you think you know about, their stories and their contexts. And pay attention to the details.
When faced with design choices, one thing you have to balance is what I'm loosely framing as a spectrum between "usability" and "aesthetics." To define the terms in the illustration above:
- "clever" - by this I mean a design that is unexpected, maybe something that once a user learns and understands it, seems really clever; it solves a problem but is anything but...
- "obvious" - I put this forward for designs that go to some length to be painfully obvious, holding the user's hands, often with clear affordances, reliance on patterns and conventions, and even textual guidance in one form or another
These two are positioned on a sliding scale of usability (how easily and effectively I can do what I want to do, with minimal frustration, confusion, and error), where increasing "cleverness" requires a corresponding decrease in "obviousness."
- "minimal" - as in a form of minimalism--the removal of all elements that aren't strictly necessary, with the typical accompaniment of an interface seeming simpler, cleaner, and thus often perceived as more desirable, as opposed to...
- "bulky" (or "busy") - this would be an interface that can seem at first glance unwieldy, maybe hard to make it look stylish and desirable
These are positioned along the same scale as inversely proportionate to the usability values, because in practice, they often have such tension. (Although aesthetics broadly understood can encompass "usability," just stick with me...) As the capabilities of the software increase, so this tension increases. It's one thing to design a simple sign up or check out form and find a good balance between these relatively easily. But try balancing these for, say, a word processing app, or a system control interface.
It seems to me that these design values do often fight with each other, and the trick is to find the right balance between them. Not all apps need to be dead simple, holding the hand step by step by step, but that doesn't mean you flip a binary switch to the other side either. And even within an app--this or that capability might need the slider moved based on its perceived relevance to the activity at hand, the commonality of need for it, or even how important it is to the business.
Often though (especially at a certain level of detail), the best position on this scale cannot be directly informed by known personas, stories, business cases, design principles, or metrics. It will be a judgment call the designer has to make, and it will have to be informed indirectly by all of these things, but ultimately it is a judgment call, and that is where the rubber meets the road for Design, where Design becomes an art, where talent and skill become more important than knowledge and scientific approaches. It is in all these little judgment calls that the totality of the design is created. It calls for focus and dedication to get it right, and even then, you will get it wrong sometimes. That's why it's so important to try, fail, learn, improve, to not be afraid to fail, but to do it as quickly and cheaply as you can.
So when you're in the throes of design, fighting with your teammates about the "best" design, keep this in mind. There is rarely a single "right" solution in design (even with a nice set of research behind things), and it's even rarer to find the best solution on the first try (no matter who you are), even after surviving a critique. Everybody has a personal design aesthetic that informs where they tend to place things on the scale above. One personal aesthetic isn't inherently better than the other--they need to be conditioned thoroughly by context of use, the people you are designing for, the totality of the app aesthetic, etc. Have patience with each other. Sweat the details, but don't let that paralyze you into not trying things, failing, and trying again. Ultimately you will ship something you know isn't going to be as good as it could be in any case, so do your best to balance but don't expect it to be perfect on the first go.