Depends heavily on the user community, use case, time-in-environment (short- and long-term), inter-user communication
about application, and rate of change. There's almost certainly a set of interrelationships between these.
For a highly technical userbase, a highly bespoke UI may be defensible,even preferable, especially:
- User community is expert, highly skilled, and highly computer-literate.
- If daily-weekly time-in-environment is high. User "lives in" application.
- If lifetime time-in-environment is high. Users base career in application.
- If there's relatively little communication between users about application state, interactions, or activities. Put another way: users interact with the app, but not about the app with others (users, clients, management, techs).
- The UI avoids drastic change over time.
By contrast, reverse virtually any of these conditions and you'll want a UI that conforms closely to current standards:
- Users are inexpert, poorly computer-literate (the vast majority, see OECD computer skills study), or simply nontechnical with app.
- Time-in-environment is low. At the extreme, all users are one-time novices.
- If users must communicate with others regarding app state or tasks -- close management, team interaction, client / management interactions. All parties need a ready and clear mental model of the UI and state.
- If the UI changes drastically over time, it should do so consistently with all other major elements. (Both should change as little as possible.)
Somewhat more concretely, the absolute worst feature a UI can have is change. Users get confused, lose trust, and are burdened by obsolete knowledge. This afflicts both expert and nonexpert users, profoundly, though in somewhat different ways.
For very technical tools used principally creatively --- virtually all editors, development environments, and many reader/browser/search/analysis tools fit this description --- a highly distinctive (and customisable) interface may be appropriate for advanced users. This is a small, but generatively critical, user community. There's a requisite complexity to such tools, simplified UI comes at the cost of vastly less efficient performance.
Virtually all "weird" tools in heavy use today evolved from what were at the time of their creation, common motifs, at least within the environment of origin. Think of Unix, vi, emacs, Photoshop, Excel, and Eclipse, say.
For standard workflow, control, and transactional tools, highly standard UIs are preferred. Here, users are interacting closely with others regarding state or interactions with the interface, and clarity, consistency, and common knowledge of the UI and state changes matter. Point-of-sale systems, equipment controls, general monitors, enterprise applications, end-user/customer support tools, and the like.
Occasional-use, public use, and similar tools must be generally usable without training. Adherence to standard motifs is critically important. UIs and capabilities are generally simple.
The trade-offs:
- More expert users and more heavily-used tools can support more novel UIs.
- Less literate users, more unfamiliar tools, and greater communications about UI state and interactions, demand more standard UIs.
- Change is generally bad, but evolutionary change (within the tool) or conformant change (with the overall environment) are generally less disruptive than either sudden drastic or idiosyncratic changes.