Do internal products need UX experts? The answer is obvious. Or is it?

I suspect if you asked a collection of people who work in IT, you’d get just as many people who say that UX experts aren’t necessary as you do people who say they are.

I’d suggest the former group is wrong.

I’ve always had the impression that internal products can gain a great deal from the involvement of UX experts, even though most companies don’t act like they are necessary.

Over the past few years, I’ve had a variety of experiences, both good and bad, that have confirmed my impressions. I thought I’d share a few of those experiences.

Personas can be helpful, when you use them

​Personas have, somewhat rightfully, earned a love hate relationship among people in the IT community. They offer the opportunity to get a deep insight into your users that can influence design decisions for your product.

Or they can turn into an opportunity to talk about your users behind their backs and write some stuff down that you never look at again.

I’ve experienced both.

When I was part of the team redesigning the website for a professional association, we started the work with a weeklong discovery workshop. As part of that session, we did an exercise where staff members worked alongside our design agency to come up with the key personas for the website using a technique from the book Lean UX.

Unfortunately, those personas weren’t based on any direct research into the organization’s members, it was all based on staff’s impressions.

We must have been able to tell the personas would not be too helpful, because we rarely used those personas after that initial workshop. The infamous create a fancy document then shove it in the drawer.

That experience left an unpleasant taste in my mouth for personas.

So when I started work to rebuild a 20-year-old system that priced production inputs, and Kara the UX designer on the team suggested we do personas, I was skeptical.

Fortunately, Kara undertook extensive research on the users of the system we were rebuilding, and uncovered some key nuggets that factored heavily into our design decisions. Probably the biggest revelation is that we needed to be very intentional about how we designed the system to minimize the chance of data entry errors.

Remember, user experience is not just about user interfaces, it's about all the user's interactions with your product, even the processes that your product enables.

The Power of the Prototype

While working on that same product, Maggie replaced Kara as the UX expert on the team.

I learned tons from Maggie, but the key thing was how to use prototypes along with conversations with users to get a sense of whether you’re making the right design decisions.

I remember one particular discussion that while a little embarrassing saved us several days of development time.

We were putting together a user interface that would allow staff to change individual prices from different grain elevators. The approach we initially thought would work was to display the current prices for all the elevators on the same page. Then if staff wanted to change a value, they’d click on a particular price and it would open a dialog box where they could change it.

Maggie created a prototype for the interface and then we sat down with our users to talk through it. Mike, one of our users, took one look at the prototype and said “This would be terrible. It would take me all day to make updates!”

We had forgotten to account for how many updates they’d have to do daily. It was definitely a face palm moment for Maggie and I.

Fortunately, we had started no development work on the interface yet, so we could change the design of the interface before the developers started working on it. The new design allowed Mike to change the prices directly in the list.

Don’t lead the witness, or the user

Maggie also taught me some hard lessons about the proper way to conduct usability testing - which is a fancy word for the sessions you have with your users when you want to get their feedback on a prototype, or actual product.

The most important lesson: do not, under any circumstances: ask leading questions or tell the user how it’s supposed to work.

Instead, show the user your product, or a prototype, and then ask them how they would go about using it to accomplish some task.

Then shut up and listen.

You’ll learn a great deal from watching people struggle with your product and what they’re inclined to try when using your product.

I instinctively knew that and tried to apply that approach when I did usability testing for the Agile Alliance website, but it was very enlightening to watch Maggie in action when she facilitated usability testing sessions. She took the usability testing practice to a whole new level.

UX has a place in internal products

Those experiences told me that while I understand some UX basics and can do a passable job with some techniques, I’m better off working with experts when I get the chance.

Likewise, the next time you work on a product with any significant user interaction, make sure you have some UX expertise on your team. You’ll be glad you did.

Thanks again for subscribing to Inside Product.

If you have any comments or questions about the newsletter, or there’s anything you’d like me to cover, just reply to this email.

Talk to you next week,

Kent J. McDonald
Founder | KBP.Media