Despite tension, engineering and design needs must be valued equally: Execs

The fervor around the consumerization of IT (or at least use of the buzz term) have waned, but some of the key principles are more crucial than ever.

Chief among them is arguably the elevation of the user interface and user experience, making enterprise software as friendly and easy-to-use as common consumer apps on mobile and desktop computers.

Yet despite all the hype over the last few years, there still appears to be a debate to remind everyone from developers to IT administrators that engineering and design need to be considered and valued equally in order to achieve this.

"You can't really weigh one over the other," suggested Pivotal Labs design director Tim McCoy. "You actually can do engineering without design. Design without engineering is like a class project. It doesn't matter."

General Electric experience design director Dan Harrelson stressed that you have to understand what end users want, but also consider the medium too. For example, this means whether content is delivered in print or via the cloud.

Ethan Batraski, vice president of product design at Box, concurred and proposed the analogy that a designer without an engineer is produces for an art gallery, but an engineer without a designer ends up with a parking lot.

"You don't want an engineering-based organization overseeing design. There's a conflict of interest there," warned Etan Lightstone, director of UX design for New Relic.

At New Relic, Lightstone noted the software analytics firm relies on "UX generalists" and not specialist designers and researchers, which he attributed to the company's "heritage as a startup," in which there wasn't even enough work for a specialist before.

Lightstone also said he's been witnessing a trend where design is becoming more valuable to the definition of product, which perhaps makes a case for design being tied to product management.

"They're responsibilities rather than roles," McCoy followed up.

At Pivotal, McCoy explained, the overlap between engineering product managers and designers stands at roughly between 50 and 75 percent. There are some tensions, he admitted, such as who has a higher valued vote into what's actually being built.

"There's some healthy tension there," McCoy remarked. "At the end of the day, the product manager has a primary responsibility to the business. The designer has a primary responsibility to the user."

There's an interpersonal relationship solution there, he continued, so long as team members realize they have the same goals.

There are occasions where that overlap can be destructive, Lightstone pointed out.

Developing for enterprise customers is also a little more complicated than for consumers, Batraski argued, pinpointing three areas where this occurs: where the buyer is not the user (i.e. IT administrators), different sales cycles, and use cases tend to be broader in the enterprise.

John Maeda, the panel moderator and a design partner at venture capital firm Kleiner Perkins, quipped that building for and establishing a relationship with enterprise customers is "more of a long courtship" compared to a "Vegas wedding" quickness treated to consumers.

Product managers, if they're doing their jobs right, know the customer already, Harrelson added. But designers don't always believe the product managers and tend to take longer in background research.

But, when all is said and done and a product is shipped, product managers are still held to a higher level of accountability, Lightstone reminded, hinting that further fuels the tension at the table.

Batraski highlighted the pressure of having to anticipate what mobile will look like in two years and how users are going to consume content in that time frame too. Based on how smartphones and tablets have rapidly evolved over previous last two years (or even last six months these days), this is seemingly impossible from an outsider's perspective.

Nevertheless, Batraski admitted his product teams, who are strategically seated near designers at Box, plan as far out as the following two weeks, constantly changing and adapting to shifts in the marketplace and user demands.

"You are constantly trying to balancing the current base with the needs of future problems," said Batraski. "You have to get ahead of it."