Bricklaying and sculpting

Interface design is like building with bricks. It's especially like building with Lego-style bricks, which come in lots of varieties, but all snap together. You use components defined by the platform — buttons, sliders, pointers, and so on — and lay them out in a usable arrangement. Sometimes you begin with a layout grid that suggests or even defines locations where each component can "snap into place". 

The thing about building with Lego bricks is that no matter how impressive the thing you build, it's hard to think of it as anything more than a "clever assembly of Lego bricks". Interface design can be a bit like that too; if all you do is use standard components, it can feel (at least to you) like an "assembly" more than a new thing in itself. With interface design this impression is probably more common for the designer than for users.

Interface is also like sculpting. It's especially like sculpting with clay, using a method in which you add new clay as you proceed. You have a goal — usually a set of goals, in fact — and create controls, visual cues that inform users about what the controls are and how they're used, and combine them into a whole that (hopefully) is useful and attractive. 

There can be drawbacks to sculpting, too. Sculpting gives you an infinity of possibilities, out of which only a very few, or one, really works well. You're creating not just the end product, but all the component parts as well — the "bricks", so to speak. 

When you're designing a production interface you need a mix of bricklaying and sculpting. Preexisting components are helpful things; they save time in both design and implementation, they reduce bugs (because they've already been tested individually and in combination), and they're easy for users to recognize and use. But most software design projects need things that don't exist as system components, so you need to do some sculpting as well.

Some platforms have too many available components. Symbian is an example of this; for any given interface object there are likely to be several variations. Such a huge set of components is a result of accumulation; the original set was, I believe, a much smaller and more manageable set. But over time that accumulation also engendered changes in parameters, requirements, and implementation. If the existing list element wasn't quite what was needed, a new one was designed. It needed more or different parameters. Perhaps it depended on different display layouts. Since the first implementation maybe coding practices have changed, or the documentation format is different, or (most commonly) there are simply different people involved. 

The end result can be a mixed bag of "these components work this way, those work that way" and as the complete set of components grows it can become just as much effort to build an interface by "bricklaying" as "sculpting". 

The overall result is that there's no time left in the project for "sculpting." And that's a problem. 

Really effective software design — beautiful, original, usable design — usually takes a combination of "bricklaying" and "sculpting" approaches. Development organizations, which feature project managers, engineering estimates, and many different ways of measuring and quantifying things, naturally favor the bricklaying approach. It's more predictable, for one thing. And the organization (where the interface designer probably works) has a bias toward predictability. 

When the software platform you're working with has accumulated a vast number of components, and those components have over time become inconsistent in many small ways, the sculpture — the beauty — of interface design is lost simply because there's no longer time for it. 

And that's one of the fates that befell Symbian.