{"id":13229,"date":"2017-08-16T16:30:09","date_gmt":"2017-08-16T15:30:09","guid":{"rendered":"http:\/\/blog.intercom.com\/?p=13229"},"modified":"2020-07-30T12:57:52","modified_gmt":"2020-07-30T11:57:52","slug":"naming-operator-bot","status":"publish","type":"post","link":"https:\/\/www.intercom.com\/blog\/naming-operator-bot\/","title":{"rendered":"Naming a new product? Start with the job."},"content":{"rendered":"

Any word can be powerful, but names are transformative. A good product name gives that product a certain shape \u2014 for the team designing it, and for those who use it.<\/p>\n

To choose a memorable name for a product, start with the jobs you want people to associate it with.<\/p>\n

A name can help people create a mental model for your product, which helps them to remember and associate your product with a particular job.<\/p>\n

Other factors come into play, including how a name sounds, and how distinctive, appropriate, likable, extendable, and protectable it is. But most important is that the name is remembered and understood.<\/p>\n

So to choose a memorable name for a product, you can start with the jobs you want people to remember it for.<\/p>\n

Who needs to remember the name?<\/h2>\n

Operator<\/a> is a bot we designed to do simple, straightforward jobs. In fact, we didn\u2019t start out with the aim of designing a \u201cbot\u201d at all \u2013 we started with the jobs first.<\/p>\n

As we began research into the bot that would grow up to be Operator, we learned that, contrary to prevailing bot design<\/a> recommendations at the time, our bot didn\u2019t need much of a personality to get its job done. In fact, the more it tried to be human, the more humans rejected it. That\u2019s why we avoided giving it a name at first: having a bot that introduced itself by name damaged it in the eyes of end users.<\/p>\n

But as Operator matured, we had another audience to consider: our customers.<\/p>\n

We wanted our customers to remember and understand all the jobs Operator did \u2013 so they could get a handle on this thing that was helping their end users.<\/p>\n

The paths we didn\u2019t take<\/h2>\n

We decided early on that we didn\u2019t want to use a proper, human name, for two reasons:<\/p>\n

    \n
  1. It would endow our bot with more personality than it needed.<\/li>\n
  2. It would associate it with bots that do have a persona, like Alexa or Siri.<\/li>\n<\/ol>\n

    We also sidestepped some issues by avoiding a human name. Gender has been a problem for bots designed to have personality. But we knew any choice of gender would load Operator with associations. Even though we were drawing on an old, Mad Men-era name, we didn\u2019t want old, Mad Men-era stereotypes.<\/p>\n

    And gender wouldn\u2019t improve Operator\u2019s ability to do its job. In fact, extrapolating from our research into personality, it likely would have made it less usable.<\/p>\n

    We also discarded the idea of simply calling it “Intercom”. This was a viable direction \u2013 think of Google Assistant\u2019s \u201cOK, Google\u201d. Their brand is so deeply associated with algorithmic intelligence and the retrieval of knowledge that building a voice for that brand was far wiser than creating a separate entity. Making their assistant an animated, voice-activated version of the search engine itself was a paradoxically subtle choice.<\/p>\n

    Our starting point was different, and so our design direction was different.<\/p>\n

    Because we designed our bot starting from a job<\/a>, we felt a kinship with names that described the job. A job-oriented name creates borders for us to design within. Those borders set subtle constraints for what\u2019s appropriate for the feature or features that evolve from those designs.<\/p>\n

    Because of that, our naming workshop circled back to the jobs Operator started out with.<\/p>\n

    Those jobs fall into two camps:<\/p>\n