UX & UI Designers in Engineering Environments

Caveat: My observations are infused with considerations that have been evolving since the seminal work of Silicon Valley’s early pioneers.

One might wonder, as I had, about legendary designer Jony Ive’s apparent influence over Apple’s product development. To this casual, outside observer, Ive seemed to have a reach that extended deeply into the company’s products, maybe even details that typically — justifiably, in traditional views — belonged to the project engineers.

Why did an autocratic organization’s autocrat-in-chief allow that, perhaps even welcome it?

A Recent Convert

My thinking has evolved. Apple’s design chief needed that kind of power, or some immunity from other’s authority. If he didn’t possess that, we might not have seen some fine Apple products. Not just by their looks, but how we feel when using them, or even just touching them.

Authority Matters

Even if a designer has sufficient insight and gravitas to rule wisely and with a firm grip, they must also have authority sufficient to the tasks they face.

The more innovation that is required, the more authority might be needed to achieve it. Otherwise, any differing interests could veto, weaken, or argue a way around the design proposals. Without vested authority in a lead designer, team contributors and critics can debate or stonewall a design issue into an impotent death. (See Picking (at) a Successful Design.)

Smart ≠ Grokking

Development team members are smart. Significantly, they are accustomed to understanding. And when they claim they understand, one tends to believe them less critically than might be warranted.

“It’s not how smart you are,
it’s how you are smart.”

People don’t know how much they don’t know. That includes smart people accustomed to acquiring new knowledge fast. Designers might approach a solution from an entirely different direction, one which seems abstract or even pointless to non-designers until they see a functional prototype.

“Engineers are not immune to good design.”

Lobbying for the internal resources needed to produce design innovation may require convincing presentations. If less authority is inherent to the designers, more work may be required to produce and justify proposals.

Talking Points

Frameworks

Production frameworks for software development make it easy to produce familiar user controls, processes, and layouts. But design that’s intended to be innovative should be separate from, not constrained by, implementation choices such as programming language and development libraries.

Designing within a framework, or using a programming language’s native constructs, naturally introduces constraints. Those are metaphorical boxes full of building blocks that both facilitate and suggest developer choices…

…but innovation.

Outside the Boxes

Why do websites mostly work the same? One page and a menu. Click a link to see another page. But what if the site was shown in two different browser windows at once? Must pages and “blocks” of content be rectangular? Why click things, can’t we just look pointedly and blink twice to activate a link?

One of those things is possible now, it’s just not done. The others — or, really, any very innovative idea that’s intriguing enough to explore — won’t be tackled easily with typical toolkits that are paved with good and useful intentions…

…but innovation.

Conditional Understanding

Engineering teams appreciate good design that’s sensible — especially what I sometimes refer to as prescriptive design. Need a new function? Just create a new icon, add a new button to a row of other buttons. Too many buttons? Hide some in a hierarchical way that makes sense and label them well.

But some design is closer to the lizard brain than to the analytical one. Its superpower is that such design doesn’t serve only well-practiced users. It reduces the load on unconscious mental subroutines that interpret the environment, identify choices, evaluate potential responses — regardless of one’s measures of intellect.

“Oh, it’s right here.” [See the human[e] interface.]

Get it right and the result feels partly magical or, at least, frictionless. It is a reward that warrants the effort involved in the novel approaches — and, sometimes, the trust — required to innovate design in a more-than-incremental fashion in engineering environments.