Barrier To Entry

It is not often that one knows with certainty that on a certain subject one is the world’s number one expert, but that's exactly what happened to me a while ago.

I was looking at a profile of a company I have designed the logo for on Wikipedia. The logo rendition in the profile was a low fidelity approximation of the logo, uploaded by a user. I set out to upload the correct version. After all, this was the one thing I knew better than anyone else! Having edited Wikipedia a bit before, I was surprised at the long time it took me to figure out uploading images. Understanding where they were uploaded to was not trivial either and forced me to do some reading. Then, to my surprise, because I marked it as a copyrighted logo (which it was), I got a removal notice from an administrator. It took a couple of attempts, help from a Wikipedia wiz in our office and some inter-user communications to get the official logo up. This by a user not new to Wiki editing, pretty computer literate and, though not a lawyer (sorry, Grandma), with above average understanding of copyright law.

This is a issue we encounter with many computer based systems. They require us to learn the system instead of focusing on what we’re good at. A 72 year old biologist may be the top expert on gas exchange in vertebrate embryos and have computer experience dating back to the sixties, yet the level of expertise that correcting Wikipedia entry requires may prove to be a barrier to entry, leaving errors entered by someone with great understanding of wiki editing, but little biology knowledge, in tact. This doesn’t mean that it is not important to know the mechanics of what it is you do – a web designer benefits from knowledge of HTML and CSS just as a musician benefits from understanding MIDI interfaces or a driver from understanding how the car works– but the tools should be a jumping board and not a hurdle. You'll often hear Linux users mocking Mac users for having had decisions made for them; “The computer controls you, when it should be the other way around”. But when your goal is creating music, designing or typing an e-mail – that is exactly what you want to do – you don't necessarily want to have to write command lines or program your own interface. You are passionate about what you use your tool for, not about the tool itself and willing to give away some control for that comfort. Apple’s iPod is an example of product, in some respects inferior to products already existing in the marketplace, that defined what a digital music player is today – by focusing on users’ actual needs instead of the product’s features.

I've seen organizations forcing tools upon employees, making their work harder and less streamlined as they were designed to support the ‘system’, not the employees needs. Usually, it lead to frustration and tools were either neglected or people kept using them because they had to – as a bureaucratic burden pleasing a manager, not an aid.

Software is most powerful when it allows users to control the balance of comfort and control and facilitates transition from one to the other based on a users own needs and pace. Designers as well as marketers must strive to understand users’ needs, mindset and level of expertise in order to create great products.