Working closely with the Creative team, as I do, I have the unique opportunity to consider user experience through the life of the project. More than many engineers, I work directly with the user. Developing wireframes, considering information architecture and user experience development all fall within my purview.

Typical engineers, on the other hand, live in a world separated and buffered from Creative and, subsequently, the user. They work with project managers, engineering supervisors and other layers of businesspeople that speak on behalf of the user, alienating the engineer from the world they affect.

It becomes easy to dissociate and refer to the user as clients and eventually abstract the interaction by focusing on the system and the software client that will interact with the functions being built. People as users become a vague notion that is hardly considered as functional pieces are built and pushed out.

This is an unfortunate circumstance as engineers exist solely for the purpose of building and supporting systems that people, somewhere, will be interacting with. People use computers. People use programs. People use web sites.

Even when working with Creative people, I still find myself getting lost in the code and forgetting that I eventually need to be able to interact with the user. I work on items that stimulate my brain, but don’t actually solve the user needs.

A popular design pattern on the web is MVC. I prefer this pattern myself. There are pitfalls in any pattern, but MVC allows me to work on three separate items in parallel.

My most recent, major project was constructing a content management system. I built this on Cake PHP. Cake is built around the idea of constructing the entire project on MVC principles.

The thing that happened as I built the system was I constructed an interface for the user to play with, first, then I built supporting architecture.

Recently I had a discussion with a friend of mine, he brought up the idea of constructing screens to show the user, first, then building the support system afterward. Funny how things seem to work out like that.

The point of all this is simple: engineers need to pretend like the clients are users, because they are. When building a function into a system, the engineer should ask, “how will this impact the user?”

Another way of stating this is, everything an engineer does, even at the deepest level of a system, will impact the user and their experience. From speed, to clean integration with a client-side interface, every line of code is important to the user.

The most important thing to keep in mind is that we are no longer in a world where bare forms and featureless landscapes of system interfaces are acceptable. Users don’t want to be reminded they are working on a machine built to do math really quickly.

Users don’t want to see an interface that is a direct expression of code, they want a smooth, human-like experience that leaves them with a feeling of satisfaction and ease.

Depending on how you view this challenge, it is either fortunate or unfortunate that building a system that anticipates user needs requires careful consideration and, potentially, more code.

The age of engineers that build programs in C and COBOL, which run exclusively on the command line is done. Engineers in the new era must be user-aware. They must anticipate user difficulties before they happen and prepare to guide the user, in a smart way, through the minefield

Current-era engineers are the gatekeepers to the computing experience. They hold the keys and empower the user to build confidence and manage the experience they have in a natural way.

Instead of being a guard, keeping common man out, be a host. Encourage your users to click, type and interact. Give them a wonderland. Pretend that they’re users, treat them like people and make the web a better place.