26 Following


Getting Real: The Smarter, Faster, Easier Way to Build a Web Application

Getting Real: The Smarter, Faster, Easier Way to Build a Web Application - 37 Signals Very quick read, but not a particularly good one. The advice is extremely simplistic, bordering on platitudes, and much of it is not particularly actionable. A lot of it simply does not apply to *many* companies: e.g. building for yourself is all it takes to find a market (tell that to the many engineers who built something that *only* they would want), everything can be self-funded (many business cannot), everyone should give away all of their data for free (unless, of course, data is your differentiator, which it is for many companies).

It's not all bad, of course. The advice on design is actually quite good, mostly because it sticks with very concrete details: e.g. avoid too many preferences/settings in an app, design for regular, blank, and error states, copywriting is part of the design, and that your app has a voice. And some of the quotes from third parties are decent too.

Overall, there is some good stuff in this book, but it doesn't do a very good job of presenting it.

Some quotes that I liked:

Build half a product, not a half-ass product

The best designers and the best programmers aren’t the ones with the best skills, or the nimblest fingers, or the ones who can rock and roll with Photoshop or their environment of choice, they are the ones that can determine what just doesn’t matter. That’s where the real gains are made. Most of the time you spend is wasted on things that just don’t matter. If you can cut out the work and thinking that just don’t matter, you’ll achieve productivity you’ve never imagined.

Another reason to design first is that the interface is your product. What people see is what you’re selling. If you just slap an interface on at the end, the gaps will show.

Design for regular, blank, and error states.

The customer decides if an application is worthy at this blank slate stage – the stage when there’s the least amount of information, design, and content on which to judge the overall usefulness of the application. When you fail to design an adequate blank slate, people don’t know what they are missing because everything is missing.

Copywriting is interface design. Great interfaces are written. If you think every pixel, every icon, every typeface matters, then you also need to believe every letter matters.

Encourage programmers to make counteroffers.You want to hear: “The way you suggested will take 12 hours. But there’s a way I can do it that will only take one hour. It won’t do x but it will do y.”

Lorem ipsum changes the way copy is viewed. It reduces text-based content to a visual design element – a shape of text – instead of what it should be: valuable information someone is going to have to enter and/or read. Dummy text means you won’t see the inevitable variations that show up once real information is entered. It means you won’t know what it’s like to fill out forms on your site. Dummy text is a veil between you and reality.

Think of your product as a person. What type of person do you want it to be? Polite? Stern? Forgiving? Strict? Funny? Deadpan? Serious? Loose? Do you want to come off as paranoid or trust- ing? As a know-it-all? Or modest and likable? Once you decide, always keep those personality traits in mind as the product is built. Use them to guide the copywriting, the interface, and the feature set. Whenever you make a change, ask yourself if that change fits your app’s personality. Your product has a voice – and it’s talking to your customers 24 hours a day.