hyalineskies

One could argue that it is utility that separates design from art: art is, in most cases, the practise of creation for the sake of aesthetic enjoyment and expression; design rather, is more of a controlled practise of aesthetic to achieve a functional means. Design is the planned creation of a product, a tool for the improvement of the human condition. In many cases, the aesthetics of art intersect with design to some degree, as one can argue that this aesthetic improvement fits the marginal improvement condition above; however, design generally requires as its product some utility as well, as merely aesthetic improvements that appeal to our senses may simply be considered art.

Yesterday, I was reading a small article in Made with FontFont, one of FontShop’s type specimen books, about the design of FF Kievit, a rather unassuming sans-serif that the article author called “plain”. In the interview with Mike Abbink, the designer of FF Kievit, Abbink stated three conditions necessary for the utility of a typeface, assembling them into a three-dimensional matrix:

• identifiability, or unambiguity, the ease of identification of each glyph in the typeface. In this way, each character must be instantly identifiable to be read with ease.
• interoperability, or cohesiveness, the manner with which all of the glyphs work together to constitute a single, unified typeface.
• inclusiveness, or completeness, the extent to which a type family has all of the necessary components to set a wide range of text. For Kievit, this would mean the versatility or breadth of family to manage point sizes large and small, work on display or as body copy, in multiple weights and with a full array of glyphs as trivial as the ampersand or as obscure as the diesis. Kievit, Abbink said, was meant to fulfill all three of these as much as possible.

Extrapolating the utility matrix

The tools of building a functional typeface, I noticed, fit well into the design of web applications if the definitions are ported properly.

Identifiability, in the case of a web interface, is the easy recognition of interactive structures common to the web platform. Surprisingly, this rule does not seem as straightforward as it should: the diversity of style CSS affords us over common UI controls, such as input fields and buttons, as well as the wealth of hacked-up ways to mimic structures such as sliders and modal interfaces through DHTML, leave identifiability differing from web property to property. With Safari and Camino as notable exceptions, most browsers will render their common controls in any style the designer sees fit.

If we as application developers are working toward optimal functionality, identifiability means that we should keep our own controls looking like common interface controls seen in our operating systems to minimise the likelihood of user confusion. In any case where your site is viewed by more than the tech elite, you will probably confuse someone.

Identifiability also encompasses commonly-seen design patterns, as well. An identifiable website should have clearly-defined, standardised navigational structures, a simple visual workflow and common interaction schemes. For example, navigation bars should be consistent across pages; forms should be in a followable format, such that submit buttons exist and reset, where applicable, is markedly offset from the submit button. Radically changing your user interface structures across your site because “it looks cool” violates the rule of idenitifiability in its entirety. A recent example I have found of this violation is the site for worldwide venue Supperclub, where site navigation exists as a set of unmarked spheres that actually move away from you. (Sadly, most other nightclub sites don’t seem to do much better.)

After identifiability comes a related-yet-different rule of interoperability. While for Kievit this is the ability for each glyph to work together, in designing web applications it is the ability to mesh each piece of the application’s functionality both in terms of interface and overall aesthetic. Much of what we perceive as “clean” design appears to stem from this rule: Basecamp, 37signals’ popular project management application, fulfills this role well if not exactly. Each piece of Basecamp works solidly as a standalone application but also works seamlessly with the other pieces of the system, maintaining a common style both in terms of interface as well as aesthetic that feels neither redundant nor disjoint.

While the above rules are straightforward, it is completeness that makes the extrapolation of these rules to application design complex, becoming the complicating factor. Completeness and identifiability actually become negatively related after a certain point: as a web application grows in its versatility and functional power, its true abilities become much less discoverable; features that may potentially be useful to a user either becomes initially intimidating or is lost in a jungle of tabbed preference panes. The amount of completeness vs. identifiability tolerable to a user also varies greatly: hardcore geeks are not afraid of powerful-yet-undiscoverable interfaces (which users of vim surely understand,) while the common Internet user today is most likely impatient and/or easily confused. When judging completeness, then, a developer should base this relationship upon the target user: if you’re building Photoshop, the degree at which you can be tolerably complete is much greater than if you are building Picasa.

Gaining user insight

With the first two is relatively easy to nail down, how do we find the crossover point between interoperability and inclusiveness, especially when it varies from product to product and user to user? It’s possible to get an optimal answer using economic modeling, setting a constant utilitarian condition and then using statistical regression to get a “best fit” line through your users’ willingness to learn. (i.e., willingness to learn becomes the cost of using the more feature-packed interface, giving way to aggregate supply and demand (of features), from which an optimal intersection can be achieved.) As the existing aptitude or willingness to learn increases across the aggregate userbase, more features can be added for the sake of completeness. This model, however nice it is, generally relies upon more information than any lowly startup developer could ever hope to get; the model becomes utterly hellish to make statistically significant if your application’s audience is varied in demographic. Instead, we can gain some intuitive guess at the expectations of our users and our own expectations to achieve something reasonably useful while requiring very little math and a lot more emotion. For now, ask yourself only two questions to see where your web application’s purpose and user tolerability intersect:

1. What functionality is absolutely necessary in your application?

This seems like the most obvious question ever to ask, since you already know as a developer everything you want your application to do before you build it (or at least you should.) In many cases, however, we as developers seem to fool ourselves with our own visions of what our creations should become, and the end result is a disaster. Overthinking this question generally lends itself readily to feature bloat. Assuming the agility of most small development teams, most likely iterative developments over the course of building the application will inflate the application’s power slowly, which gives more reason to maintain a simple outlook on the application’s purpose at the beginning. Instead of thinking of all of the minutiae that have been running amok in your head for weeks, distill your idea to its core: really, in one sentence, without conjunctions, does your application do? Stray away from ephemeral buzzwords such as social, portal, community or folksonomy. Many of today’s successful web properties exist to solve one purpose at their core: what’s Twitter for? Twitter allows you to broadcast what you are doing. Flickr? Flickr allows you to show off and organise your photos. Gmail? It allows you to read and write email. Any functionality built on top of these core philosophies augments the experience but does not dictate its primary direction. In the case of Gmail, Google’s search prowess — another application entirely — benefits the e-mail experience but does not dilute it. This point in application design is also where I seem to think that most trendy Web 2.0 mashups fail: the end result of the mashup is not a useful intersection of two other applications; instead, it becomes a crowded union with a misguided purpose. With this question answered, we can then tackle the second problem we have in building our application.

2. Who is your user? No, really. Who is your user?

I think we should largely begin to abandon the idea of a target user during the initial stages of application development. The democracy of the Internet can easily cause your “targeting” to go wildly astray: look at the odd growth of social networks Bebo and Orkut in the United Kingdom and Brazil, respectively. From the outside, neither of these seemed anticipated. Unless you are deliberately restricting growth to a specific demographic, targeting is a challenge. While the distillation to something simple was key in Question One, this question, too, benefits from simplicity: what does your user want to use your application for? Using Twitter as an example again, people want to be able to broadcast what they do. A very limited amount may want to pinpoint the messages they broadcast to a few people. Even more probably want to filter the broadcast they receive. In mainstream situations, my observation is that the disparity of developer to user is huge: if my mom wanted to tell people what she was doing, the primary interface to do so can’t require multiple flags and a man page. Sparing more anecdotes, a philosophy emerges once again for designing most mainstream, Web-wide applications: most likely, completeness is simply solving the simple goal set out in the first question. Do one thing and do it well before adding any extra functionality. As you gain more insight into your actual users post-launch, you may find a freakish consistency in your userbase to optimise for. (You may also not reach such a condition, which isn’t a bad thing.)

Putting together the pieces

Of course, the KISS idea above is entirely wrong if you are building a vertical application, although it’s also good to keep in mind if you ever envision the application’s growth taking on more than just a vertical market. Things built for developers, such as Web analytics packages, require a much greater feature set and completeness becomes more of a goal than interoperability. In the case of a complete-first, feature-packed UI, the designer’s job becomes a compromise between building a complex UI and something that is manageable in terms of interoperability. (It’s also true that hybrid markets do exist. Microsoft Word is a good example of this; most of it users don’t demand the functionality the application actually has. Microsoft has attempted to battle this with the Ribbon interface, a little usability experiment that I personally like, but seems to have polarised most of the userbase.)

In the end, however, no matter how we feel toward the overall aesthetic or how we would use what we build, time and time again we stray from the primary usability concept of “you are not your users”. Unless we’re building something that exists solely to showcase our aesthetic talents, something more Web art than Web design, perhaps we should take a few points from those developing new forms for the static user interface humanity has had for roughly 6,000 years: if we haven’t perfected that by now, we’ve certainly got a long, long way to go on the Web.