We might as well make beautiful things

by Rian on November 20, 2011

This is one of my favorite stories in the Steve Jobs biography:

The result was that the Macintosh team came to share Jobs’s passion for making a great product, not just a profitable one. “Jobs thought of himself as an artist, and he encouraged the design team to think of ourselves that way too,” said Hertzfeld. “The goal was never to beat the competition, or to make a lot of money. It was to do the greatest thing possible, or even a little greater.”

He once took the team to see an exhibit of Tiffany glass at the Metropolitan Museum in Manhattan because he believed they could learn from Louis Tiffany’s example of creating great art that could be mass-produced. Recalled Bud Tribble, “We said to ourselves, ‘Hey, if we’re going to make things in our lives, we might as well make them beautiful.’”

See also The difference between Apple and Microsoft: product before profit.

John D. Cook writes some scary true words in Productivity and negative space:

People who fracture their time putting out fires seem more productive, or at least more responsive, than the people who block out time to think. It’s harder to notice someone not being frantic. Thinkers don’t fare well in environments that reward activity more than accomplishment.

This is such a huge problem in big corporations today. People who are running from meeting to meeting are perceived to be more productive than those who sit at their desks working all day[1]. And the problem is worse for programmers – very few managers understand what they do, so it’s hard for them to stomach days and days of solid coding without seeing something “tangible” (in their view).

It all comes back the difference between Makers and Managers, and how the Makers should be evaluated on completely different criteria than the Managers. Criteria that reward the quality of what they make, not the number of status updates they give.

(link via Graham Poulter)

 


  1. I’m not saying that people who have a lot of meetings are necessarily less productive, just that those who are not in meetings are “out of sight, out of mind”, and therefore not seen as particularly productive.  

Copying taste without understanding design

by Rian on November 18, 2011

Rob Beschizza in What the Vaio Z says about Sony’s little design problem, a brilliant article on the difference between taste and design:

Apple competitors are obsessed with copying Apple’s tastes without copying its central design habit, which is solving a problem and then refining the solution until the problem changes.

This is also what makes the HP Envy such a bizarre rip-off of the Macbook Pro. It all reminds me of that scene in Armageddon where the Bruce Willis character blows up at the contractors who tried to build an oil drill he designed:

Let me get this straight. You had me pulled off my oil rig, flown half way around the world, you stole my drill design, couldn’t read the plans right, and did a piss poor job of putting it together!

I can image hearing those same words coming out of Steve Jobs’s mouth if he could see the Sony Vaio Z and the HP Envy.

Taste and consequences

by Rian on November 15, 2011

It’s not possible to get to know a man just by reading a book about him. And yet, that’s what many of us are trying to do with the Steve Jobs biography. To be fair, we do this whenever we hear stories about people. We tend to forget that there’s more to a person than the scraps of information we can extract about them from others. This isn’t necessarily a bad thing, but we must place our opinions in the proper context.

I realize that my thoughts on Steve Jobs are not only based on imperfect words on a page, but I’m also reading those words through the biased lens I use to perceive the world. At best, I’m getting an interpretation of a copy of who he really was. And I’m ok with that, because even feint copies of an original can teach us things, which is why we read these human stories in the first place.

So with that disclaimer out of the way, I believe that Steve Jobs’s genius was rooted in two main character traits: Insanely great taste, and an inability to compromise on that taste at all. This inspires me, but the way his unwillingness to compromise came out of him also makes me extremely uncomfortable.

[Read more...]

Product vision and roadmaps

by Rian on November 11, 2011

Jared Spool in The Value of Apple’s Knowledge Navigator: Gruber Has It Partially Right:

When teams don’t have a vision […], each person is walking around with a different understanding of what the end of the journey should look like. When there’s no common understanding on what that end point looks like, each decisions is evaluated on a different criteria and the resulting products end up looking like crap.

This is why I believe that product roadmaps are not evil. As I’ve written before, at our company we are very clear that the product roadmap is a flexible guideline that can (and must) change frequently as needed. But it gives the teams (and the management team) something to work towards. It’s a common vision, a sense of direction that’s more than just fluffy language – it’s concrete evidence that we’re headed somewhere good, and we know how to get there.

Bret Victor wrote a very interesting rant a few days ago on the the problem with touch interfaces and the future of Interaction Design. The piece got a lot of attention, so today he followed up with some responses to the questions and comments he received.

I particularly enjoyed his thoughts on the limits of voice control. His argument is that voice is a good way to get information or issue commands (yes, like Siri), but that it’s not very good for creating and understanding:

I have a hard time imagining Monet saying to his canvas, “Give me some water lilies. Make ‘em impressionistic.” Or designing a building by telling all the walls where to go. Most artistic and engineering projects (at least, non-language-based ones) can’t just be described. They exist in space, and we manipulate space with our hands.

It’s obvious, yes, but I think we need to remind ourselves of this. Creating things requires “manipulating space with our hands”, even if that means manipulating words onto a page when they’re stubbornly stuck in space somewhere.[1]

 


  1. Sure, some people (like John Siracusa) are able to dictate the first drafts of stuff they write, but I’m pretty sure they’re not editing their work through voice control. Editing (which is the hardest part of writing) requires a keyboard and lots of banging your head on it.  

Aaron Swartz in a great piece called Steve Jobs and the Founder’s Pain:

Something that’s perfect just feels much, much better than something that’s almost right. When I’m doing something myself, I can just sit there and work at it until it’s exactly right. It’s embarrassing to launch a product with a bug in it! It physically hurts when I realize that’s what I’ve done. But as projects and companies grow, there are more and more people in between me and those tiny details. And then I face a choice: do I keep complaining until something’s perfect or do I just let go and consider it somebody else’s problem?

The people who are not content to make it somebody else’s problem are the ones who end up changing the world.

(link via @vhata)

I’m a little late to this article that made the rounds last week, but I finally read The inside story of how Microsoft killed its Courier tablet. It’s a bit scattered and sometimes hard to follow the narrative (probably because it was split into two pieces), but it’s still a very interesting story and worth reading. For one, if Microsoft found a way to keep J Allard around, things might have turned out differently for them. He seems like exactly the kind of person they needed to deliver real product innovation in the mobile computing space.

The most interesting part for me is how the article shines a light on the differences between Microsoft and Apple’s approaches to product development. Here’s Jay Green in the CNET article about the Courier tablet:

Courier’s death also offers a detailed look into Microsoft’s Darwinian approach to product development and the balancing act between protecting its old product franchises and creating new ones. The company, with 90,000 employees, has plenty of brilliant minds that can come up with revolutionary approaches to computing. But sometimes, their creativity is stalled by process, subsumed in other products, or even sacrificed to protect the company’s Windows and Office empires.

Microsoft has a fear of not doing anything that could cannibalize their cash cows (Windows and Office), even if that means they have to do things that don’t create value for users. It’s an organization that’s optimized for profit, not product. Contrast that with Apple’s approach:

Apple hasn’t optimized its organization to maximize profit. Instead, it has made the creation of value for customers its priority. When you do this, the fear of cannibalization or disruption of one’s self just melts away. In fact, when your mission is based around creating customer value, around creating great products, cannibalization and disruption aren’t “bad things” to be avoided. They’re things you actually strive for — because they let you improve the outcome for your customer.

Kyle Baxter adds the following perspective on an approach that places product before profit:

[N]ot only does focusing on the product make for better products, but it completely changes the corporate, business and organizational decisions you make, too. If you are focused on maximizing profit (in the short or long-term), you end up making choices that inhibit great products and great success at best, and destroy your ability to succeed at worst.

The Courier project should serve as a cautionary tale about what happens when the fear of losing profit gets in the way of developing a potentially great product. A product that could have resulted in a very different tablet landscape than the one we have today.

I love pretty much everything Frank Chimero writes, and his essay on the meaning of design from a few weeks back still rings in my ears:

We should care more about our craft because we’re granted an opportunity to contribute to the world. We should care more about what we say because each time we speak, there’s someone there to listen. We should care more about our audiences because they are the ones who give our work value. We might think that design work is about you or about me or anyone else who makes it, or maybe about the things that we make and the artifacts we produce, but don’t let this way of thinking fool you. The things we make are all just excuses to speak with one another and to help one another. We are all linked, and the things that we make for each other strengthen the invisible threads that tie us all together.

Many people won’t agree with this sentiment. Many will think it’s silly to think about something as trivial as web design in this grandiose way. They’ll remind us that we’re just making web sites, not saving the world. And that’s fine – not everyone is going to care as much about design, or even understand why some of us do.

But I do care. I care because I think we have the opportunity to shape a technology that is at once exhilarating and dangerous. A technology that has the massive opportunity to bring people closer together, if we can just keep it together long enough not to destroy each other in YouTube comments and flaming blog posts.

So, yes, I care a lot about this, probably more than I should. But I’m with Frank on this: everything we do is just an excuse “to speak with one another and to help one another.”

Being honest about technology

by Rian on November 6, 2011

I’m still slowly making my way through Sherry Turkle’s Alone Together, and this quote really jumped out at me this morning:

We have to love our technology enough to describe it accurately. And we have to love ourselves enough to confront technology’s true effects on us. These amended narratives are a kind of realtechnik. The realtechnik of connectivity culture is about possibilities and fulfillment, but it also about the problems and dislocations of the tethered self. Technology helps us manage life stresses but generates anxieties of its own. The two are often closely linked.

Here’s another great example of how differently designers and users see the world. When we hear the word “clutter”, we think of visual noise. But Jared Spool explains what users mean when they say that word:

Over the years, we’ve learned that users have a different meaning of “clutter” than the designers do. It’s not the visual design the users are reacting to. It’s the actual content. Clutter is what happens when we fill a page with things the user doesn’t care about. Replace the useless stuff with links, copy, and content the users really want, and the page suddenly becomes uncluttered.

Here’s the kicker – their redesign was actually more cluttered, but users didn’t care:

We put the old and new pages side-by-side. The new page definitely had more text, less whitespace, and more dense information design. Yet, when we asked the users to tell us which one was more cluttered, they were unamimous: the old design was the cluttered design.

It’s another reminder (sorry, yawn) about the importance of Content First. I keep coming back to Jeffrey Zeldman’s classic essay Style vs. Design:

Most of all, I worry about web users. Because, after ten-plus years of commercial web development, they still have a tough time finding what they’re looking for, and they still wonder why it’s so damned unpleasant to read text on the web — which is what most of them do when they’re online.

I completely agree with Gabe Weatherhead’s views on apps made for kids in The Value Of App Reviews:

My number one reason to give a bad rating and review is when an app made for kids has both up-sell and review requests plastered all over the screen. They are trying to prey on small children tapping anything that pops on the screen. If you make a kids app, do not put links to your other apps in the game. Put them in the preferences. Put them in the app description. Hell, put them in some kind of app documentation. But when they are in the game, you are telling me that you’re shady and unscrupulous and I can’t trust your app.

This is a dark pattern, and I simply delete the app if I come across this kind of design. For some better patterns to follow when designing apps for kids, see Luke Wroblewski’s Touch-based App Design for Toddlers.