Function Follows Form

It’s customary to pull out the classic “form follows function” when discussing simplicity. It’s a simple and powerful idea. By the virtue of using generic terms, it applies to many things; it even rolls of the tongue nicely and alliterates.

However, the idea that designs should be informed by the functionality seems like an artifact of designing tangible, commercial products rather than designing products for the digital world where interfaces aren’t as limited.

When you are trying to design something that is going to be used manually by someone, you really want your tool to be designed with the functionality in mind; you really want to get out of the user’s way when they are drilling that hole or brushing their teeth.

However, when you are designing, say a web product, things are a bit different. Dealing with users who have a pointer device that can go anywhere on a screen, be it their mouse or their finger, is a different beast than designing a material object. The amount of freedom you have can be both exhilaratingly awesome or paralyzingly scary.

Of course there are tools that help you there, such as generic user interface conventions; for the most part people who use your interface on their computers know they can only click things that look a certain way or enter text in fields where a bar is blinking.

Still, as a designer, you really have a great deal of control on how your users will be using your product, or if at all. This definitely goes beyond thinking how things are going to look, which is definitely important, but how they are going to appear (or not appear or appear in a certain way) within the context of your entire application.

For example, you will probably get users to write longer pieces of text if your text fields grow as they get filled instead of showing a scrollbar, or get people to “remove” less items (or only remove the things they really want to hide) if you show the remove icon on hover (which also has to do with removing clutter).

But this idea even has bigger implications and requires you to be careful about things like your copy as a designer. In one of my projects, the biggest issue in this huge application that was designed for senior citizens and was costing thousands of dollars was that users didn’t know what “Press Here” meant. And similarly, another big issue was that users were thrown off by a screen that simply says “Please Wait”. As extreme as these examples might be, which they are; they illustrate the point that how you design your product has huge consequences.

In essence, this notion has entered the common knowledge with things like A/B testing, usability research and to one extreme, eye-tracking studies but the point I am trying to convey across is that how things are going to work has a lot to do with how they are formed, or designed.

All in all, I will end this unnecessarily long piece with an example of how I have been fascinated by function following the form. I grew up around cars as a kid, due to my dad’s job (no, he wasn’t a sketchy car dealer). I remember looking at a relatively old car’s engine; it was one of those old cars where instead of the whole engine block being covered with plastic, all the parts were exposed. I remember asking my dad how he knew where to put oil and stuff in. And I remember him telling me about how the only user accessible parts were the ones in yellow; all other knobs and lids and caps were not meant for the end user.

There’s one design language for you.