Who wags who?

It's an old joke to ask if the dog wags the tail, or the tail wags the dog. The saying fits in many contexts outside of media, including the age old battle between testing and engineering, or the usability of the application, and the technical design of the application. Do the user experience (UX) folks design without regards to the technical feasibility of their work, or does the engineering team dictate design by imposing technical constraints?

Jumping in the way back machine, five or six years ago I was working on a large web application, it was Macadamian's first project where the engineering team implemented the output of an interaction designer. When asked, I told the designer to go ahead, don't let technology limit your designs. Sure enough, we ended up creating an impressive web application (see left) with all the bells and whistles of a rich internet application, all back in 2003. I also lived at work for weeks implementing all that cool stuff. I wish I had read this article back then!

At Macadamian, we have had a world class user experience group in-house for the past few years. Learning to work with this new UX group was not an easy task for a primarily engineering and quality assurance company. It took more then a couple of months to work out the process for collaboration between UX and engineering. Everything Tim has discussed we have also learned, the hard way.

Being that I come from the engineering side of Macadamian, and that most of the costs of the project are on the engineering side of the project, the point that jumped out at me the most was the suggestion to listen to the concerns of the developers.

The first few combined projects between the engineering and UX group resulted in significant schedule delays and cost overruns on the engineering side due to really good, really cutting edge, and extremely difficult to implement designs coming out the UX group. When the estimates were created, the estimator put time in to basically add some form fields, text, and maybe a graphic or two. Pretty naive.

Unfortunately (or fortunately depending on your perspective), the customer saw these designs, loved them, and then expected to get them for the same price as that form with 23 checkboxes and 97 form fields. The complexity and innovation required on the UX side was not expected on the fixed-bid engineering side.

To solve this problem, a simple (and in hindsight, obvious) process improvement was made. The developers had a chance to look over the designs prior to the customer seeing them. This allowed any potential design decisions that would adversely impact the schedule and cost to be caught, and fully discussed prior to the designs being approved by the customer. It wasn't that engineering had a veto over the design, it was allowing the usability group to be made aware of any potential technology challenges to be discussed earlier in the cycle.

This allowed the two groups to work closely together and solve any potential issues. Sometimes the UX folks were able to convince the developers of the critical nature of the particular design, and other times the user experience group came up with another solution that was just as usable, but much easier to implement. However, don't confuse this approach with one where technology drives what personas can and cannot do with the product, that would be a mistake. User needs have to drive the design.