Enterprise UX Design

Last week I participated in on UXPin’s Enterprise Summit (2017) . On the last day there was a panel discussion by UX gurus on the state of enterprise UX with Jeff Veen of True Ventures, Lou Rosenfeld, and Marcin Treder of UXPin and Sunita Redd of UXPin. Over and over and over I kept hearing them use the word delight. So here’s what I want to say: Dear Enterprise UX Gurus: STOP! Please stop using the word “delight” in the context of enterprise UX. Just stop. I’m not the only one who wants this . Delight is creating an emotional bond with a user through pleasurable experiences IN ORDER TO SELL THEM SOMETHING. This is wholly a consumer-side idea. Enterprise users have absolutely no choice in whether they get to use our product. It’s already been decided by management. I’m up for a replacement. I personally say I want to give the user a good day, but more importantly I’m trying to make users more efficient. I’m trying to create human capacity for the company. Yeah, it’s still...

Recently one of our UX designers floated the idea of going with a font size smaller than our standard because they needed the extra space. Being the avid researcher I am I went out and started hunting for information on best practice font size on the web or in applications. I mean it's been years. Someone must have done a study. I came across someone else on Stackflow asking the same question , but none of the answers were anything supported. Just unsupported tribal knowledge. To make a long story short I managed to find a great study, The Uncrowded Window of Object Recognition , done by Denis G Pellli and Katharine A. Tillman, 2008. It comes down to this. Letters in a word are an object and must be recognizable by the brain. As you reduce a font, you need to add a little space around the letters so they can be recognized. It really doesn't have anything to do with size. Here's an example in the standard Verdana/Helvetica at 13 pixels: "You saved my life,"...

I don’t know what your calendar is like, but at my company at the beginning of the year business and upper level IT managers will prioritize their needs and I’m assigned to different projects depending on priority. Sometimes at this time of the year the air feels electric. It's almost like going on a first date. Will the project be exciting? Will it match my skills? It may sound silly to compare working on a new project to a first date. But, it's far more relevant than you might guess. While we want our users to fall in love with our products, it's wrong for us as technologists to fall in love with them. If we do, we lose the objectivity we need to keep our biases out of our work and we lose the ability to clearly see and measure the results of our work. Psychology of Attraction First, let's learn a little about how falling in love works. There are three stages:  Craving or lust - is used to filter all our options into a group of what we desire in some way.  ...

I was reading a blog article, " 9 do’s and don’ts of UX design ", this evening and found this particular section concerning: "...sometimes too much corporate oversight can limit the design process, as many clients, who obviously aren’t designers themselves, don’t exactly know what looks and functions best on the web. While they surely have the best intentions, sometimes UX design is best left to the designers—they’re the ones with experience in the field after all." Coming from a corporate environment, this was really more of a whine since it didn't contain any constructive suggestions to handle the situation. So I thought I would share some things I've learned through the years about working with business reps. 1. Everybody is visual. Go with it. While you may have a business analyst to elicit business rules and process and to define the problem, when the solution is a UI it's easier for someone to draw out what they're thinking than to ...

At my company we've been dreaming of being able to localize our UIs since I started working there. While we have localized here and there for the most part it just doesn't happen. There simply aren't the resources or knowledge. Instead our employees in all branches are required to speak English. I have no idea how branches determine whether a person's ability is up to standard to be hired. I've never seen any guidelines for branch management to follow and admittedly our industry is one where you have to learn a lot of jargon, too. I imagine that may other global enterprises are the same way. This means that your users may struggle to understand your UI, especially those newly hired employees. So part of your user research should be pointed at determining at what level your users can understand written English. Here are guidelines you can use based on the European Framework of Reference for Languages . (See Chapter 9 for more information.) I assigned the readi...

Did I get your attention? Today in our BA/UX meeting our new, very consumer-oriented UX person asked why he is sent to our business representatives to get answers instead of having access to users. It made me realize how different our process in creating enterprise applications is from the process recommended in UX consumer-driven design Don't get me wrong. Our employees do the work and the applications need to be designed to support them. But the process to complete the work takes center stage. In the enterprise you don't get to allow employees to define the process they would prefer to follow or even maybe currently follow to design a new application or update an old one. There are far more important things that matter to business such as adhering to government compliance and regulations and performing tasks expediently in a predetermined order or process. Many large and international companies have a group that determines the processes that must be followed by employees ...

We've had an on-going discussion at my company about where to place main functional buttons. At one point we were following an application paradigm where all main functional buttons were placed in a menu bar at the top of the page. Prior to that and now we follow a web paradigm where all the buttons are placed at the bottom. We always placed them to the right until one designer started refusing to do this especially with search forms. His reasoning, and rightly so, was that the button was being placed too far to the right and away from the form so that the user was being forced to search for the Search button. When I finally understood my job as an enterprise UX designer, two things changed how I lay buttons out on the page. First, red routes. What is the single main task the user will do on the page? What does that part of their process look? What is the main data and/or inputs they need to do the task? When do they have the data to enter or review so that I arrange that inform...