If you're working closely with a city and designing an application to solve a specific problem (e.g. in the context of the Fellowship), don't invent logos or brand names yet. Not until you're ready to make a standalone product or company out of it, and especially if your tech solution is to streamline, improve, replace, or add on to an existing city's service. The normal citizen user, who may not be tech-savvy, isn't going to want to remember that this service they relied on previously is now a "different app" with its own name and brand.
Apps and services that were named weird things were a side-effect of limited unique domain names, and it became trendy to do it on purpose, but look through your own phone: how often do you install an app with a trendy name only to not fully remember what it does? how often do you struggle to recall the weird name of that "one site" you occasionally use? Now imagine that's a user who's not as smart as you.
Google (apart from its original weird name) doesn't try to brand its services. It uses simple, common words that describe what it idoes, e.g. Search, Mail, Maps, Drive, Translate. Meanwhile, Microsoft Bing. What?
In a similar vein we sought to keep Las Vegas app names simple: Las Vegas Food Trucks, Las Vegas Development FastPass. And I think "Oakland Public Records" as the name of the specific deployment versus "RecordTrac" as the brand name was a good way of doing it, but at some point that became mixed up.
Larger thought, maybe a different topic: when designing (for aesthetics or experience), think in the broader context of the city's needs. If they already have pretty decent design guidelines, by all means use it, or extend it. If not, think about creating elements that could inform reuse by other services. Think how GDS/Gov.UK creates its services. Think about your design as an influence on how other city services could be provided by that city, rather than as a standalone application.
Work in progress thought.
If you're working closely with a city and designing an application to solve a specific problem (e.g. in the context of the Fellowship), don't invent logos or brand names yet. Not until you're ready to make a standalone product or company out of it, and especially if your tech solution is to streamline, improve, replace, or add on to an existing city's service. The normal citizen user, who may not be tech-savvy, isn't going to want to remember that this service they relied on previously is now a "different app" with its own name and brand.
Apps and services that were named weird things were a side-effect of limited unique domain names, and it became trendy to do it on purpose, but look through your own phone: how often do you install an app with a trendy name only to not fully remember what it does? how often do you struggle to recall the weird name of that "one site" you occasionally use? Now imagine that's a user who's not as smart as you.
Google (apart from its original weird name) doesn't try to brand its services. It uses simple, common words that describe what it idoes, e.g. Search, Mail, Maps, Drive, Translate. Meanwhile, Microsoft Bing. What?
In a similar vein we sought to keep Las Vegas app names simple: Las Vegas Food Trucks, Las Vegas Development FastPass. And I think "Oakland Public Records" as the name of the specific deployment versus "RecordTrac" as the brand name was a good way of doing it, but at some point that became mixed up.
Larger thought, maybe a different topic: when designing (for aesthetics or experience), think in the broader context of the city's needs. If they already have pretty decent design guidelines, by all means use it, or extend it. If not, think about creating elements that could inform reuse by other services. Think how GDS/Gov.UK creates its services. Think about your design as an influence on how other city services could be provided by that city, rather than as a standalone application.