“The detail IS the design”
Charles Eames
It’s quite funny to see the number of terms used to describe roles for people who are programming for the web; “interface architects” , “usability engineers” and now “UX designers”. To me it conveys a sense of confusion around principles of programming for the web, coupled with a need to real-world the roles by adding the terms “architect”, “engineer” or “designer” to an element of the program creation. The truth is that most people who venture into programming for the web do not fit into any of these disciplines entirely, or in some cases not at all.
To me, It’s a hangover from when sociopath programmers, who had a pretty poor eye for aesthetics, dressed like mathematicians, were pushed aside by graphic designers in the push for a prettier Internet experience. Notice I said prettier, not nicer or better.
People who create web pages are programmers, not designers, or architects, or engineers or anything else for that matter. When they create content for the web, they are involved in creating a program, a program that someone else uses. They ‘have’ users.
Yes, many other, probably much more experienced programmers wrote say 99% of the code that delivers the web page to the users eyes, but the 1% of programming that is involved in creating the content is actually what the whole Internet is built upon.
When we bring other disciplines into the language, what do we gain? Nothing, but confusing analogies and abstractions. Programming is a big and mature enough discipline to handle all of the tasks it needs to perform without having to borrow from other disciplines. Actually, borrowing from those other disciplines only harms the output. Web pages are not buildings, they are not leaflets, they are not machines, they are programs, run on computers. Google’s homepage is a great example of program led design, that did not care for architecture, design or usability even. It was something that grew from the program they wrote to search the internet. It’s success has been phenomenal, but not because it was well designed, aesthetically pleasing or even well thought through (the design). It came about because the program needed an input. Simple.
It’s hard to program for success, even before you get into aesthetics. There are many factors, many environments, many pitfalls; layering complexity over complexity in programming can lead to large cumbersome systems, prone to failure. Visual design is a complexity, an often unnecessary one .
Adding design elements, new visual languages, pleasing layouts, mechanical functionality for the sake of it actually harms what we need from the web. What we need from the web is transparency, fluidity and most of all efficiency. Design just gets in the way.
Efficiency is not pretty, its functional. It’s pleasing. It delivers a result in a simple and concise way, again and again, on a large scale without failure or confusion – It works. I was reading some usability materials recently and it struck me that while focussing on usability can save you money, it actually can’t make you money. Quite a bold assertion, but usability only matters if you have a product that works.
A designer is creative, they create designs. They do so from a singular
subjective viewpoint, maybe with consideration, but it’s still a subjective consideration. Subjectivity is an opinion and opinions are easy to come by. This is the crux of the problem. Using the principles of design to solve what is essentially a programmatical problem causes two big issues; it creates a paradox for the user and unneccesary abstractions (and distractions) for the programmer.
Programmers do not have the same luxurious subjectivity as designers. The output for a programmer is binary; it either works, or it doesn’t. There are programming styles, of course and elements to designing a program, but largely these elements are part of a task to be completed.
- Charles Eames Design Process