A job by any other name

When people ask what I do, I always have to pause and work out how to explain my role.

The first hesitation I feel is: “If I tell this person I am a programmer, do I have time for them to tell me their idea for an App or website?”.

Maybe I should simplify it, but if I say I work with computers, are they going to ask me to fix their computer?

I’ve tried many titles: Software Developer, Software Engineer, Programmer, Coder. But still they don’t aptly describe my role.

My job is to write code; what I do is build experiences. I’m an experience engineer. It’s not always an easy concept for people to grasp though, because to do my job well means you don’t notice my work. It’s easy to joke about. And it turns out a joke is the perfect metaphor:

Did you hear the one about the spaceship that was powered by bad news?

It traveled faster than light, but it was always unwelcome before it arrived.

Building an experience is about answering questions the users shouldn’t have to ask, “Where is the menu?”, “Why didn’t anything happen when I clicked that button?”, “Did they actually receive my order?”, and the big ones: “Where am I?” and “What do I do next?”. These are all questions we are familiar with, and all completely unnecessary.

When a user is asking these questions, they are having to think about something other than the focus of their visit. Thinking about anything other than the reason they have visited your site is detracting from their experience. Users only have a fixed amount of focus, and as soon as they are asking questions, it’s detracting from their focus on your message.

I have heard the example of specifying a house-build used as a comparison for specifying a website-build; there are so many, many variations for building a website experience that if you were to specify a house how you should specify a website you would even need to say, “Doors should be attached on one side with hinges and open in one direction, controlled by a handle which will be on the opening side, at a specified distance from the floor…”

However, this interior/online comparison is also useful when considering user experience. If people in your art gallery are distracted by lighting at the wrong height, or are avoiding your shop because they can’t work out how to get in, then their user experience has failed. No-one stood in their shoes and wondered how they would see things, and designed accordingly.

This is also why we have design principles and standard patterns. Anti-clockwise clocks are fun, but they’re annoying. Appliances with hidden controls look cool but can be embarrassing. We have little tolerance for such things and with good reason – there’s an accepted standard and any variation from that is just tinkering for the sake of it. The engineering questions have already been asked and we have perfectly good solutions. The same applies for navigation, contact pages, expanding menus, video controls…no-one will thank you for trying to be too clever!

Of course, there are times for innovation, but I’m a strong believer that this is best when it evolves naturally: in the process of an on-going commitment to the perfect digital experience, as we adapt to new technologies and as a result of research and feedback, we will iterate neater solutions and more intuitive controls. This both means we don’t leave users behind, and we don’t waste time (or code) on novelties.

So my job is to build the most perfect spaceship for the people who want it. But it should be a spaceship that nobody notices.

back to blog

Building a brand?

Learn about brand diagnostics