Code as a Building Material

A sculptor might use marble, clay or plaster. An architect might use brick, concrete and glass. As software designers, the material that we ultimately get to build with is code.

Since this is our building material, we ought to know what it is like. What its characteristics are. What is easy to do and was is hard.

One way to learn about code is to learn some and build something. Whilst I wouldn’t argue against this, I don’t think it is the only, or even the best way, to learn. For a start, there are many different languages and markups to choose from. Second, whichever type of code you choose to learn, you can only really scratch the surface as an amateur. Third – whilst some designers enjoy learning about and working with code, it isn’t for everyone.

Just as an Architect doesn’t have to learn to lay bricks, I don’t think a designer has to code. However, we do need to learn what code is about – what its properties are. This article is a brief discussion of some of those properties.


At the UI level, code is not infinitely flexible, like clay (at least not at a cost-effective level). But it is also not entirely modular, like lego. Rather it is a set of modular elements suspended in a flexible matrix of layout and content.

We can see a metaphor for this in the construction of a house:

Some elements of the design of a house are quite flexible. You can change the overall size of the house, the sizes of the rooms and their layout reasonably easily. This is because it is easy to build brick walls to match the design. Things will only become more complex and expensive if you want to build curved walls, or unusual shapes.

Other elements of the house are less flexible, although they still allow a good degree of configurability. For example, windows are typically ordered from a specialist company. You specify the sizes of the window apertures and they build the windows to fit. However, you have to choose from a limited selection of window types – you can’t just design the window frames and latches the way you want, unless you are prepared to pay a lot more money for someone to build them specially.

There are also parts that are entirely modular, with little or no option for special configuration. Take the bathroom, for instance. You can choose the bath, toilet, sink and taps from many different providers, so the possibilities to be creative are large. You can choose how to arrange them in the room (the plumbing itself – the pipework and drainage are highly flexible). However, you can’t modify the fixtures and fittings themselves. And getting someone to manufacture your own special design of tap or toilet would be extremely expensive.

We can analyse UI as being made up of the following five elements:

  • Layout – methods to control the placement of content and controls and manage their resizing and responsiveness.
  • Content – text blocks, images, charts etc.
  • Controls – drop downs, menus, checkboxes, input boxes etc.
  • Transitions – more recently, technologies have started to support the use of complex visual transitions.
  • Interactions – hyperlinks, gestures, drag & drop etc. that allow the user to interact with the software.

Layout and content are the most flexible elements of the UI. They are the two elements that allow websites to look and feel so different from each other. The page can be divided up in many different ways, with little cost. And graphic elements can be used to give a unique visual appearance.

Controls are much more modular. Each one provides a specific set of capabilities and configuration options. For example, you can define the set of choices that you want to appear in a drop down and you can also use CSS to apply a degree of styling. However, they also have discrete limits. Going beyond those limits, or building a new custom control is vastly more expensive than using the basic capabilities.

Transitions and interactions are typically quite fixed – you can choose from the set of possibilities provided by the underlying technology, but going beyond these is very tricky. Even using drag & drop is hard in HTML, as the support for it has been poor. Creating your own custom gestures would be extremely expensive.


Libraries extend the basic set of controls that a technology offers – they are the equivalent of additional catalogs of fixtures and fittings to choose from for your home. One of the benefits of HTML and Javascript is the sheer number of libraries that are available.

Just as with controls, they offer a specific set of capabilities and configuration that you can make use of, but with discrete limits. Some libraries may be more or less open to being extended, but any such extension would be a significant investment.


Designers need to understand these basic characteristics, in order to communicate more effectively with development and so that they can make better choices about the designs that they propose.

Resources are always limited in development projects, so it is better to work with the technology as much as possible, rather than against it. Ask development what the technology provides out-of-the-box and what would require more investment.

Take a phased approach: Work within the limits of the code first, and then extend later. Choose which parts of the product are important enough to invest in custom elements and focus on those.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s