silent design
On the web content is king and design is queen, we are also taught that design should always support the content we deliver. That is all very nice (and true), but it is important to realize there is more to the web than just simple content. There are situations where design deserves a more prominent mention. Before continuing, please note that I'm not a graphical designer, so this article stems from my experiences as a normal web consumer.
prologue: living in a small European country
Being a front-end developer, there are a few advantages to living in a small European country (in my case, Belgium). Europe is a pretty big place, housing many different nationalities, cultures and most importantly, a whole lot of different languages. In Belgium (population 10 million) alone we have three different official languages. This has a big impact on our job as most sites we build need to be multilingual by default, sometimes covering up to five languages for one single site (English and Spanish are not official languages here but are still important if you want a site to have international appeal).
Having to deal with a multilingual site is a pretty interesting experience. You usually develop a site in one single language, when its finished you check how the other languages behave in the design. This often brings about all kinds of spacing and alignment issues that won't necessarily show up on single-language sites. Even more problems and issues you may think (and you're definitely right about that), but it also helps you to build more flexible layouts and designs, foreseeing variable content for almost every component you design. Something which is useful in later design iterations and/or reworks.
There are also some obvious disadvantages to living in such a small country though. Last week I wanted to order an item from Amazon, something I needed rather quickly. There is no local Amazon store here so I had to look outside the Belgian borders. The nearest Amazon store is in Germany, sadly my German skills are pretty bad. Still, rather confident that I was comfortable with the Amazon design and flow I tried to maneuver my way through the site based on recollection and graphical input alone. To be honest, I was very disappointed with the whole experience.
doing it right
This little experience got me thinking as I compared the Amazon checkout wizard with other stores I often like to visit (take play.com). Even though this site is not multilingual, it's not too difficult to imagine the play.com checkout wizard in a different language. A totally different experience where language wouldn't prove to be such a big hurdle at all.
The biggest difference between the two wizards lies with their visual (functional) design. The play.com wizard is designed as such that the advance buttons are where you'd expect them to be. Cancel buttons look like cancel actions, buy and confirm buttons emit a definite "go ahead" feeling. Through the use of arrows, size, position and color the function of a particular button becomes almost immediately obvious. You don't even have to move your mouse pointer to cycle through the individual steps of the wizard. If your design functions like a guide the text labels become secondary information, simply there to verify your visitor's assumptions the first time he uses the wizard.
The Amazon wizard is a lot messier and forces you to read the labels to understand the action of a button or link. This makes the interface less intuitive even when you perfectly understand the language used on the site. When you can't understand the language, you're left to switching between Babelfish and the application, hoping the translation is somewhat accurate.
testing your designs
These days it's not unusual to set up a user test for a proposed design. These are not the most straight-forward tests to perform but on the whole they will tell you something about how your users perceive the design you want to use. An interesting variation on these tests would be to perform such a test based on design alone, stripping all descriptive labels and content. You can test specific user flows and measure how far the design will take the user in a flow purely based on the feedback a design is giving.
The web is not just about content, it's also about flow and actions. Guide your users from start to finish and make that journey as easy as possible. When considering flow, you could argue that functional design is king and content is queen. Labels are nice, but if a user can be guided by design alone the interface will feel a lot more intuitive to them. Testing a design for just that is still somewhat of a novelty but could prove very valuable in the future.
conclusion
The past few years applications have gained quite a lot of territory on the web, content is getting a big competitor in the form of flow and actions. We're not just browsing the web for information anymore but we're also looking to perform actions and tasks. Design isn't just a secondary worry or simple eye candy, but should be taken into account, especially when talking about functional design and how it influences the way a user performs a specific task.
As our job becomes more and more professional, more elements of our job will require user testing. When testing for functional flow designs, text and copy are not as important and could ( even should) be removed from the equation to reach maximum result.