In 86 slides, Stephen Anderson explains why it's impossible to separate visual design from the core of the product. You can't just make it pretty later. Visual design has to be baked in from the beginning.
Visual design and understanding of gestalt give you the tools to realize your intentions. Interaction design is knowing what a user should be able to do on a given step. Visual design is making something that allows the user to do it, quickly, efficiently, easily, and all the while feeling good about themselves.
In consumer products, how the customer feels when using your software is make-or-break.
Striking example of a remarkable redesign for the most iconic brand in history. Get rid of the bubbles, the drop shadow, the embellishments. Unclutter. Simplify. Reduce.
Do less, be less, and end up with more.
Google’s dependence on hardware and carrier partners puts the final product out of their control — and into the control of companies whose histories have shown them to be incompetent at design and hostile to users.
Windows Mobile was a failed experiment in relying on hardware vendors, partners, and carriers to build a great consumer device. There were too many cooks in the kitchen. There were too many integration points.
Case in point: Bug fixes from the field. To get a device to market, there was the core device team, then a mobile operator/commercialization team, and finally the carrier's support / deployment team. There was no shared database of bugs. No shared responsibility. When schedules were stretched thin and the device was failing even simple tasks, it was too easy to point fingers. Oh, that's the carrier team's fault. That's the OS team's fault. That's the commercialization team's fault. Hardware's fault. Nobody took the reins to ensure a quality product was being created.
The Palm Pre team is doing it right. Google would do well to take note here. Building cool techie platform toys that let you create nifty Powerpoint decks is all well and good. But it's all a huge waste until there's a satisfied user using your awesome phone that works great.
It comes down to responsibility. Someone has to be responsible. If you're creating a device, and you want it to succeed, it better be you and your team.
On my first day of work at Microsoft as a PM six years ago, I sat down with my first manager for our first one-on-one and at the end she asked, Are there any questions? I said yes -- one last one: "When do we decide to remove features?"She was flustered. It was not a question she or probably any PMs were used to answering. I clarified: "Well, features aren't always right. Sometimes they're done wrong, or they don't really fit what the user really wants. Do we ever remove features?" She remained dumbfounded at the question, and feeling like a n00b, I decided not to press further. In time, I realized why she was flustered. As a program manager, you spent so much time trying to get features in that it seems nuts to want to remove them. We made huge spreadsheets of feature lists, prioritized by P1, P2, P0 and sometimes P-1. Yes, negative 1. Because it gets sorted higher, right? Features got removed in other ways though. If nobody really used them, they were obviously chopped out and memorialized as a bullet point in the release notes. But that wasn't really my question. Those are the easy ones to chop. A product gets bloated not because the obviously bad features stick around. They're bloated because there are features that are barely OK in there. They're not complete. They aren't done correctly. Maybe the UI is wrong, or the internal states aren't thought out well enough, or don't match what the user expects. And there are egos attached, too. A poor PM's ego, at the least,and maybe a dev and a tester's self worth too. An entire feature team might have emotional stakes in that feature.
So you can't chop it. And you don't have time to fix it, so it festers. You can never remove features. You have to fix them, painfully, over time.
This can be avoided. Go deep on the things that matter. Do less with less. Be minimal in scope and maximal in completeness. If you're a startup, don't hire. Make it happen with who you've got. Don't get a PM to sit in meetings or create meetings. Only hire do-ers / creators. Do more yourself. If you're a big company, give a skunk-works-sized team a whole shit-ton of power (and really mean it).Be less. Do less. And you'll somehow end up with more.
You should follow me on twitter here.