When working with products or software tied to a complex domain—one that is not self-explanatory, like an instant messaging app—there is a high risk that new members of the design team will lack essential domain knowledge. This gap can impact the quality of their work and even their understanding of what “quality” means in that context. Imagine it’s your first day on the job, and you’re asked to design ARPA overlay settings in an ECDIS system for river users. Your most likely reaction? “What?”
The terms may be unfamiliar, the processes and efficiency criteria unclear, and the users’ needs, daily routines, market conditions, and regulations unknown. This lack of context can lead to disorientation, causing designers to focus on superficial aspects like colors and button shapes—whatever feels most familiar—rather than solving real user problems or generating meaningful UI flows. Additionally, when unfamiliar with the domain, newcomers may struggle to ask questions, especially if they feel self-conscious about their lack of knowledge compared to more experienced colleagues.
One might argue that domain expertise should come from subject-matter experts rather than designers. However, effective collaboration still requires a shared vocabulary and at least a foundational understanding of industry principles. Without this, discussions become inefficient, tasks remain unclear, and idea generation is stifled.
How to solve it?
Based on my experience in several companies, providing foundational domain knowledge at the start of a designer’s (or any IT specialist’s—tester, technical writer, or developer) journey significantly improves onboarding.
Domain Knowledge Overview
Domain experts, system analysts, product managers, and UX designers should prepare brief overviews of the domain. These should include:
- Key terminology and abbreviations
- An overview of relevant entities
For example, in healthcare, this might include hospitals, clinics, and emergency centers, highlighting their differences, internal structures, and key stakeholders. - Main goals and objectives of the industry
- High-level process overviews
Not just use cases, but broader industry workflows—for instance, in maritime navigation, what constitutes a voyage, how route planning works, and how trips progress from port to port. - People in the industry
Descriptions of key roles, responsibilities, challenges, and motivations—not just software users but also other industry participants. This should include education levels, competencies, and professional behaviors. - Regulations
References to relevant standards, laws, and compliance requirements. - Competitors
This foundational knowledge is, in my view, even more critical than product documentation. New employees will naturally learn product details through daily work, but without domain context, their efforts may become reactive rather than proactive. With a broader understanding, they can place specific tasks within the larger picture and, most importantly, ask better questions—because to ask, you must first know what can be known.
Additional Summaries
While concise product and user summaries (based on the “people in the industry” section) are valuable, excessive detail turns them into work reference materials rather than onboarding aids. One common problem I’ve observed is that employees often have a fragmented or nonexistent understanding of anything beyond the specific product they work on. This causes issues, especially in integration tasks involving multiple products.
Onboarding materials should also include:
- Names of product owners (POs) and internal experts who can provide deeper insights.
- Links to relevant technical documentation.
- UX reviews of existing products, highlighting:
- Which products are at the end of their lifecycle.
- Which are relatively new and must be supported consistently by UX design activities
- The design decisions and ideas behind them.
While introducing a design system is a standard part of onboarding, it is not the focus of this discussion.
These materials do not need to be lengthy, overly detailed, or written in a dry, technical style. Instead, they should spark curiosity and provide a broad rather than deep perspective. It is easier to dive into details when you understand the bigger picture than to piece together a fragmented view from isolated details.
Conclusion
This onboarding approach should not be the only internal knowledge-sharing initiative. Ongoing activities like monthly knowledge-sharing sessions, informal customer visits (to provide real-world context), and formal industry training at later stages are highly beneficial. I have seen cases where analysts and testers were sent to GMDSS and ARPA training courses alongside mariners just to gain a deeper understanding of the industry.
In my experience, this onboarding method is highly effective. The first time I implemented it for new UX designers on my team, a few months later, I received requests for the same materials from testers and even developers. It helped them align their ideas, understand the broader system, and contribute more effectively—despite limited resources.