The more you practice and learn user experience, the less time you spend in the artboard. The idea is that researching and interacting with stakeholders and users are front-and-center, and blind hypotheses for your designs take a back seat.

Now, how is that different for business-to-business or even business-to-employee apps?

And (the real question here): How is that a good thing?

A Duel Without a Weapon

Let’s be honest. A happy day for me, as a UX designer, is when I get to sit at my desk and put my headphones on. I am not shy, nor do I loathe human contact (most days I don’t). But, there’s something about having to create something out of nothing that makes me love the craft: The compulsory isolation, the frenzy of a deadline, the uncertainty of what works.

Except you never really create something out of nothing. At minimum, you always look at what others did before you. Call it benchmarking, competitive analysis, or finding inspiration. Even if you’ve got your headphones on, design is not a lonesome task.

More than that, if you get to this moment without some preparation, then you’re arriving at the duel without a weapon. Doing user research before getting to the artboard is how you know and understand the people behind the device screen, how they work and think, and what they need. This is how you create an alternative for their lives that is not a blind shot.

About Doctors Who Used to do House Calls

So, come with me. Drop your headphones. We’re going to an old and faraway town, far-west style, cowboys and everything; or just to the place where your grandparents lived their entire lives. That will do, too. Let’s visualize what used to happen when people got sick.

It’s late. The streets are quiet, and there’s no visible moon in the sky, making it darker than most nights. Someone’s running to call the doctor. A stumble on the staircase, a knock on the door, a sleepy man grabbing his coat and medical bag, then following the night visitor.

The doctor enters the sick person’s home. The conscious look around the room, to the people in it. And then, finally, a myriad of questions followed by a close examination.

How is this better than a consultation from behind a desk?

Well, the doctor is there, taking everything in with his own trained eyes. This allows him to make better decisions. He can see the clues that we would miss, get the evidence for the symptoms, and talk to first-hand witnesses. A Sherlock Holmes for disease.

This Story Is a Sad One, Told Many Times

Research is a harsh word. Don Norman, one of the founding fathers of the user experience discipline would probably say the very sound of it is harsh, it carries emotional weight and feels ponderous, maybe dull. Re-search. Go look again, and again. Day and night. Go where you have to go. Do what you have to do.

“(...) more and more evidence piles up linking sounds to particular general meanings...Harsh sounds are, well, harsh—just like the word "harsh" itself and the "sh" sound in particular. Snakes hiss and slither; and note the sibilants, the hissing of the "s" sounds.”

— Don Norman in Emotional Design - Why We Love (or Hate) Everyday Things

Back from the old far-west, you start with research before actually starting research. Like the doctor who keeps the medical bag close to the door. Meeting with those who want the app built helps you define what it will take for successful adoption and for productivity and engagement to increase. By listening to them and recording their goals, you’ll know what to look for.

Seated at the table are the people who will be using your app. They’ll probably show you how the process runs nowadays, if they have an app that is not working for them, if they’re on paper and pen (oh yes, this is still real), or if they are running a business from Excel spreadsheets on a shared network folder (you’d be surprised).

Whatever the starting point, this group of people will explain everything. You’ll take notes, draw their workflows, feel lost in the jargon sometimes, but you’ll get the big picture. Then you’ll ask for more: Can we see some users in action?

— What do you mean? They’re right here. This is Linus, this is Eve. They know everything.

I bet they do, and they’re probably the best at their jobs. They’re key—key-users. But they’re sitting right next to their bosses, and maybe they feel a bit restrained. They’re relying on their memory so they’re filtering through their words what they usually do, not actually doing it. They’re here, in a meeting room, an unnatural setting, with strange people asking them peculiar questions.

Note that you can still hear things like:

— They’re stupid; what they have to say is irrelevant.

— I want this to be confidential.

— They’re too busy.

What can you say after this? You need to reinforce the importance of the conversations you had so far and clarify that you are not trusting your fieldwork to create a wishlist. You need to tell them you have to focus instead on what they do, rather than what they say. Observe. Not people doing demos, but doing their real work.

This means that if you’re doing an app to support a call-center operator, you’ll have to hear a few calls. You’ll note and register things like: “Linus is using a notebook to write down the customer’s name, opening internal links in different tabs to compare information, and being constantly interrupted by co-workers that need help.”

Such things shed light on their real pains and workarounds, the ones you’ll address in the new application. Then you mention the elephant in the room and play the adoption card: If they are resisting the current app or if they complain about missing or messy features, we need to fix all that so we don’t have the same conversation a year from now.

The User at Work

First battle won, now you get to interact with people when they’re working. The good thing is that we know who the users are, and we know where they are. Because we’re creating an enterprise app, this probably means you’ll have to go to a different floor, perhaps another building, or even some other town sometimes, to get your story straight.

This is called contextual inquiry, and you’re replacing laboratory work with a realistic setting. Start by focusing on your purpose: the main work process that you are redesigning and the business goals you gathered for it—for instance, improving efficiency or productivity, reducing error, or taking the look-and-feel into this century.

Enter the room with a plan but be ready to adapt. These are exploratory conversations; you don’t prepare too much; you don’t anticipate that much. Of course, there are questions that you always need an answer to, such as whether they’re using one or two monitors and their resolutions, the tools they use to do their jobs, or their tech proficiency. But it’s possible the answers will come while you’re observing them, so do that first and then you can ask anything you didn’t get later.

These are enterprise apps, and they will handle work tasks to help users do their jobs faster and more effectively. That is what you’ll try to infer from shadowing representative users (always individually), trying to find work patterns and common behavior, and understanding what they don’t tell you.

Are they tired? Is the room’s lighting too weak? Do they have to handle dense information? Compare numerical data, maybe? Are they resorting to calculations in spreadsheets? Printing lists? These are all clues to making better decisions.

To the Artboard

Back from the house call, you get to draw simple interfaces that can handle complex data, prioritize content, and show it in levels (or chunks) that reduce user effort, change behavior when it makes sense, automate where you can, normalize jargon from different departments, and a multitude of other solutions that alleviate or eliminate real pains.

Making better decisions means that you’ll probably ignore those users asking for replicated Excel or print buttons all over. Instead, you gave them new ways to work with information that don’t require mimicking old tools.

Along the way, people will tell you that:

— You need to focus on the functionality, not so much on the layout.

— This is the art of dashboards, data tables, and long lists.

— The most significant decision you’ll make is between pagination or infinite scroll.

— This kind of app is not about attracting users, but empowering them to do better and faster work.

Some of this is somewhat true, but, more importantly, users have Spotify installed on their phones, they have Trello or Asana to organize their work, and maybe Slack to communicate. So robust user experiences and delightful user interfaces are what they expect.

Come Back for More

Mix business goals with user needs, and something magical unfolds; you have screens that illustrate a better workflow and can make things smoother for everyone. Now, who are you going to show them to? To both the business and the users, of course.

It’s a hypothesis, a shot almost on target. But you’re not shooting blanks. You’ll refuse blind updates based merely on business requirements that damage rather than advance work. You’ll be getting better, improving your aim by going back to stakeholders for validation and to users for testing.

In the back-and-forth game, you will not make promises to users you cannot keep: not about timings, nor about features. That is not your job. You will not worry too much about people resisting change, because it will happen every time, everywhere. You will prepare to launch, have users as champions that feel they were part of the process, part of the healing process.

You will be the doctor, looking for clues and grasping full context. Don’t just trust the words. You will balance the time you spend in the artboard with time spent invested in the field, on guessing better, iterating, building on the experience. You will be ready to fail fast and fail better.

Until you fail no more.