Technical people are people too

Recently, I've been tasked to work on the redesign of many products that are targeted at technical users. Tools like network management or backup software. The initial engagement with those customers is almost always the same. They come to us because they have a competitor that has a “more modern” or better looking product. And they want to remain competitive.

However, the fresh coat of paint and new curtains approach is rarely the most effective approach to beat your competitors. Let's say your company has been putting out a product targeted at technical users. You've been doing it for years and you carved-out part of the market. Now, you're trying to distinguish yourself from your competition.

In any other case, improving the user experience would be a perfect way to get a leg-up on your competition. But your users are technical. They don't care for fancy user interfaces. They have spent time to learn your tool and are happy manually editing .conf files and working around the quirks of your software.

But are they really?

Although they are capable of figuring-out complicated technical products, technical users are just like normal users in many ways:

They have other things to do than using your product. Typically, using your product is only one of the many things that they are responsible for. They might have chosen your product because it is reliable and useful. But believe me when I say that they'd use less of it if they could.

By allowing them to perform their tasks more efficiently, you will delight your technical users to the point of evangelism.

They view your product using completely different goggles than you do. When you look at your own product, you see the way it is built inside. You see code and database tables and network connections. This often means that your user interface reflects this physical model or how your product works internally. Users, even technical users, see your product from their own angle. They see their network equipment and their servers and their offices and equipment cabinets. In other words, they already have a mental model of what your product should be doing.

If the Physical model you propose through your UI doesn't match the mental model that they expect, it will create extra work for them and increase learning cost for even the most technical of users.

How do we fix that?

Interestingly, the fact that you are targeting a very specific group of users is a good thing. The first step in the process is to validate assumptions about your product. Go to the users and observe how they use the product. Specifically:

• What are they actually using it for? (it might not be what you built it for)
• What workarounds have they built around your product's limitations? (sometimes, technical users maintain whole suites of scripts and tools to do that)
• What specific tasks do then need to get done often or in emergency situations

Armed with this information, you can enter an incremental cycle of design, test, build, retest until you are successful at delighting those technical users.

When the coat of paint won't do

Strangely enough, when I start work on a product with highly technical users, the request is almost always about making it prettier. However, especially with technical users, making it look good is probably the least cost-effective way to improve their experience. Technical users usually care about getting things done fast and accurately. They often can disregard an ugly UI if they can spend less time using it and more time getting other things done.