kuwamoto.org

Recently, Andrew Chen has been mulling over the differences between Apple’s approach to product design and (a) the typical corporate approach and (b) the “lean startups” approach. In a recent post, he proposed the idea of a “minimal desirable product” to try to blend Apple’s approach and the lean startups approach.

I kind of agree with him, but his formulation makes my head hurt.

Apple’s design strategy is to work behind closed doors to build kick ass products that blow you away. They make design choices (like killing sub-par projects) that would make other companies cringe. By working behind closed doors, they are counting on their own design and vision instead of letting the market do the design. Sometimes, they succeed (iPhone) and sometimes they fail (AppleTV so far). When they get it right, they build stuff that is so desirable that people cannot believe their eyes.

The lean startups approach is to build the minimal thing that can possibly sell, get it out there, and then to iterate quickly. The lean startups philosophy says that no central planner can ever outsmart the market, so it’s dangerous to try to design behind closed doors. Instead of wasting time trying to build the perfect product, lean startups get it out there quickly and spend their time listening to the market and iterating.

Both approaches make sense. And it makes sense to ask what one approach might learn from the other. However, the middle ground between Apple’s approach of building the “most desirable product” and the lean startups approach of building a “minimal product” is not to build a “minimal desirable product.” That formulation doesn’t even make sense. So I should only somewhat kick ass? Or minimally kick ass? Could the iPhone have been “desirable” without animation? Probably. Would it have been as successful? Probably not.

Why is “minimal” important?

Building minimal products is important because product teams are notoriously bad at building good products.

Featuritis: Given more resources, a team will typically add more features instead of polishing the features they already have, on the theory that more features = more market share. “Hey! We have more time so let’s make our microwave play CDs. People like to listen to music while cooking, right?”

Listening to customers is hard: You must listen to your customers to understand what their problems are, but you absolutely cannot trust them to tell you how to design a solution for it. They’ll tell you that your product should automatically scan their inbox, and when you build exactly what they told you to build, they’ll hate it.

Killer features are counterintuitive: When we were working on Dreamweaver, we got some things really right and some things really wrong. Round trip HTML was really important. Layout Table view wasn’t popular, and we spent a lot of time on it. It’s really hard to distinguish between killer features and phantom killer features that look good on paper but don’t end up being killer features after all.

You may have the wrong market in mind: When doing design in a closed room, you have a specific market in mind. Meanwhile, your product idea may be best suited to a slightly different market. Spending months and months refining and adding to a product with the first market hypothesis in mind may actually put you behind the eight ball in pivoting to your actual market.

Minimal products means quicker iteration: This is an obvious statement, but this is one of the most important benefits of building a minimal product. Large products with lots of features are like battleships, and while there is a time and place for battleships, they are hard to steer. Smaller, more nimble products may outrun you.

Why is “minimal” dangerous?

Starting with a minimal product and iterating have a lot of advantages, but this approach also has a few disadvantages.

The MVP -> iterate process may not lead to joy: When you play with a well designed product, you are filled with a sense of joy. The whole mindset around minimal+iterate may lead to that sense of joy, but more likely than not, it leads to prioritizing function over design. Capability over joy.

Minimal products may not be a good test of the market: Sometimes, doing something minimal is the best way to dip your toe into a market. And sometimes, you may get a false negative because the thing you build “minimally” tells you that the market isn’t there.

You may end up cutting corners you wish you hadn’t Best summarized here.

Proper minimal design: Build half a product, not a half-assed product

This advice, of course, is from 37 Signals. It seems like just yesterday that these guys were the supposed gurus on building great products and now it’s other people who are the gurus. We should take everyone’s advice with a grain of salt, of course, but in this case, I think the 37 Signals guys have it right.

Focusing on design is not right for every lean startup. It really depends on the market you’re going after and the problem you’re trying to solve. But if you do need to focus on design, then I think it’s even more important to focus on the core essence of what you have and discard everything else. Be ruthless in cutting functionality to boil your product down to its core essence (no cut and paste in iPhone, right?) but then hone and polish and rethink the crap out what’s left until it elicits joy. And then follow the lean startup model to find customer fit.

Making a small product is hard (“I would have written less if I had more time”) but polishing a small product is easier than polishing a big product with a bunch of extraneous features. And when you get it right, you will have a thing of beauty.

Mike and I have had our heads down for most of the year working on our next project (which we are INCREDIBLY excited about, but not yet ready to talk about publicly).

We’re at the point where we need design help, and we need help with everything: branding / identity, usability / UX, CSS / HTML production, etc. As a side effect of looking for great designers, we’ve gotten an interesting look into the state of the design economy.

For UX and identity, we started by looking for the designers we really want to work with (mostly high end) and going down the list. These guys are busy! Every firm we’ve contacted is working at capacity, and if anything, they are looking to staff up in order to deal with the workload. Even though that makes our job harder, I like the fact that these guys are busy.

For CSS / HTML production, we went the opposite route. Because of the nature of our product, we will probably need to work with multiple designers of this type and we put out an open call for submissions on Craigslist. After posting last night (at around 9pm) I found my inbox filled with seventy responses. Some of them were terrible, but some of them were great.

It’s been a while since I’ve posted a Craigslist job listing, so I don’t have a good baseline. Is getting 70 responses overnight for a design gig typical? And what’s the best explanation for the disparity between how busy theUX and branding guys were vs. the HTML / CSS guys? Is it the difference between looking at high end firms vs. doing a craigslist ad? (probably). Or is it that these two design disciplines have different economics?

While designing Notespark, we did a lot of UI mockups. As it turns out, I prefer using Fireworks for this kind of work over Photoshop, because it’s easier to manipulate objects on the screen. After doing some Google searching, it appeared there weren’t any good templates for doing iPhone mockups, so we built our own.

The toolkit is fairly complete now, so we’re sharing it with the world. You can use it to create your own mockups of iPhone apps.

All items in the file have been redrawn as vectors for easy editing. You can read more about it and download it at the post on Blogspark.

Based on yesterday’s episode, I decided to try Buzzword. In order to do that, I needed to install the latest Flash Player.

The installation failed with the cryptic message “The file flashplayer.xpt could not be written.” This message could have been more helpful, but that’s really Adobe’s fault, not Apple’s.

I tracked down the problem to the fact that Firefox was installed using the “skuwamoto” account. Meanwhile, I was trying to install Flash Player using the “household” account.

So I decided to change the owner of Firefox to “household”. Easy, right? Guess again. Changing the owner of an application turns out to be kind of difficult.

~

I started by changing the owner of the file using the info dialog like so:

The install still failed. Take 30 seconds and try to guess why.

Ok. Being a software developer, I knew that applications were really “packages” which are a special kind of Unix folder. If you do a “show package contents”, you find that the Firefox package only contains one folder:

And after doing a “get info” on the folder, I found that the package contents still had “skuwamoto” as the owner. ARRGGGHHH!!!

Why on earth would you want to set the owner of an application without setting the owner of the enclosed folders?? Also note that the original info dialog had no option to “Apply to enclosed items”, so even if you knew that this was something to watch out for, there is no way to fix this without manually opening the package and inspecting the contents.

I mean… I had trouble figuring out what was going on, and I write software for a living.

Over the years, I’ve had the chance to work with some top notch designers, and I always try to learn what I can from each of them. One quote I that has stuck with me over the years is from Michael Gough, who taught me that design isn’t always about finding the “best” solution to a problem, it’s about deciding what the right solution is, and taking a stand.

The original discussion about design happened years ago, during the redesign of the Macromedia website. We had decided to show hyperlinks by using a light blue background color on hover. This is pretty common now, but back then, no one was really doing this. I was wondering why we were using this method of displaying hyperlinks, and we got into a discussion about the philosophy of design. It made me realize that I was looking at things from the usability angle and he was looking at things from a different angle.

The usability angle and the design angle

Back in the 80s, I was drawn to the mac because of the philosophy around usability. I did software projects on the mac and devoured the Inside Macintosh books. I read the human interface guidelines and I thought about usability. I took this perspective with me as I worked on projects like Dreamweaver, Contribute, and so on.

When you look at interfaces from the usability angle, you think about software from a purely functional perspective. Does the customer understand how to use the thing? Does the software do what they want it to do? In a sense, you get the sense that for any usability problem, there is a “perfect” answer out there somewhere for the most usable design, and that our job is to strive toward that “perfect” answer.

Meanwhile, Michael was looking at things from the design perspective. Usability is one of the considerations in design, but it’s not the only consideration. Great designs are more like alchemy than science. Think about the designs of people like Saul Bass, Paul Rand, and Ray and Charles Eames. Their designs take a stand. They express a point of view. They evoke emotion.

The importance of taking a stand

The point of “taking a stand” is not to be needlessly different or to throw out conventional thought. In fact, designs that are needlessly controversial tend to fail, and great designs usually build on conventional wisdom (grid layouts, etc). The important thing, in my mind, is to have confidence in following your ideas and to express them in the fullest. Designs that aim to avoid controversy end up being watered down, “lowest common denominator” designs. In order to push designs forward, you need to take a stand and be prepared to face the naysayers.

Recent design controversies: Adobe CS icons and MTV.com

During the last few months, I’ve been following a few design controversies. The first controversy is around the CS3 icons. Some people love them, while others hate them. I personally love them. The more I look at them, the more I like them.

Before, I could never remember the difference between the hexagon shape and the weird one with the feather. Now, I know what everything is. Not only that, I love the saturated colors. Splash screens tend to be mostly grey or white, with some icons and text. I love the big block of saturated color I get when I launch the new apps.

Whether you like the new branding or hate it, I’m sure you can see that the new branding system has a thought process behind it with a definite point of view. I don’t think you’ll see the designers backing down from their point of view on this one.

Another interesting case study is MTV.com. They launched an all Flash site called MTV Overdrive that caused considerable controversy. Some of the concerns may have been valid (too slow to load, too much stuff going on), while others were just reactionary (Flash sites are stupid, etc). I personally thought this was a good design direction for MTV, given who they are. The MTV site needs to be dynamic, focused on video, and willing to push the envelope.

I learned, via Ryan Stewart, that MTV changed their site back to HTML. You can read about the reasoning and see the comments at the MTV blog.

Now I don’t have any insight into what happened backstage at MTV, and perhaps there were very good reasons for switching back, but from my perspective, it looks like they are not helping themselves any by flip-flopping back and forth. If you read the comment thread, you will see that there are lots of angry people (again).

So what’s the lesson here? Is it that Flash is better than HTML? Or vice versa? I don’t think so. I think the lesson is that when you go for a gutsy design, you need to really believe in it and fortify yourself to see it through. MTV went for a gutsy design with MTV Overdrive. There were some issues (it was overwhelming for some, and slow for others), and from my outsider’s perspective, it seems like they should have kept iterating on it. Again, there may have been very good reasons for the switch, but that’s the way I see it.

Does that mean I have to stop listening?

Does “taking a stand” mean not listening to customers? Not at all. In the end, if people don’t buy into a design, then the design isn’t working. The advice to “take a stand” may seem like a directive to stop caring about what customers want, but in an odd way, I feel like the advice to “take a stand” is the paradoxical answer to how to reach customers in a deeper, more authentic way.

To me, it’s a bit like the conundrum that politicians face. People say they want leaders who are “authentic” and “know what they stand for”. At the same time, if the leader doesn’t follow the will of the people, the leader is “out of touch”.

It is important for politicians to listen to the people, but not at the expense of being who they are. In the final analysis, a politican who derives his/her opinions purely from polls is a politician who doesn’t stand for anything and can’t be trusted. In the same way, a design may require iteration based on feedback from customers, but not at the expense of being what it is.

So don’t be afraid to take a stand. But listen to your customers and be willing to iterate.