Prototype Theory & Design Convention
There’s an old rule in interface design that you should stick to conventions, not try to re-invent the wheel, and design UI controls and features in the way people would expect them. This guideline is at the heart of many debates in the design world when new UI features start getting used more frequently (for example the hamburger icon as a menu reveal button). The reasons for following the rule (or for breaking it) are usually couched in pretty general, non specific language, but there are actually very good scientific reasons for following the rule.
The prototype theory of categorization and concept formation was developed in the 1970s by Eleanor Rosch and other cognitive scientists, and still holds today as a fairly accurate description of one of the primary ways our minds categories things out there in the world. Prototype theory denies that we form categories of things (for example types of animals) by storing lists of rules for determining whether a category applies to some new thing we experience (for example ‘is feathered’, ‘has wings’, ‘flies in the air’). When we are asked to describe how we know something is a bird, we likely will list off a bunch of rules, or necessary conditions like this, but this is just a sort of after the fact rationalization, or a higher level cognitive abstraction that sits on top of a more foundational mechanism.
In essence, every time we experience something in the world, our minds extract statistical information about certain dimensions, or features, of that thing. As we experience more and more things that are fairly similar in terms of these dimensions, a kind of average, or ‘prototype’ version of these things is gradually formed, and stored in the brain. So for example, when we experience birds, we will unconsciously be extracting statistical information about the size and movement of the wings, the length of the legs, the shape of the mouth/beak, and so on. The more birds we experience, the more we build up a solid representation of the prototypical bird, which is the constantly updating average of all of these statistical relationships from all the birds we have previously experienced. Rosch and others showed that people can easily give a degree of typicality for members of a category, so for example a Sparrow is a far more typical bird than an Ostrich or a Penguin. Under Prototype theory this is exactly what you would expect, since far more birds — or rather, far more of our experiences with birds — are more similar to a Sparrow, when described statistically, the with an Ostrich or Penguin. This is in terms of shape, size, ratio of different body parts, movement style, typical behaviors and so on. In fact all three are just as equally members of the category ‘bird’ if described in terms of necessary conditions, or determined biologically, but that is not the way our minds work in this more fundamental way of categorizing, and forming concepts.
It is probably clear to you now how this relates to interface design (both in software and hardware). We learn what different UI controls and features are over our total experiences with different instances of each type of control, and we will extract statistical information about them based on their size, shape, behavior and so on. The more we experience a certain kind of control, the more solid our prototypical representation of that control will become. So the more we experience software buttons, the more solid the ‘average button’ is that we have stored in our brain. This prototypical button will have a specific statistical description (not that we can ever access it directly), in terms of its size, shape, perhaps color, perhaps apparent three dimensionality and so on. Every new button that we experience will be immediately categorized by our minds not only as ‘button’ or ‘not button’, but also in a way as having a degree of ‘buttonhood’. The more buttonhood some new UI control that we experience has, the more likely we are to immediately expect it to be, and treat it as a button.
You can also understand now how conflicts can arise — especially in the case of more minimal software UI, where different types of controls appear to be quite similar (especially when described purely in terms of available statistical information). The more similar the prototypes of two different categories of things become, the more frequently instances of each will be confused with one another. This is likely at the root of many of the design problems with more extreme minimal, flat UI — for example many design features of the newer iOS versions with far more purely text and icon based UI components. The statistical information available for our minds to use to distinguish between a scrollable numerical input field, a tappable expandable content section and just some plain text in a mobile app can be so slight, that the prototypical version of each of these things overlaps to a troublesome degree, resulting in many mis-categorizations.
Understanding this basic feature of how our minds work can help us adhere to more clear and obvious design patterns and ways of designing important UI controls. Of course designing only in accordance with what we think the average version of a certain bit of UI might be would result in everyone designing things that look almost exactly the same, and does not allow for any of the wonderful UI revolutions (think iPod wheel UI) that typify great design. I will write future posts on how best to approach designing a new type of UI control that defies convention, but there are some insights that prototype theory can shed on this too. If you want to make design changes to a product, perhaps it is best to do so gradually, and in a stepped approach. It isn’t always possible to do this, but if you can think of a few in-between steps between a current UI design, and the quite different one you want in the future, then people might adjust better to multiple, smaller changes which allow their prototypes to update swiftly and easily.
If you want to find out about more articles from me, and updates about a book about cognitive science and design I am writing, then sign up to my newsletter! http://eepurl.com/biojpj
Originally published at iaminterface.com on September 29, 2017.
