At NORMAN AND SONS, we spend a lot of time designing for expert users in financial services. It’s challenging to design for people with deep domain understanding, but certain pitfalls can make things more complicated than necessary. Here are my observations on common issues I’ve seen in the research and design process in financial services organisations and how to avoid them.

‍

Pitfall 1: using best practice as a substitute for research

‍

In the commercial world, I’ve seen form completion increase after making common-sense improvements. For example, adopting a one column layout for form input fields, or adding labels. Best practice guidelines like these are easily available online and it’s totally sensible for large, consumer-facing organisations to use them.

‍

So why not apply the same logic when designing for expert users? It’s important to recognise that most UX studies are based on infrequently used services, like an e-commerce site that someone might visit once a year. By contrast, internal tools are used by seasoned experts every day. This isn’t to say that best practice isn’t a good starting point, but if you ever find yourself justifying your design decisions with a generic study, make sure that you’ve validated the idea with your users.

‍

If you know where to look, there are some brilliant UX case studies and research papers that are specifically about internal tools. On a recent project, I used a multi-monitor use research paper alongside user interviews to help improve my designs.

‍

Pitfall 2: doing exactly what the expert users say

‍

Expert users often come up with a lot of ideas about how to solve a problem. These suggestions might sound like this:

‍

Can you add a yellow dot next to these numbers?

Could I have a keyboard shortcut for this option?

‍

These are valuable insights, but not necessarily good solutions. User researchers dig into these comments and identify the underlying problems, which might actually be:

‍

Can you add a yellow dot next to these numbers? : I need to know when someone changes something

Could I have a keyboard shortcut for this option? : I do this all the time, so I need an easy way to perform this

‍

Sure, a keyboard shortcut might make the action faster, but is there a better way to solve this? Could this action be automated based on a previous action? Does having a lot of keyboard shortcuts increase the chance of user error? A quick evaluation of different options might save users a world of frustration in the long term.

‍

Pitfall 3: nominating one champion to provide feedback on behalf of the team

‍

I’ve often seen businesses identify a team champion to direct improvements to tooling. This is well-intended, but most champions are relatively senior and don’t have time to sit down with people on their team and address the issues they have with a system. As a result, their views are overrepresented, while the needs of other team members are underrepresented. At worst, a champion can even feel pressured to make up feedback, which is a waste of time for everyone.

‍

Even in the world of expert users, it’s important to acknowledge that there’s a sliding scale of experience. Junior team members might not feel comfortable disclosing what they find difficult to other people in their team, but their insights are often some of the most valuable due to their lack of bias towards existing tools.

‍

To mitigate these issues, researchers usually conduct multiple one-on-one sessions. However, if research resource is limited, ensure that you encourage all team members to provide feedback organically.

‍

Pitfall 4: designing for expert users with a working group

‍

From what I’ve seen, businesses tend to defer complex problems to large working group meetings. These usually consist of stakeholders, users and technologists. Of course, big decisions require all these people, but conducting the entire discussion in a meeting like this can cause individuals to not feel heard, become defensive or conform to whatever the most senior person says. To ensure success in these meetings, you need to lay some groundwork, which often solves the problem before the working group is even required.

‍

For example, I recently worked on a system where the goal was to consolidate a workflow performed by two different teams simultaneously. Having conducted one-to-one research sessions, I knew there were strong feelings about which team should own steps in the process once it was unified. By bringing representatives from each team together, neutrally presenting the research findings and acting as mediator, the users quickly came to an agreement on this very specific problem.

‍

Designing for expert users is challenging, but it’s incredibly rewarding to make people’s jobs easier. I hope these observations are useful to you in your organisation and please don’t hesitate to get in touch if you want to learn more.

‍