Designing Interfaces for Experts
UX lessons learned from designing complex interfaces for scientists, analysts, and the likes.
If you’ve ever wondered what goes into building applications used in professions like data analysis, experimental sciences, or satellite status monitoring, you’ve clicked on the right article. Designing for experts can seem intimidating at first — how could a designer make a tool to be used in an area that might take an advanced PhD to understand? Yet, there is a way.
My name is Alicia Frudakis and I’m a UX designer for RS21, a data science, AI, and visualization company out in the desert — Albuquerque, New Mexico to be exact. As someone with a background in environmental science and agricultural biology I absolutely love the challenges of working on awesome data-driven, almost sci-fi inspired projects (Yes, I loved the movie Interstellar).
In my time here I’ve worked on a series of interesting projects where end users included everybody from electromagnetic engineers, to cancer researchers and crime data analysts. While each project has been a unique journey, I’ve noticed a trend in what works best when designing for experts and I’d like to share what has worked for me in the past.
What Makes a User an “Expert?”
The Difference Between Domain-Specific and Generalist Users
Specialized vs. Generalized Workflows
One difference is that generalist users generally complete routine tasks that don’t require the same level of scrutiny and experimentation that experts are required to give for their tasks.
Take for example the Uber app. Made for the general public, it’s intuitive and does one thing — matching riders with drivers — very well.
Contrast this to an interface built for a specialist or expert. This app might be used to test multiple scenarios at once. It will most likely need to exist in an already complicated ecosystem of other interfaces, databases, and processes. It will probably need to provide actionable insights for highly variable scenarios with many parameters or influences, too.
A domain-specific app flow has a flexible finish line that allows for specialized experimentation and iterations versus generalized app flows, which have well-defined finish lines.
Higher Stakes
Stakes are often higher for expert users. We all remember the 2018 missile scare in Hawaii, right? Placement of the option for the drill and the real alert broadcast were not visually distinguishable, and so the poor technician picked the wrong dropdown option. This sent everyone living on the Hawaiian Islands into panic mode thinking a real missile alert had been issued. This is just one example of how expert users can be responsible for making decisions that impact people’s immediate lives.
They could also be responsible for using specialized equipment safely and effectively, or perhaps deriving insights from data that inform long-term public policy, immediate action, or expensive financial decision.
So design decisions really matter here!
Working with Sensitive or Private Data
Expert users can be found working for government agencies or national laboratories, and we can’t always see their raw data or talk to end users. The data is private for good reason — I’ve worked on projects that pertain to national infrastructure resilience, or even protected health information (PHI). In these instances, we design with dummy data. The applications are only populated with real data when we hand over the finished product to the client, so it’s crucial to ask for dummy data representing the most complex scenario to make sure the interface can handle the real deal.
A Summary of Interface Requirements for Experts
Many differences are found when you simply look at what an expert user requires from their system. From what I have observed so far, they need to dive deeper into a problem space or task than a generalist user. That means the interface must:
- Support domain-specific users, knowledge, processes, and workflows
- Handle, manipulate, and experiment with large datasets
- Provide insight for high-impact or high-risk decisions
- Be efficient, but still flexible
- Allows for easy sharing of summarized results
8 Lessons Learned
Now that we’ve identified some key differences in domain-specific versus generalist users, here are some of my suggestions on what works best when designing for and with experts.
1. Design Education
This might be your client’s first time working with a UX/UI designer, and it might be their first experience with user-centered design thinking in general. The design process may be foreign to them, and because it likely differs from their typical research process, they will want to know the point of abstract exercises like ideation or wire-framing.
The best thing you can do is to educate clients on the design process ahead of time. Tell them what will be accomplished at each phase, what to expect at each workshop, and the purpose of each deliverable.
The truth is, they may not initially understand the value of design — but don’t get discouraged. It’s our job as designers to introduce them to our world, just like we need them to guide us through their domain to make products that fit seamlessly into their workflows.
2. Collaborate with a Subject Matter Expert
Having a representative of users at the design table can be highly beneficial for the designer when access to information or data is scarce, as referenced earlier. Think of the subject matter expert (SME) as the needle on a compass; they’ll point you in the right direction as you navigate through a new domain.
SMEs are great to have during the interviewing phase because they can help you translate what you heard or saw. Having an SME to digitally whiteboard with can help a designer create a strong hypothesis for what might work for users. These topics are discussed in the following sections.
As a designer you won’t be able to replicate their domain expertise, so SME participation and critique is crucial in making sure your concepts truly fit into the user’s reality. This type of collaboration requires patient, kind, and thorough communication from both parties.
You can look for an SME in your client, your internal team, or even hire an external consultant in the domain. While it can sometimes be a challenge to find an SME, it’s well worth the time spent and will save valuable time, energy, and budget in the long run.
3. User Interviewing Tactics
The first thing you need to work out in discovery is how the thing is supposed to work. Expert users are rightfully goal oriented. They need to get tasks done as part of their jobs, and they might not understand the goal of the interview if you start off by asking them how they feel about processes or tasks they can’t really opt out of.
Example of something I’ve asked in the past:
“How do you feel when you begin Tasks A and B?”A Typical Response: “Well it doesn’t matter because I have to do both anyways or I won’t get my results. It’s my job to do both.”
Try this instead:
“What are some challenges you face when completing Task A?…What about during Task B? …What are your least favorite parts of those processes and why? …Where do you see areas for improvement in terms of efficiency? …Is there information you repeatedly input or can’t find?”A More Informative Response: User opens up and shares thoughts and details about their work and domain.
Just assume they encounter obstacles, because most of the time they do! It also shows you acknowledge the complexity of their jobs and are invested in their success as much as they are.
So ask questions that help you understand what the user needs from the interface first, and ask questions that help you make the experience enjoyable afterwards.
Find the pain points and understand why they are pain points. Understand what is important to them, whether it’s the end result, configurability during the process, or integration with existing systems.
Even by just simplifying their processes you can create a better experience for these users, so ask lots of questions about how they do things and the inputs/outputs of those actions. You can ask “how did that experience make you feel?” to dig into how to create a happier flow after you ask “what do you need this interface to do and how?”
4. Translating the Science
Naturally, SMEs can have incredibly complicated, domain-immersed, and jargon-filled processes. You’ll need to understand the user’s mental model to provide an intelligent design solution.
This means you will need to put in some extra work to translate these processes into layman’s terms. Annotated wireframes are a life saver here. This is important because you have to be able to explain design logic for why you set up a user flow the way you did to both the domain-specific client and your design team.
Another good idea is to keep a glossary of specialized terms and update it as you learn new domain vocabulary. This is a great resource for on-boarding someone new, or just keeping yourself sane.
Become curious about the domain. For example, if it’s advanced physics, brush up on some high school level physics. This also helps you have more educated conversations and collaboration sessions with SMEs who live, breath, and eat their domain topic.
5. How to Ideate Remotely
Figma has been a great online tool for intra-collaborative wireframing, and Invision Freehand and Mural are great options for white boarding/sticky noting remotely with users. When it comes down to ideation strategies, creating different design options for SME critique via preference testing works better in my experience than asking users to talk about potential possibilities.
“What we covered is really good — this is the most interesting discussion I’ve ever seen on how we complete user help, and the functionality of export versus save. As we go in these exercises, I find gaps in my own understanding. This is really valuable.” — An SME on preference testing
If you provide the SME with some creative ideas based on what you heard in interviews, they can almost always discuss with you the pros and cons of your designs from a user’s perspective. This is a simple way to extract more UX rationale from your user base, and it can be done completely remotely via slide deck presentation. It also gives users a strong voice in the design process, and gets them excited about the end product (which as a designer is a reward in itself).
Lastly, bake in some time in case there are technical difficulties. Not everyone uses the same tools, so they might have to create a new account or some direction on how to use it. Always check that tools like Mural, Figma, or Invision Freehand can be used by the other party as well, since some organizations may not allow their use for security reasons. Microsoft tools are usually approved, although not as robust as other tools.
6. Quantitative + Qualitative Data
Being able to provide numerical or statistical data when it’s time to share results of user testing or usability testing will help communicate the impact of UX and UI to expert audiences. The reality is they may have reservations about qualitative data at first (as many of these professions are driven by quantitative data), but as a designer it’s up to us to show the value of qualitative data. An example of this is using direct user quotes from interviews to justify design choices and explain trends or patterns in experiences.
7. Deliverables
Polished, white-paper style formats can work very well here, given that it’s a style often used in academia (where many expert users may have spent a considerable amount of their time). However, different design studios have different ways of crafting deliverables which is based on their branding or style of communication.
A typical deliverable designers create is the persona, which is very useful in helping stakeholders empathize with users. However, if your user base for a very specific app are also the stakeholders and include 8–10 people it might be as useful as holding a mirror up to them. In a case like this, a persona helps the designer more than the user base and wouldn’t provide a whole lot of value as a deliverable. As always, use your own judgement as to if it’s valuable to share or not.
What has worked for me is delivering a discovery summary, ecosystem maps and workflows. The discovery summary captures the rationale behind the designs. Include quotes from interviews organized into themes that were revealed in affinity mapping. Ecosystem maps and task-based user flows can show a “before and after” effect of reorganizing complexity to be manageable, as well as illuminate a process and the inputs and outputs holistically.
However, if the client is also the SME, a polished summary style white paper may just be re-iterating smaller scope deliverables they already received along the design journey.
The bottom line is your design rationale should be formatted in a way that is familiar to your client and clearly shows what informed the design decisions. Include both qualitative and quantitative data when possible to show the end product is well-rounded. Cadence and scope of deliverables will vary depending on the project.
8. Admit When You Don’t Know Something
Be humble! They’re the expert because they’ve spent a considerable amount of time in the domain, and you’re not going to fully understand something like complex physics or advanced genetics as a designer. And that’s ok!
SMEs and expert users will know if you’re unsure about how something works or if you don’t really understand a user flow, so don’t be afraid to ask for clarifying explanations multiple times.
Experts depend on us designers having a clear idea of what the basic steps in a process is to represent it correctly in an interface. This is where soft skills (which aren’t really “soft” at all) like communication come in handy. I usually say something like:
“So I understand the process up until Step C. Could you explain this process again to me, maybe at a high-school level?”
And then I repeat a summary of what they say back to me to make sure my understanding matches their reality.
“So what I’m hearing is you do X to get Y, and then Y is input into process A using tool B to create Z. Is that right?”
Showing that you’re putting effort into understanding can be displayed by repeating back what you do understand, and attempting to explain what you’re missing (even if you know it’s wrong). SMEs and experts will appreciate your effort to understand, and they are usually happy to explain again if you misunderstood something.
Conclusion
UX/UI design can sometimes be thought of as a luxury — something that big tech companies with a plethora of money to spend implement to make their product extra nice.
The reality is UX can be the bridge between information and informed action, as seen in its application in the realm of data visualization and scientific modeling:
“…Visualizations still hold the power to relay visceral imagery to the public in a way that helps them understand science. But as supercomputers expand the ability to combine complex models, these scientific visualizations will play an increasingly crucial role in science itself. Because as the questions posed grow more complex…so must the tools used to find answers.” — John M. Patchett, Albuquerque Journal
Good UX is especially important in data-driven and scientific fields because of the impact these disciplines have on people’s lives. Having intuitive and informative tools that enable us to experiment with, maintain, or analyze data and information is not a luxury; it’s a necessity.
Next Steps
If you’re starting from zero experience, I would recommend learning the UX basics through a bootcamp, certificate program, or mentor. If you have a grasp on the basics, a great resource for those wanting to learn more about designing for expert audiences (which I ended up completing after writing this article) is Nielsen Normans’ Designing Complex Apps for Specialized Domains seminar. If this is out of your budget, I recommend browsing for design case studies and portfolios of designers that have worked with clients like NASA, NOAA, government agencies and labs, and the like. Or reach out to designers who have worked in this space on LinkedIn, too!
Thank you for reading this far down! My goal with talking about my experiences here is to inspire discussion in an area where resources and examples are sparse. How do you design for expert audiences? Do you have any lessons you’ve learned designing in this space? Is there anything I missed or that you’re interested in hearing about? Let me know! You can find me on LinkedIn.
I’d love to create a living library of domain-specific case studies, so if you have one you’d like to share publicly drop a link in an email to me at alicia@rs21.io.
