Debunking 8 Myths of UX within an Enterprise
Checking session availability…
Hang tight while we load the latest updates.
How do you take away the bad reputation enterprise UX has accumulated over time ?
Work tools are important and getting their experience right has always been tricky with the complexity and multi stakeholder environments.
In his talk Amit shares some myths about enterprise UX which keep products away from making experiences exceptional, appropriate and delightful.
He will share learnings from failures and how products can re-pivot to focus on the right things that empower users and their organizations to achieve more.
Debunking 8 Myths of UX within an Enterprise
Amit Patil at UXDX Community: Bengaluru. Video: https://youtu.be/ZHYBKTIeKhw
Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.
What enterprise user experience is
[00:00:00] Hi everybody, I'm Amit Patil, senior design manager at Microsoft India, and today we're going to talk about debunking some myths of UX design within an enterprise. Let's get started. What is enterprise user experience? User experience for big organizations? User experience for small organizations? Well, there are a lot of definitions out there, and to begin with, let me just set the context and say user experience for enterprises is all about software which are work tools used in organizations, irrespective of the size of the organization as such. That's the assumption we'll take and we'll move on today to slay the myths for enterprise UX.
[00:01:02] Once upon a time, and that's where all stories start, so let me start with that story. Once upon a time when I was a designer, an aspiring designer actually, and wanting to do big, big projects and such, we were part of a project regarding SharePoint for a big telecom communications major. We took all the requirement documentation and we understood every little detail of it. We talked to the customers every day and tried to check, oh, are we on track, are we doing it right, are we doing it right? And finally deployed it, deployed the wonderful experience.
[00:01:41] During the pilot run, when we reached the actual office where the software was deployed, just to talk to users and understand, and possibly also get some goodies for our bosses back home, like, hey, see, look what we've done, we didn't find a lot of excited faces. In fact some of those users didn't even want to talk to us, because we had, it seems, added overhead to the existing flow and existing set of things to do, and that was a major concern. We were wondering why did that happen.
Myth one: the user is the customer
[00:02:17] One reason for that is myth number one: the user is equal to the customer. That's one myth which most organizations carry, and I'm sure there can be a lot of arguments around it, but the end user is not always your customer. Now try to compare it with, say, buying a shiny phone. When you're buying a shiny phone, you decide I want to buy the shiny phone, you go to the store, you pick up the best shiny phone, or these days do it online, pick up the best shiny phone, the shiny phone comes to you and you start using it. At most you'll buy it for your parents or your brothers or your family members as such.
[00:03:02] However, when it comes to enterprise, you know that enterprises are complex beings. The one who discovers it, the one who buys it, or the one who uses it is not the same, and that's the challenge. That's why the formula for consumer experience design cannot be directly applied to enterprise user experience, because these people are different, they have different ways of thinking. And hence you cannot ignore, or just blindly believe in, customer responses, because the customer is not your user always.
Myth two: org needs don't matter
[00:03:47] Moving on. Organizations are complex. They are almost a complex fabric of departments and people, and above all there's so much that organizations actually have within themselves. Each user has different software that we handle as enterprise software, ranging from time management to vendor management to even everyday communications as such, and sometimes we don't even know what software is used within the same organization.
[00:04:24] The reason I bring this point is myth number two, which is: org needs don't matter. Now this is another big myth that we tend to have when designing enterprise user experience. Yes, we do listen to the customers, whether we are a service company or a product company, but we don't see the ecosystem, which is called the organization, in which the software is actually being used. That's a big myth. What you should actually try and do is not try to imagine your software in isolation, or enterprise experiences in isolation. You're not going to deploy it in space. There are going to be living beings, and actually living organizations, with different needs. So look at these different needs within that organization.
[00:05:21] On one side we need to understand the user's perspective, we need to understand the organizational perspective, and we also need to understand the ecosystem within which it sits. Enterprises are interconnected meshes of multiple tools, and we need to actually give respect to those existing tools. You never know, your competitor is being used by the same user during the same time within the same organization. What people do offline is equally important within that organization. And hence, trying to actually understand organizations, or even having organizational personas if required, is equally critical.
Myth three: aesthetics and delight are optional
[00:05:58] Moving on. When you think of enterprise software, isn't this what comes to our mind? Something that is densely populated. And no offense to the designers who might have designed this, or even the organizations, everybody has their constraints, but the point I'm trying to drive is most enterprise software has got its bad name because of its bad looks or bad aesthetics. And that takes me to myth number three, which is: aesthetics or delight is optional.
[00:06:34] Think of it. We are people who work all our days, and these days days and nights. Around 90,000 hours of our life goes into work, and these tools that we use day in, day out actually influence our thinking, our working, our moods, and these moods end up influencing our impact on productivity. And hence aesthetics is not optional, delight is not optional.
[00:07:06] One example I could talk about is Yammer. Yammer is Microsoft's tool which is used as a social networking tool within organizations, and when we were redesigning it an interesting perspective came into the picture, where a lot of people were wondering why do we need to craft the experience to this micro detail, or even make it aesthetically appealing. But you would not imagine: the usage of Yammer gained a lot of success after the redesign. In fact it actually helped us as well as the organizations to communicate better.
[00:07:49] Moving on to a more famous software, which is our favorite enterprise mail software, which is Outlook. In the recent Ignite conference Microsoft announced a new way of interacting with it: reactions. Reactions are these small emoticons. If you remember, in social networking we use them often, but bringing them to email actually changes the way you feel about certain things, and you're actually getting an ability to express what your feelings are, and hence creating an experience of delight.
Myth four: we need to simplify everything
[00:08:27] Moving on to cockpits. No, we are not traveling anywhere during the pandemic times, but the reason for putting cockpits is my early years, when I joined an aerospace company. As a young designer, like any other designer, I was challenging the very complexity of the cockpit. Of course everybody, every designer, would like to put it in their resume that I like to simplify things as such. While I actually had the same notion in my head, I started talking to pilots and I started talking to human factors engineers, and that's when I realized the perception of simplicity is relative at times, and what, say, a pilot finds simple is very different from what we, or me, or you find simple.
[00:09:19] In fact that takes us to myth number four, which is: we need to simplify everything. Now that's a big myth, the reason being your users are not dumb. Your users are actually some people who have expertise, and this expertise could range from the lowest to 10, 20 years depending on the domains, and respecting that expertise within the interface is a very important thing to do. The reason being that when you actually reflect it in an experience, if you try to oversimplify something, the users are not going to like it, not going to cherish it.
[00:09:58] Many times as designers we face this bias: since we are learning it for the first time, we want to super simplify it. Because when we are learning for the first time, within say 30 days of your project or say 60 days of your project, we found it difficult and hence we want to simplify it because we felt it was difficult. In fact, so much of a bias, I've also seen people actually find that complexity when communicating to the users during user research as well. So this is something that we need to take care of. This is a big myth. We don't need to simplify everything. We need to simplify things to a point where the users need it to be simplified.
Myth five: user validation is optional
[00:10:45] Moving on, we talk about, of course, any kind of presentation for enterprise cannot go away without Dilbert, right? So I have to put in the Dilbert in this presentation. This Dilbert actually talks about: hey, we interviewed thousands of users and they actually turned into features, and every user talked about was really an idiot, dumb suggestions ruined our product. And Dilbert says that, oh, I don't think we should have talked to people, we should have actually talked to people outside this building, that would have been better.
[00:11:24] That takes us to myth number five, where user validation is optional, but this is something that comes at the end of the project, right before you're launching it, before you're going live. There's this tendency in enterprise user experience that we want to say, hey, we have taken care of all the needs, we have taken care of the customer requirements, let's go live with it, what's stopping us? And it's actually only by observing people using our tools, using our work tools, using our software, that we can actually realize whether it fits in their lives.
[00:12:01] So in the enterprise space also, user validation, or validation from the user for your software, is not optional. It's a myth, don't fall for it, fight for it, because user validation is important. Get out of those AC cabins, get out of your comfort space of your own company, and talk to users with software that is about to launch, because you'll find and unearth a lot of mysteries.
Myth six: processes are perpetual
[00:12:35] Another story to talk about. When I was in IBM I was working on this particular project which was an assistance requirement specification project. It allowed people with disabilities to request for assistance, assistance from braille keyboards to different types of assistance. A pretty complex project, and it had its own processes, right, just like any other process any other company has. So we designed according to the process, we drew the process maps and accurately depicted everything and fit the software exactly according to the process. But when we went live, the process had changed.
[00:13:20] Now this actually was a big, big, big impact for us, because when we designed it our architecture was so fixed to the process that we had to go back to the drawing table. That takes us to myth number six, which is: processes are perpetual. This is an assumption that we make, that in any organization this process is going to stay forever. And yes, I do agree that in a lot of places processes do stay for a longer time, but changes keep happening. Companies and organizations are like living beings, they upgrade themselves, everybody wants to become better.
[00:13:55] Now of course I'm not assuming that designers become oracles and try to predict the future. That's not possible, otherwise we would have the best software in the world. But what we need to do as product people is actually create software that is scalable enough, create software that is actually flexible enough, which fits in the processes of the future, fits in the process of the customer. The advantage of this is that the same tool can be used in different situations and actually enable the customers and the users, because no two orgs actually have the same processes. So even if our sample space of the process is the same, we should actually enable, no two departments have the same processes, remember that as well. So change is always there in any organization.
Myth seven: users only complete tasks
[00:14:51] Going to the next myth, and this one is my favorite: users only complete tasks. Let's build things which will completely help them complete their tasks and we are done. I would try to say you are questioning your own humanity when you're saying that, because when we actually identify software tasks, when we identify initial tasks for building any software, yes, user flows are necessary, but we need to remember users are human beings, users are living beings in every corner. In fact the pandemic has made us realize even more how much human we are.
[00:15:39] So as humans we tend to fail, we feel, we need to do things offline, we need to take time off, we need to pause things, and we need to make software that helps the users breathe, relax, energize. Some examples I'd like to give: for example, users forget, managers forget. If you have more reportees you tend to forget when was the last time I met some reportee. In one example, a Cortana email out here on the right, you see how we are actually assisting the users to remember certain things, like schedule a one-on-one. Did you forget to have a one-on-one with your employee?
[00:16:22] This is judging the finer details of the experience, trying to make sure that we not just look at the things that they want to do and close their tasks, but look at the softer aspects of the enterprise world as such. Users feel, we all feel, and we are making experiences not for robots but actually for human beings. This particular experience, about to launch and recently showcased at Microsoft Ignite, was around the pandemic situation, as in, we are all feeling low or high, and how do we reflect on the day and how do we just express that? So how do we record our feelings?
[00:17:08] Another recently talked about experience which we were part of is: how do we actually make sure that we enable the users beyond the usual tasks? Do we actually talk about kudos, appreciation, or even give them a break at times, and remind them? So software then becomes a helper, an assistant, rather than becoming an overhead, a stick on your head. In the end, users are human beings.
Myth eight: enterprise UX is boring
[00:17:43] And eventually I'd like to talk about myth number eight: enterprise UX is boring. Now this is a lot of a myth among a lot of young students, young professionals. I want to do that fancy little thing that can be advertised. And purely due to the complexity, even due to sometimes the visually not so great looking software, we tend to see that enterprise UX is boring. But trust me, it's not. The truth is, it's not just that enterprise UX is boring, it looks boring from its outer self, and I think the onus is on us.
[00:18:26] The reality is enterprise UX, and like I said, UX for work tools, with every tool, every feature that we build, we are empowering people. We are actually making people superhumans. You're actually enabling people to do their tasks so that perhaps they in turn can impact someone else's life, or they can go home early, or they can reduce their stress, cognitive stress, or even go back to their family faster. So next time when you think about enterprise UX, I'd rather look at it as: whose life are you impacting next, whose world are you changing, whose family are you helping?
[00:19:14] That's what I'd say. Those were the eight myths of enterprise UX. And just to recap quickly, the enterprise UX truths are: user is not equal to customer, org needs do matter, aesthetics is not optional, delight experience is not optional, we don't need to simplify everything, user validation is not optional, make sure you validate with your users before you go out there, processes are not perpetual, things are not going to remain the same always, we cannot always explain it in the manual, this is the extra one which I didn't talk about, users are human beings, and above all enterprise UX can change lives. So next time you're doing that, don't think you're just designing some tasks. You're doing a great service to humanity. Thank you very much, I'm Amit Patil signing off, and it was great sharing my thoughts with you. Take care, bye.
