1

We are migrating a collection of modules which were independent desktop executables into one monolith, and a matter related to naming menus just popped. The desktop execs had each one its brand name, related to their scope, so the module for managing the kitchen of a hotel would be called "SysKitchen", or the one for managing finances of the hotel would be "SysFin". Now, each module is going to be accessed through a menu, which will list the execs' names and under those names (treeview) there will be subroutines.

Some colleagues think it's a good idea to keep the names as they are so that users don't feel lost and can more easily find the module in the menu; so the "SysKitchen" and the "SysFin" are staying the same. I am more prone to say that obvious names are the way to go, so "SysKitchen" will be "Kithen", and "SysFin" will be "Finances".

I'd like arguments for both sides (if any) to help us make that decision.

Improve this question
2
  • It is still unclear. Please edit the question. Why is the question here, if they are brand names. Commented Aug 2 at 7:03
  • The question depends too much on user preference. Do you know what users prefer? If new users prefer the names you are suggesting but existing users prefer keeping names as they are, and if the outcome is 50/50 or uncertain, maybe implement both and allow users to choose one. Commented Aug 3 at 14:32

2 Answers 2

Reset to default
2

I think your proposal breaks with the conceptual essence of the project. In the wording of the question, you state that each module has its own "brand name," and what you're proposing is breaking the corporatism as an identifying entity for each item. In my opinion, this is counterproductive. Especially considering that, as you point out, customers already know these products by their brand.

If I were the company's marketing director, I would not only reject your intention outright, but on the contrary, I would reinforce the identity of each element as a unique brand, especially considering that they will now all be within the same menu, precisely so they don't lose that identity.

Edit after the comment

So the point is to go in one direction or another: keep them as simple components or give them their own identity. It depends on the level of importance; my inclination is toward the second option. A clear example is LEGO®:

  • LEGO® Minecraft
  • LEGO® Super Mario
  • LEGO® Land
  • LEGO® Avatar
  • and a thousand more...
Improve this answer
2
  • Maybe I didn't make my point clear enough. Each module is just a module of a bigger whole system which could be executed in parts. But now, it's just modules grouped under a menu. Also, almost all modules had a name composed of a prefix + a shortened version of what it did (such as the eaxmples, finance, kitchen), so it's not A Brand brand, it was just a proper name. Commented Aug 1 at 20:54
  • 1
    Answer updated.- Commented Aug 1 at 21:02
1

This is a fine example for a question that should be answered by talking to your users. I.e., research which menu labels create the least cognitive load for your users while they interact with your product during every-day use.

If these modules have already been in use for a while, your users might be familiar with the branded names and find them perfectly usable. Then again, maybe they'd still prefer more generic terms, anyway.

Additionally, you describe that you're consolidating individual applications into a single application with a unified front-end. You might want to test, then, whether users can easily find and effectively navigate the new selection menu that you're adding.

With such tests, you'll have hard data about what works for your users — versus negotiating mere personal opinions of internal stakeholders. 😏

Improve this answer

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.