Category — ux

One thing designers aren’t often taught in design schools is how to work with and respect the other functional areas that you’ll work with on software. For the most part, the attitude coming out of HCI or related programs is a strong belief in design as being a savior to the rampant problems of bad experience with software (a belief that can easily become arrogance). Once you are out of design school, you will then find blogs that say more of the same, often either writing about ways around constraints and frustrating developers, or touting new methods for how to instill the value of UX into one’s organization. In a way, we are trained to believe that design is everything only to find it can be quite a hard sell in the real world.

I’m not writing this to criticize design schools. In fact, I think this is probably the way it should be. Designers should leave school feeling inspired and ready to take on some of the wickeder problems out there. The problem, I think, really lies in the defensive nature the UX community often takes when confronted with obstacles in corporate and consulting environments. We believe we can change the world, only to find that our designs are hacked by developers or simply ignored by our clients. So we get upset. We blame software developers. We blame product managers. We blame “the corporation.” If we haven’t quit our job to find a company that “gets it”, then we try to find better ways to “sell” our designs. Or change the culture. We try anything to get the other functional areas to understand just how valuable we designers are.

Fundamentally, this “design first” attitude is self-centered.

How often do you think about the needs and motivations of your other functional areas? Unless someone genuinely has it out for you, it’s safe to assume all functional areas working on a product want the same end result: a product that is useful and a pleasure to use and makes money. So why do we act so differently or above other groups? Mostly, I think it is because each area has different incentives that yield different motivations along the way. Software developers, for example, are largely risk managers. They have deadlines just like any of us but they have the ability to actually break the product you’re building. As a result, they will inherently be hesitant towards any changes that they are unsure about. This manifests itself to designers as “scoping out the important stuff” or “being conservative.”

Another example (at least from my experience at Autodesk) comes from Quality Assurance (QA). Their incentive is defect counts (simplified). They are paid to pick apart the product. As a result, you may find them asking very detailed questions about designs–things you may find either inconsequential or downright annoying. They are only doing it so they can do their job better. These are just several examples of the ways different functional areas of a product development team can have a perceived negative effect on your ability as a designer.

Everyone involved in a product has the same end goal but we have different ways of getting there. And while there is nothing wrong with thinking that design can save the world, it’s not the best approach or attitude to take to really be successful. In the above examples, you could increase your chance of items not getting scoped out by planning better and working with developers or software architects earlier on in the process. You could help QA by being aware that the amount of detail they need from your specs may be more than you care about (a nice by-product is that your design will improve).

If my experience over the last 5 years has taught me anything, it’s that lecturing and selling design are easy ways to meet resistance. But respecting and empathizing with the other teams you work with are easy ways to find solutions. Helping others get what they want will help you get what you want.

Respect.