Have you ever seen a website whose interface is ‘way out there’? Of course you have – there are many. Sites where, for better or worse, the designer has chosen to make her own path rather than follow a tried and tested design.
Individual design is a highly creative discipline; it forces the designer to think about every little detail, how those details fit together and how they combine as a whole. It allows the designer to express personality, demonstrate their technical and aesthetic capability, and challenge accepted norms. To be brief, it’s something of a clean sheet with all the possibilities that this brings.
Conformity is the contrasting approach; it’s more constrained, conforming to established rules, guidelines, accepted practice, you name it. It prescribes ways of doing things and in practice frees the designer from the tyranny of that ‘clean sheet’ which can be daunting.
Neither approach is ‘all-or-nothing’; the designer will find a balance that suits their own preference, experience and abilities, tempered by the requirements of the customer. We’d like to consider some benefits and drawbacks of either approach.
First of all, let’s consider conformity. The driving force behind conformity (in a software design context) is to take advantage of the hard-won experience of those who have gone before. Over time, a solid body of accepted practice has built up, shaped by the lessons learnt about what works and what doesn’t. There’s a good reason that things are the way they are.
In conventional software development, for example for Windows forms-based applications, a great deal of the hard-work is already done. There are standard form styles, controls, menu conventions, buttons and so on. A user, having never seen SomeCompany’s new ThingyApp tool, will at least be presented with something which has a basic familiarity. A conforming design will behave in much the same way as other applications. The minimise button will be where it always is; there will be a File menu, perhaps a tool-bar, et cetera.
What we as designers gain from this is a greater consistency with the ecosystem of other applications. We also benefit from the re-use of common components and frameworks, which are probably more stable and better tested than anything we could come up with ourselves, if truth be told. A common UI is, then, a starter-for-ten which enables us to concentrate on the functionality without getting bogged down too much in how we’re going to let you control that functionality.
The drawback to conformity is of course that everything tends towards… well, bleh. ‘Bleh?’ I hear you say? Unashamedly non-technical, it’s our instinctive reaction to the ordinary, the familiar, the taken-for-granted – dare I say it, the dull.
If you want to make a big impression with your software, it has to stand-out in a good way. Maybe this can be achieved by solving some hitherto difficult task, or by improving radically on something that already exists, or perhaps by doing things in a novel way.
Individual design tends towards this ‘doing things in a novel way’ approach. Rather than be constrained with the common UI, the designer can really go to town on a design. No longer bound by convention, then, the outcome is completely at the hands of the designer.
And this is where it typically falls down.
You see, many designers want to express their individuality into their designs. Especially in web development (whose actual content doesn’t have a common UI as such, beyond standard html controls and the typical page lifecycle). Flash has a lot to answer for here. Many potentially great website ideas have been compromised by the use of bad Flash design. Slow, confusing, overly graphical and exclusive (in the sense that they exclude people who might have no choice but to surf using assistive technology, for example the Jaws screen-reader).
The difficulty is that deviating from well-worn path of convention is a real risk to the usability and accessibility of a design. Whilst it’s possible that a designer might come up with something which improves upon convention, it’s far more likely that what is designed will fail. A radical design may well please a small proportion of its user-base, but by messing with the accepted norms, it will doubtless alienate or at best confuse a significant number of its users also.
So, where does this leave us? Well, the point of this article was to weigh up ‘individual’ versus ‘conforming’ designs, and the short answer is that we can’t really rule on either. After all, designs exist for a reason, and that reason is to facilitate the use of the thing for which the design was created. An individual design may well achieve this goal better than a conforming design – we can’t really judge this on a hypothetical basis. What we can do, however, is look at human nature and suggest that anything which challenges our understanding of how to interact with a system, or forces us to leave our ‘comfort zone’, is likely to require greater effort than a design which plays to our existing understanding and experience in interacting with a system. Where greater effort is required, we are more likely to make mistakes. With mistakes come frustration, and frustration quickly turns into dislike and abandonment.
The designer should bear all of this in mind before she departs from the ‘standard designs’, and have good reason for doing so. If she does take this route, then it places a far greater responsibility on her to ensure that her design works, and justifies its ‘individual’ nature. There are many techniques which might be used to do this – requirements prototyping being one of the best choices – but at the end of the day a radical design is a challenging proposition and carries increased risk.
We don’t like unnecessary risk. We can either mitigate it, with careful feedback using prototypes, or avoid it, by sticking to tried-and-tested ‘conforming’ designs. What we mustn’t do, however, is bury our heads in the sand and hope it all works out…
Designing interactive software systems is a fantastic opportunity not 
There is a school of thought which suggests that smaller teams are considerably more effective, per person, than larger ones. The theory goes that the overhead required to organise and manage a smaller team is proportionately lower than that of a larger team. As team numbers increase, in fact, this overhead appears to increase exponentially.
‘Free’ training simulations allow the user to try systems out without imposing structure on what they should do, or how they should do it. Whilst there may be context sensitive help or general guidance on training objectives, the user is left to their own devices to explore the system and make their own discoveries. In these ‘unguided’ simulations, as we aren’t focusing on workflow or operational tasks. We simply want the user to gain confidence in, and awareness of, the system and how to navigate within it.
Many great designs have succeeded because they kept things simple. Consider the Apple iPod: a music player like many others in functionality, but in essence a much more desirable gadget due to its great design. At least as far as the original iPod design was concerned, the engineers at Apple concentrated on how the device would be used rather than loading it up with niche features. The competition chose to stuff their competing devices with extra features which invariably got in the way.
