diginomica

Enterprise UX roundup – unicorns don’t collaborate, but good designers do

Since my last Enterprise UX missive (You can’t build a good enterprise UX without user research), it’s been a little quiet regarding big UX ideas. But sprinkled amongst the latest UX articles are a few topics I have yet to hit on. Here’s four key concepts.

1. You don’t need to chase unicorns to build a great UX team. Enterprise UX has something in common with data science: the tech press loves to fawn over the skyrocketing salaries of exotic skill sets. But just like with data science, successful Enterprise UX teams are not built with divas and rock stars. As Jennifer Winter notes in You Don’t Need a Unicorn: Anatomy of a Great UX Team, it’s about building a well-rounded collection of team players – as unglamorous as that may sound.

Winter reviews five key players on a UX team: generalists, researchers, designers, writers, and managers. Once you break them down that way, it doesn’t sound so exotic. I’d argue she missed a couple: for example you could make a distinction between visual designers and “experience designers,” (good teams probably need both). There is often an architectural design aspect also. In some cases developers will need to be part of the mix.

If those types of designers give you a popsicle headache, it’s basically about 1. make sure it looks good and is easy to use, 2. make sure the experience is seamless with what the brand purports to be about 3. make sure the UX is compliant with the standard way the brand’s software is presented.

Then there is the matter of coordinating user and performance testing. But once we peel back the UX sex appeal, most of these skills are folks who already exist in your organization, ready to tapped on the shoulder. The design part is one area where specific skills may need to be identified and outsourced. But that’s about budget and resource management, not chasing unicorns. I’d argue the bigger challenge is not building the UX team, but incorporating UX early into the product/software design process (see how Infor’s data science team pulls UX design into early prototyping).

2. Enterprise UX is dead in the water without collaboration. If we accept that collaboration early and often is a key to enterprise UX, then how do we get it done? In Developing a Collaboration Culture by Jaimee Newberry, she breaks out five key “shifts” to a collaborative UX culture:

3. Programmers must embrace the UX challenge. I’ve long believed that developers need to immerse in modern design principles and put themselves in closer contact with the business users they are building for. But in Programmers, Let’s Earn the Right to Be Called Engineers, Kathleen Vignos takes it further, challenging developers to live up to the “engineering” title that they have appropriated, at least in corporate job descriptions. Vignos delineates several characteristics of what she considers to be true programming engineers. One of those is design:

This is by far the greatest overlap between people who build with code and people who build with steel and concrete. Software developers must solve complex problems; envision unintended use cases; and ensure the capacity of their designs, just like bridge builders. Their designs evolve over time, innovative frameworks arise, standards improve…

As a software developer, my colleagues and I constantly adopt new process tools (think Node, Docker, Jenkins, Vagrant), invent frameworks, and strive to improve performance (think decreased start render, server load). And we learn from failure, applying those lessons to future projects.

While some of Vignos’ “design” characteristics are better classified as learn-by-doing/intellectual curiosity, the point stands: developers serve modern UX better when they push to grasp the bigger design picture.

In 2014, developer Steven Caven made a similar argument in Why Developers Need to Learn Design:

In this new world, the best thing a developer can do is to acquire an eye for design—to be able to take design aesthetic, realize its essential components, and reinterpret them on the fly. How is a certain piece of design going to look and behave? How will a tablet designed for a desktop view work for mobile? Designers and developers can work together to answer these questions. Almost always, these discussions lead to a solution that is elegant, effective, and sensible.

4. You can’t design for the enterprise if you don’t grasp the enterprise. I’ve written about how enterprises can learn plenty from consumer UX design virtuosos. But enterprise UX pros need to understand how seemingly mundane but not trivial issues like the enterprise data model impact the design process. In Why I Design for Enterprise UX, and Why You Should Too, Uday Gajendar kicked off 2015 with a very good post that details the following enterprise software attributes designers must reckon with:

My take

That’s good food for thought from Gajendar. I’m interviewing him next week for an upcoming Enterprise UX feature, so I’ll ask him how his thinking has evolved in 2015 and what he envisions for Enterprise UX in 2016. I’m betting the Enterprise UX show in San Antonio (June 2016) he is helping with with come up also.

Meantime, I hope you enjoyed this article review, which fills in some gaps from my ongoing Enterprise UX article series. If you know of a company (or individual) doing kickass things with Enterprise UX, please be in touch.

 

Image credit - Fotolia.com