Questions about ID in the register of a web system

Asked

Viewed 74 times

2

I’m developing a commercial web app and I come from the world of desktop apps. I noticed that in most commercial app sites are ignored the Ids or codes of customer registration. Of course in the database they are fundamental to relationships, but I have this doubt of leaving them visible or not in grids and registration screens.

Exemplo de tela com ID mostrado

In the company where I work, we use a back desktop system in which all registrations have the registration (ID or Code) and they are very important for customers to use to relate a registration with each other. Even, when we migrate data from a competing company to ours, customers make a point of preserving old customer codes, products, groups, suppliers, etc.

What’s more appropriate to do?

ux
  • 1

    Maybe it would be more based on opinion, but I think you can save the question by synthesizing a little and changing the tags that have not to do...

  • @Rovannlinhalis agree. I had a little trouble understanding what the OP wants, and if there is a specific doubt.

  • 1

    I think the appropriate tag would be UX

  • One of the advantages of making it visible is that it can facilitate a search. Many systems to this day use code as a kind of reference there is something (usually the primary key), of course nowadays things are changing. Therefore, you better think about it, and see what you have to gain or lose from it. You could consult users and see if the concealment of the code in the interface brings some benefit or harm.

  • Colleague @LINQ, sorry but I disagree. "This" does fit in the scope of the site. See the meta scope discussions and the amount of UX questions and answers that already exist on the main site. Perhaps the question is in a way that seems merely opinionated (the "what do you think of it" denotes well the question problem), but UX at all times had (and always will have) this discussion.

  • 1

    Tranquil, @Luizvieira, if you’re sorry. Community is supposed to be like that, where one misses the other hits and so we keep everything in line. I had overlooked a possible discussion about UX and now it makes complete sense. I got carried away by the opinionated tone of the publication.

  • @LINQ No problem. Thank you. :)

  • I understand the relationship that customers use with the codes... many sellers know the codes of the products head, or use a label with a "internal code" smaller than the EAN to go adding the products with greater agility (nothing that a reader does not solve, but that’s not how it works in small businesses inside...) there are also cases where the client uses the code of the old system, to relate to a physical file of chips (yes, I still see this kind of thing around here...)... if I were to do something today, I would certainly only show the essential, at most some function to show

Show 3 more comments

2 answers

4


The key point of your question is this:

"[...] all registrations have the registration (ID or Code) and they are very important for customers to use to relate a register with the other [...]"

Yes, they are certainly important... for the company that created and uses the. First of all, it is a nuisance for a user to remember a code, whatever and however short it may be. Secondly, in terms of identification data, nothing is more important to the customer than his own name. Certainly the customers of these registrations you mention would prefer to use their names to relate. Don’t you believe? Ask customers. Or do an exercise in empathy and put yourself in their place with some service you use (telephony, entertainment, etc).

If code is something really needed to business, make it easy for the customer to put it on a card. This is no brilliant idea: movie companies have been doing this for a long time (by the time they persisted). If you need a code, let the customer define it. This is called login, and usually email is used not only by contact, but by uniqueness.

Well, now, considering as a user not the client, but the person who deals with the client and uses that interface for some relationship, the code is even less necessary. What this user really needs to know is the customer’s name, maybe their email and other user identity data or their business situation, depending on the domain of the problem. In fact, in a well-made system, the lines of this table already demonstrate the action that the user needs to take in relation to that customer, and to fool themselves even make the phone call (an example of telemarketing) even displaying the phone. Why then the ID would be needed beyond its use in the database tables, that is, why it would be necessary in the interaction?

What usually happens is that such an ID is so important to the company that it pushes down the throat of the customer and the user who attends this, but almost never such code is really needed. See that doing UX is precisely if you ask these questions (difficult and sometimes uncomfortable for those who are already used to the "world of desktop apps").

  • I worked in an automaker where codes were used to refer to a particular part, as were many parts (thousands of models) and their names were too long and too technical, the code helped, but the code was not the bank’s primary key, but rather to help identify groups of parts, such as the parts of a truck that always started with the digits 509 or other groups of models. In this context, the codes undoubtedly helped, but only the system users, customers did not need to know the code that was used internally in the factory.

3

You’re the one who needs to answer the question, like every UX question.

Do you need to show this ID for any reason? Does the user need to be aware of this? Maybe to get some support? You can optionally show?

I wouldn’t put anything in that’s not very necessary. And even if it was for secondary reasons, I would create an optional way to show the information, I don’t know, an advanced or support mode.

It would be different if this is a client code or something. Even in this case I’m not a fan of the idea. I prefer to make the user more comfortable by dealing with information that is part of his domain.

Not showing does not mean that it is not present in the whole system.

I find the statement in the last sentence a little strange, but if this is true it could be a reason to use that code. But this code coming from something external doesn’t seem to be a primary key, at least it shouldn’t be. Then the ID still becomes necessary and has an extra reason for it not to be shown. But the natural code would be. Do not confuse database ID (replacement key) with natural key that the user understands.

See more in Surrogate Key and Natural Key.

Browser other questions tagged ux

You are not signed in. Login or sign up in order to post.