Different Context, Different Design
In The Most Frustrating Thing, Matt Mullenweg, who helped create the Wordpress software that runs this site, is frustrated about our geeky fascination with technology and design. So frustrated, in fact, that he claims they don’t matter…
In The Most Frustrating Thing, Matt Mullenweg, who helped create the WordPress software that runs this site, is frustrated about our geeky fascination with technology and design. So frustrated, in fact, that he claims they don’t matter:
“Technology doesnâ€™t matter. Design doesnâ€™t matter.”
Later, he refines:
“Of course design matters. Technology matters. But they have no causal relationship with success any more than the color of a logo does. Donâ€™t focus on the wrong thing!” (my emphasis)
Mullenweg’s point, which is a good one, is that most of what we know about design and technology is generalized to the point that we can’t be successful without something else. We know that something needs to be usable, but what exactly does that mean in relationship to our product? We know that contrast is important in design, but how much and when and how? We know that we should write in the user’s language, but what exactly does that mean?
These principles of design are important, but only in the sense that we know what we must manipulate for success. The design itself will determine how we manipulate them. How we manipulate the principles determines whether or not people use the design. The best we can say is something like: “contrast helps us deliver a clearer message”…we don’t know how much contrast will be necessary until we examine the message, or the actual screen where we deliver our message. We know that contrast is important, that’s been generalized very well, but that’s all we know until we start getting into the nitty gritty details of our unique project.
The problem is that each design project, and the people who use them, live in their own context, and therefore have their own solutions. My design solution won’t work for your project, just as well as your design solution won’t work for mine. Our projects are different, our users are different, and their worlds are different.
Mullenweg suggests we focus on something else…something he can’t quite articulate:
“I canâ€™t tell you what you should be focusing on, no one can. I can only tell you it is not design or technology. Itâ€™s different for every company, service, and person.”
I disagree with Matt that what we should focus on isn’t design. In fact, I think that’s exactly what we should be focusing on…how our design helps people lead better lives.
I think we need to make a distinction between the activity of visual design (using principles of perception to make something more clear) and the activity of strategic design (deciding what we’re creating in the first place). This is a crucial distinction to make because it separates what many of us think of design (communicating a message) from the actual decision of deciding what message to communicate.
I’m arguing that the common notion of design (communicating a message) is only half the battle. The other half is just as, if not more, important to the design: deciding which message to communicate in the first place. In other words, the what as opposed to the how.
Generalizing is often about the how. How to communicate messages more clearly. How to publish on the Web. How to make a button look clickable. These are all design practices. But there is also the process of coming up with the message in the first place…the function on which we apply the form.
Many folks don’t agree with the notion that functionality is part of design. I’ve argued, and am still 100% convinced, that functionality is the soul of design. The decisions about what functionality to offer our users is as crucial as the clarity of presentation.
Consider, for example, taking away the functionality of a chair. Taking away the decision that we’re providing a place to put someone’s rear-end so that they can give their feet a rest. Is it still a chair? No, not in any functional sense. (In an artistic sense, maybe)
Yet, dozens of industrial designers create new chair designs each and every day. But they all do the same thing…because everyone knows what a chair needs to do in order to be considered a chair. It is such an obvious decision made by the designer that we tend to forget that it is being made at all. We gloss over it as if it isn’t being made each and every time a designer begins a new chair. But without that decision, without the decision that there needs to be a relatively horizontal part of this thing that serves as a place to rest the butt, we wouldn’t have a chair, and the designer would have failed. In other words, the soul of the design (the ability to sit on this thing) is decided upon by each and every designer who approaches the problem…and without that decision the design is something else. This decision has little to do with technology and little to do with visual design. It’s a design decision about what the thing does.
When it comes to the Web, we have few clear cases of functionality like we do with a chair. That’s because the Web is so new, while we’ve had chairs for millenia. We are coming up with certain conventions, however.
So I think Matt is correct, whatever problem you’re solving for people probably has a unique solution outside of the realm of technology and visual design. But I think the answer lies within the design process. It’s all about the functionality of what you provide…and over time markets will sprout up to commodify them. The functionality of a chair is commodified…we know what functionality they need to work. But in the software world we are only just begun.
Currently working on: