Wednesday, June 02, 2010

Requirements vs. Constraints

I love "x" graphs, you know, the ones that show one domain diminishing while another is increasing. They form an x, and the point of intersection represents a sweet spot or break-even point. These days, I feel like I'm living the one shown below:

The more feature-rich a particular design approach is, the more it delights product management. Of course, that starts to overload available engineering resources which drives their delight down. Being a UX designer puts one in this position a lot. On the one hand, you want the product or service to be a differentiator in the market place, one that carries a lot of delight to the customer. On the other hand, it has to be build-able within the constraints of the organization's resources.

So you look for that acceptable area of compromise, somewhere close to the intersection of the two lines. Something achievable that represents enough delight to be a package you can take to market. You end up playing devil's advocate at times, pushing back on product management and goading engineering to stretch. You need to be sensitive to when to back off and say, "OK, I hear you, let me see how I can make the design accommodate that."

In the end, you have to have both sides at the table at the same time, otherwise you find yourself in a series of no-win situations where you are the bearer of the bad news (the areas shown in gray). It also helps the spirit of compromise if each side can be connected to the other's point of pain. Engineering is more willing to bend when they deal with Product Management directly, and Product Management is more willing to compromise when Engineering says "Our schema can't accommodate that kind of a query." Also, each side can hammer out alternatives a lot more efficiently when talking to one another. I'm always impressed how creative engineers can be if you share the problem with them instead of insisting on a particular solution.

This could be one of the most important skill sets a UX designer develops, the arbiter of user requirements and product constraints.

No comments: