Skip to main content
Designing for Experts Without Being An Expert

Designing for Experts Without Being An Expert

Published by Aaron Nathan

While we consider ourselves experts in “the human condition,” we frequently find ourselves designing for people with expertise in areas for which we have little or none. Over the last several years I have worked as a UX researcher, designer, and strategist primarily in medicine and finance. So how did I, with little to no medical expertise, conduct research on and design products for some of the most specialized medical experts in the world?

First, I had to recognize that I am not, nor will be an expert in the topic at hand. What I can become an expert on is the cognitive process of the experts I am designing for. Experts can process loads of qualitative and quantitative information in an instant to provide unique solutions to complex problems. Our goal is to build a product that distributes some of that cognition to leverage the skills of these experts and supports their natural human weaknesses. I have broken this process down into 4 steps:


Targeted Ethnography - learn basic information, people’s roles, and network with experts.


Expert Knowledge Identification and Management - identify and understand the content necessary to support your users.


Content Delivery Design - leverage your knowledge management infrastructure to support the cognitive challenges you found in ethnography.


Validation of Trustworthiness - validate both your content and your designs to ensure that you will not lose the trust of your users.



This first step is about learning and networking. Usually the team you work with will include some people who are experts doing the work that your designs will support. Start by watching them do it and write down questions to ask later. If you can, expand beyond your team and include people more representative of your users. You need to know enough of the acronyms and jargon to start mapping out workflows and justify your design decisions.

So you need to be able to define any of the fields in a software interface. For example, you need to know that “10mg BiD” is the prescribed dose and a frequency of a medication. You don’t have to know what “BiD” means, you just have to know where it fits in the information architecture at the highest level so that if someone says it in an interview, you know that’s a frequency. When you first start a project, you will need to develop fast friends with experts on your team because you will depend on them early and often to assist with this learning curve.


Through the ethnographic work in step one you will have learned where the users’ cognitive distribution needs are but your ability to provide cognitive assistance to experts depends on your ability to first deliver accurate content. Experts tolerate bad UI but will not tolerate bad content. If a prescriber notices any inaccurate information in a newer product they will stop using it. The visual design of UpToDate (a medical reference software) violates every Nielsen heuristic and is still the most used medical reference software in the world because physicians trust the content.

Now you need to know where you are going to get that content as well as the affordances and limitations of that source. For this you need to have a good relationship with your development team, content/knowledge “vendor” (internal or external), and expert users. Whether you are using internally written content or using a knowledge vendor, you may have to work on infrastructure to supplement the content. These people will help identify those affordances and limitations so that you can either fill in the gaps or at least create a self-aware product that accepts its own limitations. If there is no industry-wide or organization-wide consensus in an area, do not claim there is because experts will stop trusting the product quickly.

If you are not working with established content databases, you may need to work on your knowledge elicitation skills. Knowledge elicitation is a broad and heavily debated topic, which would require its own blog for sure. For your purposes you need an accurate enough picture to be able to determine the form factor for delivery and defend it.


There are two unique aspects to designing products for expert users.

  1. Experts inherently distrust new tools that claim they have anywhere near the expertise that the experts do. Design in transparency to establish trust. In instances where a product is influencing the decision of an expert, the reasoning for that has to be obvious when the expert first starts to use the product. As they begin to trust the product, you can default to hiding that logic, but still make it available.
  2. In my experience, experts are particularly change-averse. These people have such ingrained workflows, small change is hard especially since many experts have gained their expertise over a period of decades. I have seen that experts are more likely to work later in life because they have chosen expertise in an area of passion for them. It is important to validate that this is true with your users, but scaffolding major changes can help that audience adjust.

With those two factors in mind, your ethnography and knowledge management exploration will inspire how to design for trust. Utilize a thorough competitive analysis and investigation of analogous experiences to inspire innovation of expert support. I have found The Best American Infographics of 2016 to be helpful as an ideation tool.


Usability testing early and often is a challenge with this type of interface. Integrating complex data into prototypes often requires as much of a lift as just building the actual tool. Sketch has gotten better about their ability to integrate database data into prototypes, but we are far from where we need to be to churn out quick iterative prototypes for complex systems. As with any design project, identifying and questioning your assumptions for each design will help you determine how much concept validation is possible, useful, and ultimately worthwhile before fully developing a product.

With these types of products, trust is everything. As a result, you are less concerned with whether someone will find something and more concerned with validating that someone will trust what they find. As a result, reducing bias in your usability testing and design process is paramount. Self-awareness, team transparency, and mutual accountability will provide the environment you need to validate how trustworthy your product truly is to your users. Losing that trust is potentially irreparable, so tread carefully.

Starting the process of designing for experts without being one is daunting but there is no more rewarding type of product to succeed at building. After the first two steps it will be much less daunting and you will develop the confidence to make decisions. Trust that confidence but remember to stay aware of the fact that as much as you may learn about the expertise of these people, they are the experts for a reason. For me, designing for experts has been an amazing way to help loads of people while being a passionate designer and researcher. Just stay diligent, and as they say in Philadelphia, trust the process.

Aaron Nathan

Formerly a Research Associate at the Bentley User Experience Center, Aaron is currently a Service Designer at Mayo Clinic where he looks for innovative ways to use cognitive science and user-centered design to improve provider workflows and health outcomes.

Aaron has a bachelor of science in Psychology from Clemson University and a Masters of Science in Human Factors in Information Design from Bentley University. His background is in mental/behavioral health and research.

These words reflect the thoughts and opinions of the author alone and do not reflect the thoughts or opinions of The Mayo Clinic.

Let's start a conversation

Get in touch to learn more about Bentley UX consulting services and how we can help your organization.