“Form follows function” – that’s what we were always taught at design-school. Yet is that actually true? I wonder…
There was nothing in particular that triggered this one off: it was just one of those ‘first thing in the morning’ things, together with revisiting a previous post of mine, ‘Architecture is non-functional‘, and thinking about a couple of slides that need to go into my upcoming EA training-course about the old requirements-model distinctions between ‘functional’ versus ‘non-functional’.
The classic assertion is this: that the function that a device or system or whatever is intended to perform, should guide the design, and the design in turn should reflect the function – hence the assertion that form follows function. A bicycle should look like a bicycle, something that rolls on two wheels along a road; a cigarette-lighter (okay, old-fashioned example, I know) should look like something that would light a cigarette; a phone should look like a phone; and so on. Hence, again, the user-interface for an IT-based application on screen or handheld should be kind of self-explanatory, easing the user-experience.
All well and good: yet what is it that determines the function?
Let’s take an everyday example – the humble, ubiquitous ‘hole-in-the-wall’ ATM:
If form follows function, then what actually is the function here? The quick summary is that it’s not just one function, but a suite of easily-automatable bank-teller transactions – hence ATM, Automatic Teller Machine. There are obvious bank-oriented functions:
- enquire bank-account balance
- provide cash in standardised bill/note amounts (combinations of £10 and £20 notes, in this specific case)
- enquire credit-card balance
- pay credit-card balance by funds-transfer
And it supports a few other transactions on behalf of partners:
- donate to charity or charitable-appeal, as selected from a predefined list
- add phone-credit to a partner phone-service provider, by funds-transfer
There are also some maintenance functions which, of course, ordinary customers don’t and shouldn’t see.
That’s about it, really: all fairly straightforward.
To support those functions, we’re going to need the following:
- some form of display to the customer – in this case, the screen, and also a small thermal-printer for receipts (and maybe also a larger printer for bank-statements, in this case, with an output-slot visible as a long dark line above the screen)
- some secure means to identify the customer – in this case, a reader for a pin-and-chip card, and a keypad to enter a matching PIN
- some means to obtain command-input from the customer – in this case, that same keypad, plus the buttons either side of the screen
- some secure means to dispense bills/notes to customers
Again, there’s also some other less-obvious or intentionally-hidden support-functionality:
- built-in lighting, to make the unit usable at night in street-accessible conditions
- loudspeaker, for audio-feedback for blind customers or real-time customer-service help, and also for security-alarm
- status-lights to indicate which input and/or output slots are active (visible in this case as as a short dark line above each of the respective slots)
- security-camera to capture customer’s face when using the system
- logging-printer for bank audit-purposes
- reloadable safe, to secure bills/notes, separate from yet associated with the cash-dispenser
- network connections
So, what form should all of this take?
If form follows function, then every ATM should look exactly the same, pretty much without any variation.
Which is sort-of true – but only ‘sort-of’, because in practice just about every bank seems to have a different layout:
- some have touchscreens (this one doesn’t)
- some put the keypad beside the screen (rather than in front, as in this case), or under the card-reader
- there’s quite often (as here) more than one keypad, though sometimes none at all
- the customer-identification card-reader or equivalent can again be just about anywhere, with quite a few variations of form and slot-configuration, and occasionally use other forms of machine-readable ID such as Bluetooth-tag or RFID-tag or even an iris-reader
- the customer-output printer(s), if present, can be just about anywhere
- the cash-dispenser can be just about anywhere
The function itself doesn’t tell us all that much about where these things have to go, and their physical relationships with each other.
Instead, it’s so-called non-functionals – often practical human concerns, and/or security concerns – that determine most about those physical relationships. Which, in turn, are well-illustrated in this case:
- this system uses a card-reader, which is placed to the right of the screen because most people are right-handed and will ‘naturally’ hold the card in the right hand
- the main user-interface – screen, keypads etc – is inset relative to the overall frame, because the customer’s body itself provides some measure of physical- and visual-security, such as against others seeing what is on the screen or entered on the keypad
- the cash-dispenser slot is inset on the left-hand side, to minimise the risk of snatch-attack whilst the notes/bills are exposed
- the cash-dispenser slot is horizontal and below the screen, because that configuration provides the best trade-offs for mounting, loading and securing a reloadable-safe, compatibility with typical paper-feed mechanisms, and not clashing with placement of other components
- the display is of a particular size, because it needs to be read at a known distance by people with varying acuities of vision
- the keys on the keypad(s) are of a particular size, because they need to be used by people with varying sizes of fingers, with minimum risk of data-entry errors
- the unit as a whole has a particular appearance and ‘feel’, because it has to line up with corporate branding and, often, unstated non-functionals such as implied by Conway’s Law
The most common variations on form and layout are with components where the non-functionals are not so critical, such as for the receipt-printer – it’s perhaps most often in the position shown in this example, above the card-reader, but I’ve seen it placed just about anywhere, relative to other components. And the internal components that drive all of this functionality, of course, can go just about anywhere that fits – subject to other non-functionals, such as temperature-management, inter-component interference, and accessibility for maintenance.
When we look at the unit as a whole, the same point applies. From a pure functional perspective, the physical position and mounting of the unit makes no difference at all: we could put it just about anywhere, as long as it can do its job, its function. It’s the non-functionals that ultimately determine exactly where it goes – such as:
- market relevance – it needs to be somewhere that people will use it, sufficient to justify the cost of installing and operating it
- physical security – it needs to be located and mounted such that criminals cannot steal the entire unit
- accessibility – it needs to be at an appropriate height, and with appropriate access, visibility and security, such that people can actually use it
That last point is particularly relevant in this case, as the unit is mounted unusually low on the wall, for use at wheelchair-accessible height:
Pedestrians can still use it, though it’s somewhat awkward:
Put together, the non-functionals in effect determine the minimum viable shape, size and weight of the unit, and probably much if not most of its physical appearance and means and modes of operation. Sure, there’s function there – otherwise there’d be no point (other than as a piece of street-art, perhaps?). But in terms of overall form, the form doesn’t follow the function: form follows non-function.
The real problem, of course, is that ‘non-functional’ is a highly-misleading term: so-called ‘non-functional’ requirements such as usability, security, reliability, durability and accessibility all combine to determine a great deal of what we see on the surface as ‘function’.
Which, in turn, does give one somewhat flimsy excuse for the ‘form follows function’ motif, because much of the form does in practice depend on the subsidiary functionality required to satisfy the ‘non-functionals’. But it is a flimsy excuse – not enough to justify the usual claims made for ‘form follows function’.
And there’s another simple counter-argument, anyway: in reality, ‘form follows function’ is itself an example of form following a ‘non-functional’, in this case an arbitrary requirement that form ‘should’ follow function. Whatever that is…
The closest we really get to ‘form follows function’ is that yes, it does help if the surface form and user-interface (in the broadest sense of that term) provide or underpin a user-experience in which the item’s function and usage is seemingly ‘self-evident’. There’s a lot of work that goes into creating that sense of ‘self-evident-ness’, as any user-interface designer, user-experience designer or service-designer would attest. And that applies to just about everything: from bridges to buildings, from cars to kitchen-utensils, from software-architecture to enterprise-architecture, or whatever, the so-called ‘non-functionals’ are more critical than the ‘functionals’, for the form and effective function – the user-experience – of that design.
Again, no particular point that I’m making here: just seemed worth saying, that all.
Over to you for comment, anyway, if you wish?