Yes, that seems reasonable. If the intended audience does not understand the terms of your language or misinterprets them, then the usability for the enduser takes precedence.
A program or content that a typical user does not understand is of little value. More so, if you only want to present them a simplified tip of an iceberg because they are not and never will be domain experts.
Normally, when you talk about the domain during development then everyone understands the language because it is accurate and all people are within the domain. But if business value is created by communication of content to outsiders of the domain, then do this as simple as possible. Use wordings and languages which are the least likely to be misunderstood and use them in the UI.
Keep the accurate language in your code and for communicating with people who are concerned with the domain. These are the people who have the specs and who are the key users of the applications, the ones with whom you discuss the business logical details. In the rare case that you really discuss most of the business logical details with users who don't have much of a clue about the domain and you needn't dive deep into it, then incorporate their language in your domain language, given that they have a common, unambiguous language at all (which probably isn't the case).
But do make sure that the frontend devs know about your informal terms and their corresponding domain terms.