Web Designers … From a Web Engineer’s Perspective

By way of introduction, let me say that I often present myself as a “recovering software engineer.” That is to say, I’m not one of the breed you see these […]

About the Author: admin

January 14, 2013

By way of introduction, let me say that I often present myself as a “recovering software engineer.” That is to say, I’m not one of the breed you see these days who assemble intricate programs from fancy toolbars or pre-built class libraries. No, I was a full-on Jolt cola-drinking, pony-tail-wearing, hard-core nerd from that mystical DOT-COM era at the end of the last century, when we wrote Perl or ASP script in a text editor, spaghetti code was practically an industry standard, and web design was pretty much limited to questions like, “Arial or Times New Roman?” and “What color do you want the background to be?” Let’s face it, my generation invented the <blink> tag and actually thought this was a good idea. These days, I enjoy dabbling in more modern stuff like Ajax, JQuery, and Flash when I get the chance, but to be honest, asking a command-line dwelling Neanderthal like me to develop a user-friendly design with these tools is like giving a toddler a selection of finger paints and asking them to paint your portrait. “Hey, this is a cool control. Let’s throw that up on the page too!”

Web design as a profession really came in to its own after the turn of the century, and those companies who were forward-thinking enough to have dedicated designers on staff were the envy of those of us who did not. This wasn’t because designers made much “prettier” web sites (we can always reverse-engineer “pretty”), but because everything they do, by definition, looks and feels like it should be intuitive, yet so many of us just can’t think in those terms.

My first experience working with this mystical breed was around 2004. I was lead developer on a project to build a web-based scheduling, calendar, and messaging system for a large company. My team included a “designer,” who worked in a black box at some other company, and who I instantly decided I wasn’t going to like. Why are we blowing a third of the budget for some kind of graphic artist-type person?   My first and only real contact with this designer came at the end of the project, when I received a .zip file containing a bunch of web pages and something I’d never heard of before called a “CSS File.” Each page had a large, commented out space in the middle of the code that said, “Darrin: Insert your magic here.” So I did. When I loaded the site, it was like clouds parting and trumpets heralding. This had to be what Simon felt like when he met Garfunkel. This was the chocolate guy bumping into the peanut butter guy. This was like rehearsing a play for six months and suddenly getting to do it with costumes and sets as well.  This mystery person had taken my work and expressed it ways I hadn’t even envisioned.  Dashboards instead of menus?  Drill-downs and collapsing sections instead of huge scrolling lists?  Tool-tips and contextual help instead of “man pages?”  Who was this mystical wizard?!

These days, web designer typically don’t work off-site and magically appear at the end of the development cycle.  With so many more possibilities to choose from in the user interface, and so many more decisions to make concerning user experience, a web sites design is often just as complex, if not more complex, than the underlying system. For that reason, designers are often involved right from initial discovery phase of new projects and work alongside developers throughout the project.  In a typical project, developers live in a world of functional requirements — “What do we need to get from the user?” “What do we need to give back to the user?” “How do we store this information in the system to optimize speed and efficiency?” Designers, on the other hand, focus on the non-functional — “How does the user want to interact with the system?” “How can we make it easy for them to supply the information?” “How can we present it in a usable, efficient manner?” “How complex or simple should the website be so as not to frustrate or insult the intelligence of the user?”

I have had endless debates with many of my designer friends as to which job is harder. Certainly, developers have to constantly keep up with new technologies, speak in strange coded languages known only to a few, and often work in a Jenga tower of complex and precariously integrated systems where one misplaced digit can stop a business cold in its tracks. In a typical project, the developer is given a list of things the system must do, and the project is complete when the system does everything on the list. At an oversimplified level, you could say the job can be reduced to ones and zeros. Does the system do X? If Yes (1), then it works. If No (0), then it doesn’t work.

Designers, on the other hand, have to be part developer, part artist, and part psychologist. Developer, because they too must know the capabilities and limitations of the platform and have a good understanding of the available components; artist, because they must constantly come up with creative ways to present the user interface that are both functional and appropriate for the audience who is using it; and psychologist, because so many times the decisions that need to be made are more a matter of personal taste or user perception than they are of right and wrong. The worst thing you can do is to give a designer a set of black and white “must do this” design requirements in the same manner you would give an engineer. Does the report display on the screen in rows and columns? Yes, although the user no has to spend fifteen minutes hunting for the one cell that’s important to them. The most well-engineered and technically correct system can still be unwieldy or completely unusable – making it a failure. Why is the user frustrated with the experience? What don’t they like? What can we do to make it better? These answers aren’t spelled out in a definition file or set of rules, nor are they empathically gifted to the designer (well most designers, anyway). Beyond the obvious technical know-how, finding these answers requires a combination of customer focus, imagination, communication skills, and familiarity with a customer’s business that, let’s face it, don’t always go hand-in-hand with the engineering disciplines.

So, hats off to my designer compatriots. We couldn’t do it without you.

Share article

Related Articles —

— Also on Galvin Tech —