January 28, 2016

As the product owner finished the 20-minute demo, she braced herself, took a deep breath, and said, “Ok, what questions do you have?”

This is the moment she always dreads. The twenty or so high-profile users on the call are an extremely opinionated and critical bunch. No matter what her group has built to please them, they always have list of why it won’t work and how it’ll make their lives more miserable.

Which is why, this time, it was so weird. They weren’t saying anything. She only heard silence.

She knew they were there. They had interrupted the demo with clarifying questions, so she knew they were paying attention.

“Hello? Y’all there?”

The phone erupted with twenty or so, “Yup” and “I’m here” pronouncements.

“So, no questions?” she asked staring at the speaker phone as if it was going to jump up and bite her.

A voice replied, “Not from me. It’s exactly what I expected. Good work. I’m excited about where you’re taking this.” Other voices agreed.

She’d silenced the critics. It took her a few minutes to soak that in.

Seeing the Users Work, First Hand

What made this demo different from previous ones wasn’t the demo itself. It wasn’t that they’d built anything different. What made this time different was how much more the team understood about the users’ work processes and activities.

Months earlier, the lone designer on the team had wrangled a site visit. Instead of going by herself, she cajoled a product manager and a couple of developers to go with her.

They showed up in the field office to watch their users, the field representatives, do their jobs. Even though they’d been working on this project for a while—for some, it had been years—this was their first exposure to how the users did their work.

It was amazing to watch. They saw so many things different from what they expected.

Field reps, who often worked directly with the business’s customers in person or on the phone, would often write down important data before entering it into the system. The team learned the fields on the screens showed up in an awkward order. Interviewing the customer, writing down the data, then transferring it to the screen created a more natural conversation.

The team watched field reps frequently write down information that was on the screen, only to fire up another part of the application and type it back in. “Old school cut & paste” they called it. Of course, there was a lot of cut and paste, though you can only move one thing at a time that way, and often the users need to move more than one field’s worth of data.

This was only part of what the team saw on that visit. They witnessed bespoke spreadsheets to make calculations the application expected the users to do in their heads, saw users jumping furiously around screen instead of following the expected flows, and witnessed a lot of cursing when the application did something unexpected.

The team returned energized to make changes to their own process.

Developing a Shared Understanding

Upon return, the team noticed something interesting. Developers and product managers who had been in the field were coming up with better design ideas than those who hadn’t been there.

This put a program in place to get every developer and product manager out to watch the field agents work. As each team returned, designs started to improve.

It wasn’t easy, getting all these folks into the field. It took some selling. Because many of the developers were outside contractors, their contracts needed rewriting to give them time away from coding.

Hagan Rivers, who specializes in redesigning complex enterprise apps (we think of her as a enterprise app whisperer of sorts), says meeting with users is essential. ”You have to be touching base with your users regularly, constantly, so that you understand their pain points.”

Better Developer-User Collaboration

The team adjusted their sprints to review each user story for UI related elements. Any story that touched the UI was now reviewed by the high-profile users—those folks who would be on that demo call who were the team’s subject matter experts. The developers would create a mock-up of what they think the design might be, contact a few key users, and go over the story.

Because the developers had been in the field, they knew how to ask the questions and understood the answers they received. The key users continued to help the team with their shared understanding of how the field agents worked.

Injecting Feedback and Learning Throughout the Project

When it was time to present the project in its almost finished state, it was not a surprise this time. The subject matter experts had seen the project evolving. They had injected their experience and knowledge, making the developers smarter.

Most projects wait until the end (and sometimes until they’ve shipped) to learn what the users’ really need. In this project, the visits to the field reps triggered a chain of events, leading to a smarter, more-informed design process. Field visits became a catalyst for better design.


With knowledge of your users and a toolbox filled with design patterns, you can simplify your enterprise applications and ship something that is truly delightful. Join Hagan Rivers in her full-day workshop, Enterprise Apps: To Boldly Simplify Where Nobody Has Simplified Before, to fill up your toolbox with a rich collection of techniques and methods.