Zing

John Gruber is right: his four-year-old Daring Fireball essay, Ronco Spray-on Usability, still holds up nicely indeed.

Alas, the notion that usability is the easy part—something you just add on after doing the hard part of writing the code—is hardly limited to the open source community.

There are still many companies that think information architecture holds a mirror up to the org chart.

There are still many web clients who believe it is more important to support an “investment” in a moribund technical platform than to create great user experiences.

There are even (although there are far fewer than there used to be) some designers who think their primary job is to wow the user with their skills.

[tags]design, usability[/tags]

26 thoughts on “Zing”

  1. I have also found that some designers really report to the ad sales team. Really doesn’t matter what the user wants or expects, just as long as we can somehow fit two more ad units on that page.

  2. There are even (although there are far fewer than there used to be) some designers who think their primary job is to wow the user with their skills.

    What do you think has caused the decline in designers not simply in it to wow? Do you think they died off with a survival of the fittest type of mentality? Do you think they are still out there, but are now drowned out by those that understand that design isn’t about decoration?

  3. And there are those who design because they have to fulfill the CEO’s ego. Oh wait, you mentioned that. – “their primary job is to wow the user with their skills”

  4. support an “investment” in a moribund technical platform

    Ah, our old friend “throwing good money after bad.” Just ’cos it’s a cliched saying doesn’t mean it ain’t true.

  5. Basically, usability is about reducing the users’ mental burden by providing good answers to the ‘how do I do it’ problem, thus allowing them to concentrate on the ‘what should be done’ problem.

  6. Do you think they are still out there, but are now drowned out by those that understand that design isn’t about decoration?

    Yes, they are assuredly still out there, but their voices aren’t heard as much.

    Also, people who called themselves des9ers in the 1990s have grown up; their work experiences have probably deepened their understanding of what design is really about.

    And people just entering the field are probably influenced by designers who are more UX-savvy, and who care about legibility as well as typography. And don’t underestimate the influence of companies like 37signals, who offered a whole new way of becoming a design rockstar.

  7. …becoming a design rockstar

    piffle.

    Good design isn’t becoming the Axl Rose of GUI. That’s silliness.

  8. To summarize what Yoav says: “don’t make me think”. Also, Mr. Zeldman, the tab order on this comment for is out of wack. I’m guessing that is not intentional.

    Maybe WordPress would be considered an exception, since they even hired a usability guru (minus points for having no beard though). However, ‘real’ developers mock this toy system that is not object oriented, uses no template system or known framework, no MVC, and is built in that pre-school language with no structure called PHP. Yet, only Google Blogger can compete with it (and that’s closed source). It’s all probably because Matt (_photo_matt, not _hacker_matt you see) is a visually oriented guy.

    Still, all puns aside, I would just love it if a bunch of bearded unix guru’s went to WordCamp and just rewrote the whole shebang using an OO framework and templates. And they would have to write a backwards compatibility bridge of course, so not all WordPress blogs would suddenly fall apart.

    Matt, are you listening?

  9. John Gruber is not right.

    I mean, if you’re talking about public-facing applications like web sites, desktop apps, or operating system GUIs, then sure, usability is very important and very difficult. But it is pretty ridiculous to say that usability is somehow more important or more difficult than developing something like CUPS (which, like lots of open source software, is a component that’s useful to lots of people even without a GUI).

    At the risk of offending my betters, Mr. Gruber’s argument that UI development is the hard part. And it’s not the last step, it’s the first step. is flat out wrong when you’re talking about something like CUPS, or, indeed most of the systems driving something like Linux. I think the reason that Gruber’s argument irritates me is that, if the usability dolts who created Linux and its various subsystems had shared this view, they probably would not have bothered to create Linux in the first place. Meaning we’d be stuck with the much less compelling systems driving Windows and the original Mac OS.

    I mean, I appreciate the good folks who work their fingers to the bone to bring me usable websites and applications, but lets not let lose sight of the huge amount of talent that went into designing the underlying software engines as well. Those developers are artists in their own right, and we are all indebted to their efforts.

    So yes, in some cases, usability should come SECOND.

  10. Even more organisations treat accessibility as something that you bolt on at the end.

    Actually, I’m lying — most of them don’t think of it at all.

  11. There are lots of those designers still here in web agencies. I think there’s just more good designers, so we look at less shoddy work. But it’s still there.

  12. and there are graphic designers thinking 300 dpi works on the net. A rampant problem with sites that are done in my area.

    Also accessibility is an unknown up here. e.g.: The local technical college teaches web design courses and they teach students to do layouts with tables.

    *sigh*

    I’m certainly glad I had attended the AEA in Boston, it certainly opened my eyes a bit wider to usability.

  13. As hard as you try to define usability, I doubt you’ll ever be able to do it precisely. Each user has their own personal preferences that are impossible to predict. The best you can do is make an educated guess at the average.

    Some of the users of my web apps say they want the submit button on the right. If I move it to the right, then I get to hear from another group of people wishing it were to the left. Same story for font size, font face, color combos, and pretty much anything that can be designed and re-structured to enhance the experience. I’m reminded of the CICS terminal emulators that display no graphics, but the user can control which monospaced font to use and whatever color combos they like. You wouldn’t believe the color combos I’ve seen. But the bottom line is that they have a limited amount of preferences, just enough to suffice their wants. I’d like to bring this concept to the web, but the most difficult part is choosing the limit.

    I’ve redesigned a couple of our intranet sites, and I still get the occasional email saying they liked the old one better. The old one was a complete nightmare with no organization what so ever, an eyesoreful jumble of colors that should never be displayed together, and an abundance of confusing instructions with poor grammar. So I’ve pretty much come to the conclusion that functionality comes first. Then I worry about design, then usability/information architecture.

    I could be way off, considernig my experience is somewhat limited. But this has proven to be a successful formula for me (so far). It’s definitely worth noting that these are internal business applications, nothing that is meant for the public eye. Anyways…

    The part about wowwing users with the skills is great, I’ve felt the same way for quite a while. Good zinger, Zeldman!

  14. @Josh Stodola

    The best you can do is make an educated guess at the average.

    I think I know what you are saying, but I think your wrong. While it is difficult to guess each user’s own likes and dislikes, using usability testing methods can teach a great deal about norms in usability–aim small miss small. You will have the occasional “where is this located” but thinking about usability will ensure that the masses can use your stuff better.

    Why was windows created in the first place? To make the computer more usable. Did everyone get on board right away? Maybe not, but the masses found clicking an icon was much more usable and forthright than typing in dos commands.

    You also stated:

    I’ve redesigned a couple of our intranet sites, and I still get the occasional email saying they liked the old one better.

    What I believe your users are really saying is really not about visual aesthetics, they don’t like it because it is wildly different from what they are used to. Which brings up another point about usability, you can follow design norms, but there is still a learning curve with any UI.

  15. Paul Redmond says [..different from what they are used to..]

    I don’t know, they could also be personal preferences, but these are not important in usability. Nielsen says “don’t listen to what they say, look at what they do”. And that’s because they may like the button on the other side, but since the most logical place is on this side, they will look there first, making the task easier.

  16. Jeff P is wrong. I’m sure he means well, and he seems to recognize good usability when he sees it, but it’s a mistake to conflate the user interface with “usability” in general.

    APIs are user interfaces. In order for something like Twitter or RSS or GSM or any of the other myriad technical conveniences we take for granted to work, a hell of a lot of back-end work has to be done, starting with thinking about how the user is going to do things.

    When you consider how incredibly limited cellphone interfaces are (usually just a few lines of text, and a number pad), it’s a miracle we can make calls at all. If Jeff P had his way we’d be exposed to the raw bytecode running on the Broadcom chip inside the phone, because the developers did a lovely job on that so we can send everyone else home early, ok?

    I really despise this attitude that the code is all that matters. _Good_ code matters, and good code that is _easy to use_ matters more than code that is closed, or hard to grok, or poorly conceived, or once built, cannot have a good UI attached except by Herculean efforts.

  17. is hardly limited to the open source community

    If you’re implying that the open source community by nature doesn’t care about usability, then I’d say that you’re wrong. The open source community works on the principle that each developer does what he or she thinks is necessary to make the product worth using. If the product is not usable to a certain class of people – say, everyone who is not a unix hacker, for example – it’s because the developers of the product either have no idea that these users cannot use it (no feedback?), or lack the skills to make it usable to them (quite common), but also because all the people who really do have the skills and who know the problems have chosen not to contribute.

    If open source software fails usability tests, its because usability experts are not interested in improving open source software.

    Oh, and this wordpress blog’s usability is broken. It won’t accept my email address because it’s on a .info TLD, and the validation regex looks for 2 or 3 character TLDs. That regex will probably fail most RFC2822 valid addresses.

  18. I found this last bit amusing:

    It’s easy to ridicule the estimated 2006-or-2007 ship date for Longhorn, the next major release of Windows. But do you doubt for a moment that Longhorn will provide more improvements from Windows XP than desktop Linux will gain during the same period?

    I haven’t personally used Vista or Ubuntu, and I don’t doubt that Vista is easier to use. But which one has made more gains? Based on what I’ve heard, anyway, it’s Ubuntu.

  19. “If Jeff P had his way we’d be exposed to the raw bytecode running on the Broadcom chip inside the phone, because the developers did a lovely job on that so we can send everyone else home early, ok?”

    I’m not sure that that’s what I said, AJ. I said that usability should come SECOND when you are relying on the efforts of some (mostly anonymous) developer to make the underlying technology work in the first place. The example cited was that of CUPS, which was savaged in Gruber’s post for being unusable. However, when Apple’s engineers had to come up with a printing system for OS X, they used CUPS and BOLTED ON A USER INTERFACE to fix the usability issues. Now OS X has one of the nicest printing systems around.

    Gruber himself had to tackle this criticism of his message in the follow up to his article, where he is forced to clarify:

    “Yes, Mac OS X is built with lots of open source software under the hood. But point #1 doesn’t imply that the entire implementation needs to be written from scratch. Yes, Mac OS X contains a lot of open source software under the hood — but these components are used to implement Apple’s designs, not the other way around.”

    But, of course, this is somehow different from BOLT ON usability.

    So to your point, AJ, if the raw bytecode on the Broadcom chip inside the phone WORKS WELL and provides a stabile platform for me to build my phone application, then you won’t find me disparaging the chip designer for issues of mere usability – my end users would never SEE their usability issues because I would develop an interface to hide them. The chip designer has done their job, and now its time for me, as the integrator, to do mine.

    Look, Zeldman intended this thread to hold a spotlight up to the ongoing usability issues he sees in the industry (and perhaps in the WORLD in general). I’m cool with that. Let’s make things usable. Why not? My only point is that bolt on usability is not always a sin, and it strikes my as somewhat shrill to consider it such.

    If the component you are bolting on to is a GOOD component, then it is fine to add usability after the fact. If the component you are bolting on to is bad, then scrap it and get a new one. Or write your own! My point is that this consideration should often be based on an ENGINEERING evaluation, not primarily one of usability.

  20. I found this last bit amusing

    Yeah, that part didn’t hold up so well. But who could have imagined that the reception for Vista would be as poor as it was?

    If the component you are bolting on to is bad, then scrap it and get a new one. Or write your own! My point is that this consideration should often be based on an ENGINEERING evaluation, not primarily one of usability.

    Let’s agree that every component (consumer-facing or not) should be brilliantly designed and usable.

    Generally speaking, websites and web applications tend to do best when they’re designed with the needs of real users in mind. That means coming up with features people need (not just building stuff because it’s cool); implementing those features in ways that don’t require a huge learning curve on the user’s part; making features easily discoverable; and creating language, design, and architecture that help the right user find the feature or content she’s looking for. Gruber uses “usability” to mean all that; it’s a driving force behind good design, whether of websites or software.

    This doesn’t mean, though, that the underlying programming is unimportant. It’s vital — I agree with you. Build a great website on a bad platform and you guarantee failure. I can see how a developer might take umbrage at Gruber’s suggestion that the part that touches the consumer is more important than the part she doesn’t see. Gruber was of course reacting to Raymond’s naive and disingenuous “discovery” that the front end matters — and Gruber’s dismissive tone toward programming versus usability probably comes from Raymond’s dismissive tone toward design/usability, which Raymond mistakenly thinks of as the easy part.

    None of it is easy — we can all agree on that. And all of it is important. As a designer, I wouldn’t have spent eight years pushing web standards if I didn’t respect the technological underpinnings of our digital world.

  21. @Jeff P: Sorry, but you’re still wrong.

    First, as someone else noted, systems programming is just as much concerned with ‘usability’ as user-facing programming; only the criteria for ‘usability’ changes. You may be dealing with APIs, calling parameters and returns instead of menus, entry fields and dialogs, but the first design priority is still ‘how is this code going to be used‘ – not ‘how will this code work.’ If it’s not, you’re setting yourself up for trouble down the road when it comes time for integration…

    Second, your CUPS example is still guilty of cart-before-the-horse mentality. It’s just as likely – in fact, from what I know of Apple, more likely – that instead of picking CUPS and thinking ‘how do we make it usable,’ the OS X design team thought ‘how do we want OS X printing to work’… and then looked at code to implement it, and picked CUPS.

Comments are closed.