Earlier this summer I got the chance to interview Luke Wroblewski of Functioning Form. Luke’s a great writer and longtime web application designer currently working on Yahoo! Social Media. Following the interview we kept up an informal dialog around the idea of a design lifecycle.

Well, we ended up archiving it in Writely, and filling it out a bit. Luke’s got the first part up now. (I’ll be publishing some parts of it during the week).

The Lifecycle of Design: Part 1

Continue Reading: The Lifecycle of Design: Part 1

This past week’s Digg controversy is one in a growing number of incidents that suggest that a small group of users are having an undue influence on the promotion of stories. In response, Digg is changing the way that it handles votes by adding complexity to its ranking algorithm. I think that’s the wrong approach, so here’s another idea: change the actual design of the site…that’s the real problem.

The most recent controversy happened on September 5th, when someone named jesusphreak posted Digg the Rigged?, an in-depth article exposing some of the curious details of recently-popular stories on digg. Many of the stories, jp pointed out, were dugg by members of the Digg Top 30, or the 30 most popular digg members (popular being measured by number of stories submitted that were promoted to the frontpage). The Top 30 includes Digg founder Kevin Rose.

This was not the first time that someone has pointed out this phenomenon. On April 18 of this year Macgyver at ForeverGeek posted Digg Army, which included screenshots of who dugg two recent articles on the site. Each article had the exact same 16 people digging it in the exact same order. Of the first 19, 18 were the same. Included in that list of people was, again, Kevin Rose. ( for an in-depth history see Tony Hung’s excellent: A Brief History of the Digg Controversy)

These incidents, taken together, are more than coincidence…

Continue Reading: Digg’s Design Dilemma

Most books that claim to be about web design aren’t about web design at all. They’re about publishing in HTML and CSS, which by and large has little to do with the problems of the users we’re supposed to be designing for.

I was in a Barnes and Noble this weekend looking at web design books. There were lots of them! I saw old favorites like Eric Meyer’s O’Reilly books and new favorites like Dan Cederholm’s Bulletproof Web Design. I have a collection of these books, and my life has been made easier by them. I’m grateful for that.

But these aren’t really design books, per se. They’re more like books about web development, a similar and related field but not quite the same. They’re books about how to publish web sites in HTML and CSS. That’s publishing, not design…

Continue Reading: 99% of Web Design Books are Not

One of the integral parts of web design that isn’t as creative as the others is business: the money side of things. As a part-time freelancer and full-time web developer, I sometimes work on small parts of the overall project: wireframes, for example. Rarely does this include me in conversations about how the project will succeed moneywise. This is changing, however. I’m having more conversations every day about bottom-line results. Accountability may be coming soon to a project near you.

There is a tension between what designers can affect and what we have no control over. Because we can’t always change the ultimate success or failure of a project, we often dismiss the success or failure as completely outside the work we’ve done. I think this is a short-sighted, dangerous way to approach design…

Continue Reading: The Business of Web Design

In The Power of Positive Whining, Jeffrey Zeldman writes:

“If web design were not an art, then we would always get every part right. But it is an art, and, like all arts, it deals with the subjective. The subjective is something you can never get 100% right.”

I think Jeffrey is right: no designer can expect perfection in design. They can neither expect to create the perfect design nor expect to be able to know it if they did. And even if they did, somebody would hate it just because it was perfect.

Web Design

But web design is design after all, and as such we need to know when it works and when it doesn’t. If people use it, it works. If people don’t use it, it doesn’t work. Though people’s comments about it might be subjective: “I like it!” or “It’s ugly”, web design, like all design, succeeds or fails based objectively on how well people can use it. We may argue about metrics: (do 60% or 80% of people need to succeed in order to call it good design?) but we aren’t talking about someone’s subjective opinion…we’re talking about their actual behavior. That’s the beauty of behavior: it’s verifiable and objective.

Continue Reading: Self-expression in Web Design

People find things that work well endearing. That’s the secret.

When things work well, we see them in a new light. They become more attractive, more pleasurable, more desirable. Our opinion of them strengthens over time.

Our initial reaction, usually a superficial one based solely on looks, is vaporized upon use. If it doesn’t work well, then no matter how impressive your graphics are, it doesn’t matter. (think about all of the graphic design done for American-made cars). If it does work well, however, then we give it even more value than before, we attribute all sorts of things to it that we wouldn’t otherwise. We think it looks great. That its designers are nice people. That the site owners are credible. Etc. Our opinion of all attributes of a design skyrocket if we are happy using it.

In the graphic design classes I’ve taken they never told us that. It was all about directing the eye, communicating the product’s message, and showing priority. There was never any talk about how people related to the product we were designing the graphic for. Perhaps I’ve only taken bad graphic design classes, but this still seems to be the general feeling…that graphic design exists in a bubble outside of the success of the product and that people will appreciate graphic design as long as it looks good. Most people, however, don’t give a hoot about graphic design unless the thing works well…first.

So, as a graphic designer, make sure that you work on stuff that has the potential to work well! If it does work well your great-looking graphics will get much of the credit. And if your graphics help make it work even better (e.g. if you’re doing interface design), then you deserve the credit. But if you’re working on a project that just can’t work well because of an innate flaw in the product itself then you’re on a sinking ship. Say no to it, and stick to projects on which you can affect the outcome.

This secret is why it’s so important to get people using your software/product/service as fast as you can. If any part of it works, people’s perception of it changes and they’ll tell others. Design becomes social. And others, hearing what they say and knowing deep down we find things that work well endearing, are more likely to take the chance and use it themselves.

And then, after they like using the product, they’ll go back and notice how nice the graphics are.

Do we all love the Nike logo because it’s inherently a great logo or do we love it because we’ve had good experiences with Nike shoes? How about the FedEx logo? The Apple logo? Chanel No. 5?

Michael Bierut tackles this question in his great piece The Mysterious Power of Context over at Design Observer. He uses the example of how the word CHANEL is written in a very plain, sans-serif font that is quite boring on its own. But placed within the context of a Chanel bottle and our experiences with the perfume, the logo becomes powerful.

Bierut suggests that we love the logos only after we’ve become accustomed to them, saying that it is the context in which we engage the logos that matter. I think Bierut is exactly right, and so in the tradition of the Del.icio.us Lesson,, I’m going to have some fun and call this the Chanel No. 5 Lesson. The Chanel No. 5 Lesson is that we have to experience something before we have strong feelings about it: that experience precedes branding.

Continue Reading: The Chanel No. 5 Lesson

Designing for change is one of the new hurdles of designing for the network.

Back when print designers made up the majority of web designers, designs didn’t change after they were delivered. That’s because the practices of print design were carried over to the Web. Print designers are set on a project, they work through it, and deliver what becomes a final printed design. At this point, their work is done and they can go work for another client or on another project.

So some web sites created by print designers were set in stone, so to speak, and never touched again.

Time has shown, however, that the most successful web sites are the ones that constantly adapt to the needs of their audience. Today’s site is different than tomorrow’s. Chances are that the sites you use the most are ones that change on a regular basis. MySpace, Amazon, CNN, blogs, Boing Boing, etc. All of these sites are different every single day…or even every single hour!

It is still the case that interface designers (many of whom decended from print) are brought into a project, asked to create an interface, and then move on to something else.

I think that over time this will become less and less the norm. Designers will increasingly be part of the permanent design team, or perhaps hold an advisory role, simply because they need to be around to change their work over time. At the very least, they will have to create interfaces that can be easily modified by others who continue to work on the project after they leave.

That leaves designers with the problem of how to create interfaces that are adaptable to change, that can be modified when necessary, that don’t require another complete redesign to fix. That’s a big challenge going forward, and one that continues to creep into conversations I’m having with folks working on web apps.

Clay Shirky via Nat Torkington:

“We are literally encoding the principles of freedom of speech and freedom of expression in our tools.”

I hope he’s right. It sometimes feels like we should be, but aren’t.

Clay’s pattern library is interesting, too, following closely on the heels of the Yahoo Design Pattern Library.

The interesting difference between the pattern libraries is that Yahoo’s is a library of interface elements, while Clay and Co’s is made up of social elements modeled in an interface. Both really great tools for discussion/inspection.

Jon Udell thinks that XML formats will rule the day:

“There’s no doubt in my mind, however, that online forms will continue to transform our means of gathering information, that hypertextual XML will make page-oriented technologies such as PDF obsolete as a means of publishing it, and that blogs, wikis, and their successors will become our primary means of collaborating around shared information.”

Tim Bray agrees, but says that easy-to-use word processors are hard to make:

“I’ve used a lot of different programs over the years, and written some myself, and I’ve never seen software, designed for use by human authors, that has good usability and isn’t a great big honking monster. And usually, they’re not only big, but they take years and years to get working properly. So I really hope Jon’s right, but I’m not holding my breath.”

Jon responds by talking about user experience, but not in so many words:

“For a decade I’ve been pointing out the vast gulf between TEXTAREA and Word. Analysis of a representative corpus of business and web documents should enable us to define a target set of features, and scope the difficulty of the problem. In this case, the right thing to do with the long tail is chop it off. Most of us don’t need that stuff most of the time. We do quite desperately need a widget that does the five or six or eight things we all do all the time. And we need it to do those things in a way that’s standard across browsers and operating systems, produces valid XHTML, and is cleanly extensible. The W3C isn’t the right venue for this work, but something like the WHAT-WG might be.

Analyzing the right document corpus might also dispel some of the MSXML-vs.-OpenDocument fog. Goverments and citizens need technology that’s lightweight, ubiquitous, and good enough for everyday use. Defining what’s good enough for everyday use would be a great contribution to the debate.”

In the usability/user experience world this finding out what is good enough is known as field research. I think Jon’s right, we need some serious field research to see what people are actually doing, so we don’t smother them with features.

But we can’t get carried away and simply make Notepad on the Web (unless those features are what people actually use). Instead let’s shoot for the Einstein quip: “make things as simple as possible, but not simpler“.