Design, development, and distance
There is a problem with combining software and visual design. It ties the look and feel of a thing to the ugly details. It crosses the thinking about the visuals and the technical bits, two very different domains with their own balances and influences. As we don’t multithread well, we don’t naturally separate our thinking of how it’s done to how it should be. It isn’t that programmers aren’t artists (many are), or that we can’t separate ourselves from code (we can), it’s just that we don’t often do it well, and when we do it’s usually a product of time away from the project and a forced discipline of objective thinking.
But it gets worse. Most of us think we can do both well, at the same time, without any stops between what the implementation dictates and what would be usable. With the details forcing the visual design, a project might be soluble, but not much more. It does what we all know to be technically possible, which is to say that it does what any of us could do. There’s nothing interesting about that, but it can be predictable, and it can be dressed up and be presentable. Of course okay is shit, and is nowhere near useful, inspired, or innovative.
Inspired design needs equal, opposing thinking between each of its hemispheres. A product must be usable, despite what the toolkit can’t do. It must perform well (or appear to), despite what the processors and platform can’t do. And it must look and feel good, no matter what. It doesn’t matter that $x can’t do $y, because it MUST DO $z! And debating it in only one head fails with halfway designs that favour what’s known to be possible, what’s easy, or what happens to be interesting at the time. Debate is difficult without opposing, informed viewpoints.
It’s difficult to find balance with a team too: it requires focus and rapport, and a balance of important ideals. Finding that balance, and that set of ideals that produce great software is a difficult problem. The difficulty lies in not only the distance between the mindsets, but also in the nature of the balancing act: it’s not purely fact based, it’s a principled domain with few absolutes (and many opposing beliefs, methods, and measures).
You have to step back to see if a design is balanced. The artists in you, the programmers in you, the business trolls in you. Each of you have to step back, think, dream, and then come back together to debate. Does it work? Does it make sense? Does it look brilliant?
Of course it is possible to design well with a team (just difficult), and it is possible as an individual (just much more difficult). The trick is finding ways to get distance from your thinking so you can look back at it objectively, to question (and obsess) over the project’s principles so that you have a scale to measure your thinking, and to know that it’s never good enough until it is. Honestly, is it good enough? Is it great?
Find distance in your own thinking, a way to not only be objective about what you’re building, but to also see paths that you couldn’t see before. Use what’s come before you, but question it all. Lean on standard methods, but question them, and be critical of what you’re building in every way. Look at what’s wrong with your design and what’s right. Look at what’s wrong with other people’s designs (and what’s right). Find ways to separate your thinking, to clarify it, and to test that it’s not insane.
And then walk away from it. Sleep. Relax. Come back to it fresh and start thinking critically about it again. Wash, rinse, and repeat until great.