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:
- Understand and embrace a UX mindset – “A UX mindset reframes the thinking of what User Experience is. As brands, enterprises or corporate cultures, we need to think about UX as a [company-wide] responsibility, not as a role.”
- Collaborate from the “Why” – “Everyone involved needs to understand the “why” behind what they’re going to be doing. Start off every project, product, feature or requirement exploration by framing the problem that needs to be solved and the outcome that needs to be met.”
- Respect for roles – Newberry sees the lack of respect for certain roles as a cause of a lot of miscommunications and morale problems. How do you overcome that? Newberry advises to build multi-disciplinary teams and build time into work days for more personal interactions.
- Improve communication – Kind of a no-brainer, but Newberry says to pay special attention to the listening not the talking side. She also cautions that word choice is crucial for avoiding emotional or blaming situations.
- Encouragement to Embrace Change – Another no-brainer, stemming from the difficulty of culture change around UX. Newberry reminds that seeing the good aspects of change is a discipline and a mindset choice.
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:
- Domain-Specific – Enterprise software is created to serve the needs of a specialized audience. That means you’re designing for a “tribe,” if you will, with a set of concepts and terminologies unique to their industry. Ergo, you better know this stuff or your designs, however pretty, will fall short.
- Data Model – All software has a data model underlying its interface and interaction. But as Gajendar points out, “In enterprise software, due to the domain specialization, this data model can be mind-blowingly complex… Grokking it can be a big challenge, yet helps in preventing it from being dumped all over the interface!”
- Customized – “In my experience, Enterprise solutions typically require heavy amounts of customizability, because of detailed needs of a certain buyer… Hence, the need to create something highly customizable and modular to serve that demand.”
- Ecosystem – Gajendar has found that enterprise software ecosystems are much more complex than consumer ecosystems, causing a “mostly invisible ripple effects of user interaction flows, data clarity & mutability, notifications and messaging, roles/permissions of use, findability of objects, in an ‘ecosystem’ of dashboards, portals, modules…some of which may not have visibility into each other! Oy.”
- Sales Channel – Gajendar considers this the biggest differentiator of all from consumer products. The buyer is (usually) not the actual user. “These are not products you breezily pick up at Best Buy or the Apple Store on your way back from lunch, sadly. There is a heavily managed sales process, with formal channels of awareness, marketing, engagement, and demo’ing via “proof of concept” (which can take weeks or months to setup).”
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