In How to recruit the next generation of Enterprise UX designers, I shared Uday Gajendar‘s keys for teaching UX, as well as his project lessons on the “wicked craft of enterprise UX.” We also hit on why UX is changing the minimum viable product ethos. But there is more.
A year ago, Gajendar, who is an enterprise UX designer and consultant – and an organizer of the upcoming Enterprise UX show– published a landmark post, Why I design enterprise UX, and you should too!. That post detailed six crucial ways enterprise UX is different. Gajendar also made the impassioned case that enterprise UX software can – and should be – “beautiful.” I don’t disagree, but I challenged Gajendar on what “beauty” means in an enterprise context. Here’s how he responded.
Let’s start with the eight ways Gajendar believes enterprise UX is different, keeping in mind his post is meant for designers who are UX-savvy, but new to enterprise projects.
Gajendar: eight ways enterprise UX design is different
1. Enterprise UX is domain-specific. – as Gajendar puts it, designers are used to designing for “everyone’s Grandma.” But in the enterprise, you’re usually designing for a specialized or industry-specific know-how. You need to acquire some of that know-how, and become skilled at collaborating with those that do.
2. It’s customized – that means a “one size fits all” app design mentality won’t work. Designers need to think in terms of creating “highly customizable and modular” frameworks to address this.
3. Ecosystems matter – enterprise UXers must learn to navigate multiple vendors, brands and protocols. As Gajendar says, this can be a “daunting ecosystem,” but it must be grappled with. For the designer, there are “ripple effects” from this ecosystem that impact everything from user interaction flows to job roles/user permissions.
4. The all-important sales channel – Gajendar considers this the “biggest differentiator” from designing consumer products: “the buyer is not the user.” Designers must familiarize themselves with a “heavily managed sales process.”
5. Get ready to design at scale – Unless you are designing apps that analyze millions of Facebook or Twitter records, the scale of enterprise UX design is different: “literally thousands, or hundreds of thousands of objects with hundreds of actions to be performed.” Reckoning with increased errors and edge cases is part of the game.
6. Complexity and ambiguity are a given – that might sound like a turn-off to some, but for Gajendar, grappling with the complex ambiguities of the enterprise is a great challenge that keeps him engaged. As he writes: “The complexity of a financial service or a “Big Data” app can be intricate puzzles to be deconstructed, and reconstructed again in a far better, simplified, easier model.”
7. It’s about system level problems – an enterprise UX designer is influencing system level issues. It might seem that grappling with complex technical systems would push the enterprise UX designer deeper into his or her cubicle, but Gajendar urges the opposite: it should push the designer into greater collaboration:
[enterprise UX] requires more investigative conversations with stakeholders and customers alike. Remember— these users inhabit, actually “live”, inside these systems all day to get their jobs done! And they usually see only one small part of it (maybe just 3–5 screens), but your job as a designer is to devise a clean, elegant UX model for the whole system.
8. Reckon with the data model – and last but not least, the enterprise data model has a potent impact on design considerations. More on that shortly. Gajendar goes on to exhort designers with a call to beauty:
But mostly, I’m just driven by the persistent nagging thorn of making Enterprise beautiful as hell. It doesn’t have to be ugly! Texture, motion, balance, tone, style—we can ascribe those qualities to Enterprise UX.
This is a concise version of Gajendar’s points from my own view – I encourage you to read his context for each on his blog.
Where should an aspiring UX designer begin? With the data model
I had one issue with Gajendar’s list: it’s all essential stuff, but it runs the risk of being a bit overwhelming – even if you have some enterprise know-how. So: where do you begin? Gajendar advises to start with the data model:
First and foremost is the data model, you have to understand what the elements are. The great thing is, in order to understand the data model ,that forces you work with the engineers, the back-end folks, the front-end folks, as well as the business process team who impact what gets translated into a data model. Learning the data model leads you down this kind of spiraling staircase, if you will, of being able to understand the domain and the ecosystem, and all these other players, vendors and partners.
I asked Gajendar to elaborate on the connection between architecture and UX:
It is kind of a multifaceted problem, right. Those facets have to happen simultaneously to some degree. On one level, there is understanding of the display formats and platforms, right? Nowadays, that includes mobile, and responsiveness and so on, so that’s one level. Then the other level is thinking about the actual architectural structure of the entities. Like these components and objects are the conditions. What are the states? What are the relationships? It’s important to map that out from a system perspective.
This also applies to the front-end:
Then you want to go back into the UI architecture of the front end and ask, “What data needs to be shown and displayed? How should someone interact with that data? What’s the workflow? What’s the user’s journey? What kind of information do they have, or not have, on hand? Then branching out even further at the microscopic level, it’s really looking at what I call the social life of information.
Yes, somebody enters some data into the database, but that data may be moving from one person to another because of certain business processes approvals, permissions, licenses, et cetera, so that’s the data trajectory path a designer must understand. How do we interpret the data? Then, how do we express it in a form that makes sense to the proper audiences?
The UX beauty debate – what should “beauty” mean in an enterprise context?
The other issue I had with Gajendar’s original blog post was making enterprise UX software “beautiful.” To me, beauty for enterprise software is overrated – I’ll happily sacrifice some UI aesthetics for speed of app processing, for example. Here’s what I said to Gajendar:
Either UX beauty has to be redefined, or there are other factors that are important. With enterprise software, adoption is a huge issue right now. In the past, you could almost force people to use certain software, even if they didn’t like it, and didn’t enjoy using it. Now that’s getting harder and harder, except for certain core systems. There’s a lot of pressure now in enterprises to create software people want to use. I think beauty is a part of that, but I’m not sure it’s the whole thing. For example, I’ve had a lot of experiences with Slack lately; a couple of projects and groups I work with have adopted it, I wouldn’t call it a beautiful interface, but it works seamlessly across devices and touch points, and that’s fueled adoption.
But Gajendar had already anticipated my objection. In a prior article, Towards an Integrated Aesthetic Experience, he defined four areas of design beauty: Story, style, utility, and performance. (Gajendar has some authority here; his master’s thesis at Carnegie Mellon was about design beauty).
So, the UI aesthetics of beauty would be a subset of Gajendar’s definition (visual UI would fit in under style). I like Gajendar’s view: it has the expansiveness of storytelling, but the brass tacks of utility and performance.
I really liked his inclusion of story:
The narrative or scenario of use for this product, and how it suggests a positive, beneficial user experience or service for the targeted customer. Also, how does this offering fit within the portfolio of products/services by the company? What’s literally “the story” for this, as communicated by marketing and supported by the product’s functionality, to fit the user’s needs and goals?
During our talk, Gajendar elaborated:
Story, in effect, is the marketing in a product management context. Style is the design -the beautiful design, the interaction design – how it looks and feels. Utility – that’s the ergonomics and functionality of what’s actually useful. Then performance – well that’s hardcore engineering. It’s got to work. If it doesn’t work, who cares? When you have those elements come together, it can lead to something that is a beautiful experience.
Bingo. That’s an excellent definition of beauty in an enterprise context. Gajendar went on to point out that the IBM Thinkpad (yes, the Thinkpad) was beautiful in its way: “No, it’s not the same thing as a MacBook, but it had a strong degree of craft and quality, and the signature iconic feel.” His take on Slack is a good note to end on:
I think people resonate with Slack partly because, it works well across platforms, as you mentioned, but it’s also it’s just a well-crafted interface. It may not be the most visually seductive and sexy, but it’s just well crafted. In enterprise software, design craft is a hugely overlooked, it’s one of the last things for various reasons. The craft leads to quality.
End note: this piece is part of my ongoing series on enterprise UX.
Image credit - against the stream - opposite concept - leader goldfish © Romolo Tavani - Fotolia.com
Disclosure - diginomica has no financial ties to Uday Gajendar, or the Enterprise UX conference.