Hi Sophia - I’m Harry (a fan), great article!

I agree that identifying the nouns in the thing you’re designing and exposing those nouns in labels etc. is a solid strategy; that is, understand the domain, and design the thing with a solid understanding of that domain and the ‘stuff’ that makes it up.

However, I’ve found limits to this strategy when tackling the extremes - such as very broad domains (e.g. government services) or very focused products (e.g. maybe when you’re designing a very focused app that does only one thing).

For the broad domain, I find myself forced to be too abstract. E.g. for a local government, you could have objects like “places” (parks, libraries etc.), “projects” (development proposals, policy revisions, maintenance work), and “services” (anything from registering a pet to ordering a new waste bin). Because there are so many different things, to go even slightly more granular means a very big domain model, but to remain at this level results in significant generalisation.

There’s also that gov.uk axiom that’s often quoted “good services are verbs, bad services are nouns”, referencing the “thing” in a government service is often pretty alien, e.g. it might work better to label a service as “get permission to build or renovate” rather than “development applications (DAs) and complying development certificates (CDCs)”.

I don’t know where I’m going with this, anyway, more after your thoughts - what’s your view on OOUX in the context of these broad and diverse domains, as well as in super focused domains?