November 23rd, 2009

A while ago I wrote a glowing post about Google which a number of people told me they liked; I never wrote a followup post, but I have a lot more thoughts on the subject.

Pretty much everything I wrote in that post turned out to be true — Google really is a very bottom-up company. The feel of the place is like an open source community which has been placed behind a corporate wall; that is to say, there’s a relatively free and open exchange of ideas within the company: as an engineer you have access to nearly all the source code, and lots of ideas come from the bottom up. It has such an open source feel, internally, that the ethos permeates it, to the point where many Google projects end up being open sourced outside the corporate wall; Android, Chrome, and Chrome OS all come to mind. This contributes a great deal to solid engineering, as we all know now, open source as a development methodology does work well for creating reliable software. However, it turns out that this architecture has one major failing: a lack of understanding of design from the user perspective. For all the solidity of Linux and free software from an engineering perspective, it still falls far short of being easy to use.

This is not to say that Google products are as hard to use as Linux — they do have designers at Google, they do user research and testing. There is an awareness of user experience as a field and a theoretical commitment to it. But — Google is, at its core, a company made by and for engineers. As stopdesign, Google’s first visual designer, put it in his famous post last March about why he left Google: “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.” Google’s engineers drive product ideas, they drive product design, and this turns out to be its major weakness.

While working at Google I got one of the early Android phones; I have to admit, Android is a beautiful piece of engineering. It’s responsive, stable, and feature rich, unlike Windows Mobile, which has been an unmitigated disaster for years (see my comments about Windows Mobile below that article). However, there’s just something clunky about Android. Yes, it’s far superior to every other smartphone OS… except the iPhone; next to that, it pales in comparison. It’s not simply because Android can’t use some of Apple’s patented UI ideas; there are just a lot of places where things are more complicated than they should be, take more steps, or are inconsistent. It’s less pleasant to use than an iPhone. If I were to give it a subjective score, I’d say it’s “half” as nice to use as an iPhone.

That was my first clue there was something amiss at Google. But then other things happened; I realized I was unusual in my design orientation — I believed in user research, talking to users, designing with users in mind. While my managers and coworkers initially seemed open to this, the more I tried to bring this into the development process, the less well-received it was. The focus there seemed to be primarily on coding — how much code did you write last week? Did you write your code the way I would have written it? How well was it formatted? Of course, I realize that was just my experience in the one group I was working with, but I got the feeling that this was a widespread phenomenon — the key thing people seemed to value at Google was code, and to a lesser extent engineering architecture — but design definitely takes the back burner.

I am a very good coder, but I spend a lot more of my time and energy thinking about higher-level considerations. How would this code support users? How does it help people do things they might actually want to get done? Is it a pleasure to use? Is it intuitive for most users, not just for a small subset of users? I like to think about design and architecture and code as a system, how it all fits together to create an excellent user experience, and how one can write code which is flexible and clean, so it’s easier to modify later on. But most of all, I like to start with the user, how they would use the system, and design and architect and code with that in mind.

But the first hurdle I came across was there was no way to get someone from the UX team to help our project; no one was available. There weren’t enough designers around; we could only get part of one designer to do a little bit of consulting. So, I thought, okay, I guess I’ll have to do some user research myself. I did manage to talk to a user researcher who gave me some pointers, and thus (poorly) equipped I started making phone calls. One of the benefits of Google was the ease of talking to people at all levels; I happened to be in the same room with the CIO of Google (I didn’t know who it was at the time) and he suggested I call a VP at a major corporation who might be interested in giving us feedback on our design, because that VP used to be one of his employees. I did, and the VP was really interested in talking with me, so I set up a couple of meetings.

My manager didn’t show up. Furthermore, he seemed to think my effort was a waste of time — that we already had in-house resources who knew everything we needed to know about how people might want to use the product. I got a ton of useful feedback from the VP, who could have been a major user of the product I was working on, and wrote up reports, and got no response from anyone.

This was another clue that something was amiss at Google.

I realized that no matter how much I wanted to inject a design sensibility into my work at Google, it wasn’t going to happen. And I realized even if I managed to get into a greater position of authority, I wasn’t going to be able to significantly influence things from there, either; because of the bottom-up structure, managers don’t have a lot of say in how engineers do their work. It’s a company made by and for engineers, as I said before, and engineers are going to do their work in the way they want to do it, which creates, in the end, a kind of open source sensibility. There’s no one at the top who really understands and values design, and for that reason it gets short shrift.

Since I left I’ve seen a series of products or product ideas come from Google which I believe support my thesis that it’s engineer-driven product design. While Google values “simplicity” (it’s one of the core principles of the company), they tend to conflate engineering with user simplicity. Chrome OS, for example, is a cool engineering concept (get rid of everything in the OS but the browser, and have all “applications” simply be browser apps), but simplicity of engineering doesn’t mean simplicity from the user point of view. The iPhone, by contrast, has plenty of non-browser OS functionality, but from the user point of view it is simple and consistent and easy to use and does what users want it to do. Google doesn’t seem to realize that making things simple for the user might mean having more complicated engineering. Also, why make Chrome OS when Google already has Android? I suppose this is again the plus and minus of the bottom-up culture: there isn’t really a lot of coherent product strategy, which results in a plethora of ideas — however what if those ideas are bad designs?

Then there’s Google Wave — I could write many posts about my problems with Wave. It’s complicated to use, confusing, and there are many things about the user experience that seem unnecessary… but at the same time, it’s based on a really old idea, email. The collaborative real-time multimedia editing is cool, but why stick that into an outmoded format, email? People have been moving away from email and towards forms like wikis and Twitter, etc., as ways of communicating, but Wave seems to have missed much of that. The collaborative editing feature seems ideally suited to, say, group wiki creation, but Wave isn’t really a group wiki tool; it doesn’t support linking very well, so you can’t really create a web of waves very easily. Having to specify a user or list of users for each wave is cumbersome — it should be far easier to publish waves to groups. If Wave supported linking better, a wave could then be used to organize other waves… (in fact, if Wave were just a collaborative multimedia real-time wiki it would be a hell of a lot more useful). But, instead, Wave builds on an outmoded email metaphor and dumps a ton of “features” into it. Designing a bucket of features is the first sign of “engineery” design and not the way to design, in my opinion.

Google’s search is still the best in the universe, and probably will remain so for a long time. Maps is good, and so is GMail, both of which I use all the time. But it was the Maps team that designed Wave… perhaps they were lucky with Maps, or perhaps they were better at building products based on refining existing paradigms rather than creating new ones.

I still think Google is a great company and I think it’s a great place to work for a lot of people. It will continue to produce products of superior engineering and mediocre design, probably for the rest of time… and there’s really no way to change this, in my view, precisely because of the bottom-up structure of the company and the fact that none of the founders were designers. Google is what it is, and will be that way indefinitely, I think. It’s a grand experiment in an engineer’s engineering company.

permalink | comments(rss)

comment trackback