While performing a UX evaluation of some new Salesforce functionality today, I made several observations.

The most striking one was, the implementor wasn’t consistent with field naming.

A previously created custom object had a picklist field called “Status”. Simple, easy to understand, cool. But on a new custom object, the field was called “Shift Status”.

Now, if there was a field called “Status” and then “Shift Status” was a secondary status, that would be OK. But nope. This was the one and only status field.

Some readers might be rolling their eyes right now. Sure, it’s a nuance. But things like this can add up. And when they do, users can become frustrated and adoption can suffer.

Without a standard, fields could be named differently across the board. Then users would need to think and understand that for THIS object, you need to look at “Date” and “End Date”, but for THAT object, it’s “Start Date” and “End Date”.

The takeaway
It’s OK not to have a design document before starting a project. But as you create custom fields, document their naming convention. So when another similar field is needed, you’ll know exactly what to call it.

Category:
Salesforce