Edit: Crap, this was a long one. Because I know none of you will read this, here is a picture of the beautiful Alona Tal as a peace offering:

Sadly, this picture is more valuable than all the words below :(

. . .

Doug Bowman (visual designer) wrote an interesting post about leaving Google: (emphasis mine)

Without a person at (or near) the helm who thoroughly understands the principles and elements of design, a company eventually runs out of reasons for design decisions. With every new design decision, critics cry foul. Without conviction, doubt creeps in. Instincts fail. "Is this the right move?" When a company is filled with engineers, it turns to engineering to solve problems. Reduce each decision to a simple logic problem. Remove all subjectivity and just look at the data. Data in your favor? Ok, launch it. Data shows negative effects? Back to the drawing board. And that data eventually becomes a crutch for every decision, paralyzing the company and preventing it from making any daring design decisions.

A response from somebody a little less critical of Google: (emphasis mine)

I don't think Google had to be a bad fit for you, but that you were put in to the wrong role. Back when Irene Au was building the User Experience team at Yahoo, visual designers (VisDes) were often paired with interaction designers (Gooeys) and usability researchers (UER) and together they would tackle design problems at the product level. This kind of arrangement would have probably been more effective at Google as well. Hiring visual designers only to silo them together means the visual design team lacks the benefit of sufficient inroads in to the product teams the interaction designers have been working with for years. This makes your job impossibly hard, because what product team welcomes a design that is handed to them without their involvement?

Scott Stevenson cuts through the personal feelings and summarizes the crux of the issue:

Visual design is often the polar opposite of engineering: trading hard edges for subjective decisions based on gut feelings and personal experiences. It's messy, unpredictable, and notoriously hard to measure. The apparently erratic behavior of artists drives engineers bananas. Their decisions seem arbitrary and risk everything with no guaranteed benefit.

The important thing is that design decisions are made based on personal experiences. Design decisions are made based heavily on context. The human mind is wonderful in its ability to synthesize seemingly disparate thoughts and ideas at once and to reach a singular conclusion. Subconsciously, I remember bad as well as good UIs, then draw on those ideas when I'm trying to solve a problem.

Engineering decisions can largely be made without any context - and their results are far easier to measure with unit tests. Well written code prevents the need to understand the whole environment you're in - each feature can be modularized and you can have decent success without any cross-pollination of engineers between features. In fact, technologies nowadays are all about gluing together functionality from different languages through the usage of APIs - talk about not needing context! (Caveat reader: This is a slight simplification so I can drive home this point.)

Good design decisions cannot be made without context - while engineering is more about making your puzzle piece fit with the adjoining pieces, good design is about understanding how your piece affects the whole puzzle.

My experiences about data (from chemistry and economics) was that they always assumed a perfect situation. Does a cannonball and feather fall at the same speed if dropped? If you're in a vacuum, sure. But when are you ever in a vacuum? In the same vein, I'm a little skeptical about relying purely on data - it makes the assumption that the same set of factors that gave you that initial data still are applicable.

A good example of this is Amazon. Amazon is notorious for A/B testing to maximize their revenues. While I don't doubt their methodology (they are people who are smarter and more experienced running those teams), are their product pages the shining pinnacle of usability? The human experience in me tells me a big fat no. But what do I know?

What's particularly interesting for Amazon is when they redesigned their homepage to remove strong emphasis on signing-in. Go to their homepage and try to quickly identify the log-in link. It's bured as "Sign in to receive personalized recommendations." Apparently this works - but I feel it's "very wrong." Guess in this case, data wins?

. . .

I believe that software succeeds based on two key components: the strength of its user interface and its ease of installation. PHP and mySQL succeeded because they were always bundled together, and they were installed on every Linux distro by default. Flickr blew all other photo hosting sites because of their humanizing user interface. phpBB and WordPress, both technical disasters (have you ever looked at the source for either of these?) blew out Perl-based scripts (which had first mover advantage) because PHP apps were simply easier to install - it also helped that WordPress and phpBB had passably good user interfaces.

Even at MindTouch, this is clearly evident. Wik.is, our SaaS offering, is our top distribution channel. No need to install - just sign up through your web browser. Our VM image (easiest server offering to install) is incredibly popular - and that's followed up with our Linux RPMs. While we don't have specific numbers yet, I would hazard a guess that pure source downloads account for a negligible number of installs.

While maintaining all these packages remains a huge drag on releases (Pete and Mathieu truly are superstars), I'm firmly of the belief that these multiple packages are the lynchpin of our success. You have to ask yourself: Why would you wittingly lock yourself out of success in a 10% market because you don't make it easy to install?

I throw a stink anytime any feature/design implementation only works on one browser. Either way, you've locked yourself out of 40% of the market out of the gate. When is 40% ever an acceptable (40% FF + IE, 20% misc browsers) percentage? Why would you set such low standards? Unless you can hit 90% of your audience, there seems really no point in building that feature or doing that particular design.

I've been fortunate in the sense that Aaron and Steve are patient with my never-ending obsession with creating usable software (although lately I've been slipping on this just because I've been so busy). I remember in the early days how obsessed we all were with creating the best user experience. It took us nearly two years of real effort to complete the Ace skin (which is hideous, but I'm still proud with how well it's stood the test of time).

An example of this is the control panel of MindTouch. Over the past two major releases, we've iterated through it twice. This goes somewhat contrary to my previous statement, but this is a section that only appeals to less than 1% of the users who ever use MindTouch. So why would we ever spend so much time fixing and refining a feature that affects so little of our user base?

Well, the easiest justification to use is that administrators tend to be the ones who make the judgement call on the software - and making their lives easier helps them to understand the value of MindTouch.

The real answer I tell myself is that it's a part of the application, and any part that looks or acts like crap reflects poorly on the whole application. Mediocrity spreads since it's the path to least resistance - and to have such poor design principles and usability in one component of the site makes it very easy to bleed that crappines to other components.

After two years, I finally decided to throw the Deuce skin I had been working on (off and on) for two years into the latest release. It was my hope that I could run usability tests and get some more data points on what the optimal skin is for utilizing the front-end, but I realized that given how many different use cases there are, that would be a futile task.

I had been using MindTouch for about 4 years. All the data I needed was tucked away somewhere in my mind, and I just needed to trust my mind and instincts to create a cohesive design that would be usable, aesthetic, without taking away from MindTouch.

I have no data points to support any of the design decisions in Deuce - the main design was put together based on my feelings and instincts. Yet it seemed to turn out fine - I've enjoyed using it on my personal VM (it's been a pleasure drafting content in it). You can check out the skin in action at http://trunk.mindtouch.com/

. . .

I was showing my friend MindTouch, and I even surprised at how much progress we've made with such a small team. Not only on the technological front (the stuff we do is pretty awesome), but how much polish the whole application has. Even the roughest parts of our application (link + image dialog) aren't horrid compared to some other applications (hel-lo, WordPress). The file upload process? Pretty great. The control panel experience? Awesome.

It was nice to take a step back and appreciate the hard work we had done. While each battle to create the best UI seemed distinct, at the end, it all came together to create an application that is truly beautiful to use.

What does the future hold? I'm concerned that as I get spread even thinner at work, my ability to truly focus on the user interface, one of MindTouch's unpublicized strengths (good user interface is simply something you don't really sell against, unfortunately) will wane. And that would truly suck.

One of the realities of my job is I have to deal with internalizing different conflicts and finding the best solution. Decisions must oftentimes be made at the expense of something else. We can cut corners on a feature and "just get it done", or we can spend the extra time really making it awesome. You can either pay big costs to build an architecture to build a feature (getting the benefit of being able to build more stuff on it), or you can simply build the feature by itself in a quarter of the time. Each release must be balanced by having features people want to buy, features we know will be great but aren't requested ("looking ahead"), and code refactors to pay down technical debt (from when we cut corners or we know it can be done in a better way) which do not exhibit to end-users in ANY way.

All three are necessary for a successful product, and that seems to be the role of a successful product manager - balancing these acts into good releases.