Related
I am trying to learn how to use BDD for our development process and I sometimes end-up writing things that implies a UI design, so for brand new development or new features, the UI does not always exists.
For example, if I say this in a scenario "When a column header is clicked" it implies that this feature is based on some sort of table or grid, but at this point we are still just writing user-stories so there is no UI yet.
That gets me confused to know at what point in the process do we come up with a UI design ?
Keep in mind, I only have read articles about BDD and I think it would help our team a lot but still very new at this! Thx!
If you write your scenarios with a focus on the capabilities of the system, you'll be able to refactor the underlying steps within those scenarios more easily. It keeps them flexible. So I'd ask - what does clicking the column get for you? Are you selecting something? What are you going to do with the selection? Are you searching for something and sorting by a value?
I like to see scenarios which say things like:
When I look for the entry
When I go to the diary for January
When I look at the newest entries
When I look at the same T-shirt in black
These could all involve clicking on a column header, but the implementation detail doesn't matter. It's the capability of the system.
Beneath these high-level scenarios and steps I like to create a screen or page with the smaller steps like clicking buttons in it. This makes it easy to refactor.
I wrote this in a DSL rather than English, but it works with the same idea - you can't tell from the steps whether it's a GUI or a web page, and some of the steps involve multiple UI actions:
http://code.google.com/p/wipflash/source/browse/Example.PetShop.Scenarios/PetRegistrationAndPurchase.cs
Hope you find it interesting and maybe it helps. Good luck!
I guess you can write around that by saying "when I sort the information by X, then..." But then you would have to adjust your scenario to remove any mention of the data being displayed in a grid format, which could lead to some rather obtuse writing.
I think it's a good idea to start with UI design as soon as you possibly can. In the case you mentioned above, I think it would be perfectly valid to augment the user story with sketch of the relevant UI as you would imagine it, and then refine it as you go along. A pencil sketch on a piece of paper should be fine. Or you could use a tablet and SketchBook Pro if you want something all digital.
My point is that I don't see a real reason for the UI design to be left out of user stories. You probably already know that you're going to build a Windows, WPF, or Web application. And it's safe to assume that when you want to display tabular data, you'll be using a grid. Keeping these assumptions out of the requirements obfuscates them without adding any real value.
User stories benefit from the fact, that you describe concrete interactions and once you know concrete data and behaviour of the system for it, you might as well add more information about the way you interact. This allows you to use some tools like Cucumber, which with Selenium enables you to translate a story to a test. You might go even further and e.g. for web apps capture all pages you start concrete story at and collect all interactions with that page resulting in some sort of information architecture you might use for documentation or prototyping and later UI testing.
On the other hand, this makes your stories somewhat brittle when it comes to UI changes. I think the agile way of thinking about this is same as when it comes to design changes - do not design for the future, do the simplest possible thing, in the future you might need to change it anyway.
If you stripped your user stories of all concrete things (even inputs) you will end up with use cases(at least in their simplest format, depends on how you write your stories). Use cases are in this respect not brittle at all, they specify only goals. This makes them resistant to change, but its harder to transfer information automatically using tools.
As for the process, RUP/UP derives UI from use cases, but I think agile is in its nature incremental (I will not say iterative, this would exclude agile methods like FDD and Kanban). This means, as you implement new story, you add to your UI what is necessary. This only makes adding UI specifics in stories more reasonable. The problem is, that this is not a very good way to create UI or more generally UX(user experience). This is exactly what one might call a weakpoint of agile. The Agile manifesto concentrates on functional software, but that is it. There are as far as I know no agile techniques for designing UI or UX.
I think you just need to step back a bit.
BAD: When I click the column header, the rows get sorted by the column I clicked.
GOOD: Then I sort the rows by name, or sometimes by ZIP code if the name is very common, like "Smith".
A user story / workflow is a sequence of what the user wants to achieve, not a sequence of actions how he achieves that. You are collecting the What's so you can determine the best How's for all users and use cases.
Looking at a singular aspect of your post:
if I say this in a scenario "When a column header is clicked" it implies that this feature is based on some sort of table or grid, but at this point we are still just writing user-stories so there is no UI yet.
If this came from a user, not from you, it would show a hidden expectation that there actually is a table or grid with column headers. Even coming from you it's not entirely without value, as you might be a user, too. It might be short-sighted, thinking of a grid just because it comes from an SQL query, or it might be spot-on because it's the presentation you expect the data in. A creative UI isnÄt a bad thing as such, but ignoring user expectations is.
My boss believes that wizards make things simple for the user.
I think they have their place but I can't really define what that place is.
I feel there is a danger in turning something into steps that doesn't need them.
Does anyone know where I could find rules for such things, or even a guideline to follow that describes when and when not to use wizards and possibly even other UI elements.
Here is what some common Human Interface Guidelines have to say about when to use them. Most are quite restrictive:
Gnome HIG
An assistant is a secondary window that guides the user through an operation by breaking it into sequential steps. Assistants are useful for making complex operations less intimidating, as they restrict the information visible to the user at any given moment.
[...]
Assistants do have major downsides. After using an assistant it is often hard to figure out where the individual settings aggregated into the assistant are stored. Often people will resort to re-running the assistant, re-entering many settings that they don't want to change.
Assistants are often used in situations where a better solution would be to simplify, or even better automate, the process. Before using an assistant to step people through a complex operation, consider if the operation can be fundamentally simplified so an assistant is unnecessary.
Microsoft Windows Experience Interaction Guidelines:
Consider lightweight alternatives first, such as dialog boxes, task panes, or single pages. Wizards are a heavy UI, best used for multi-step, infrequently performed task. You don't have to use wizards—you can provide helpful information and assistance in any UI.
Apple Human Interface Guidelines
For products with complex setup procedures, a setup assistant can be helpful
(Assistants are not mentioned in any other context, as in the other HIG:s, so I assume that means that Apple think they have no place except for setup)
I'd agree with you that Wizards have their place. And that place is back in Azeroth.
No, but seriously, if the user has to input a lot of different data fields, using a Wizard to split up the data entry into several related groups might help to make things less confusing.
If the Wizard covers a process that consists of steps A, B, and C, and the input at B or C depends on the input at the previous step(s), a Wizard would probably be a good way to structure your application.
There are probably a lot of other situations in which using a Wizard would be warranted (those are just two off the top of my head), but in each case, you'd want to evaluate it and make sure that a Wizard is the absolute best option. To borrow an old saying, everything doesn't become a nail just because your boss wants you to use Wizards as a hammer. If that makes sense.
As far as best practices guidelines goes -- the use of Wizards seems to fall under UX rather than UI, but here's a few items that I came across:
Wizard-style forms best practices
Designing Effective Wizards: A Multidisciplinary Approach (Book)
Best Practice: Designing Wizards
Try reading this.
I would suggest to avoid wizards as much as possible. People have a short attention span and you risk that, at the middle of it, they start forgetting what the said, what they are doing there, etc.
That being said, i think that it may be viable when performing some shopping (e.g., checkout), first-time configurations, others?
When to Develop a Wizard
Always try to:
Only ask the information really needed
Simplify as much as you can, thus avoiding the need to additional explanation
When creating a wizard:
Clearly show the how many steps are needed and how many are completed
Allow the user to revert or cancel it
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
What UI/GUI guidelines should be followed that subtly (or not so subtly) direct users so they don't shoot themselves in the foot.
For instance, you might want to give power users the ability to "clean" a database of infrequently used records, but you don't want a new user to try out that option if they've just spent hours entering new records - they may lose them all because they're 'infrequently used'. Please don't address this specific issue - it's just here to clarify the question.
While one could code a bunch of business logic in place to prevent some issues, you can't account for everything a user might do.
What are some common techniques, tips, and tricks that prevent improper usage?
ie, How should I design the interface to alert users that a function or action is to be taken with care
What should I design in that limits risk and exposure if a poor action is taken?
-Adam
Everything can be undone. Don't erase - deactivate. Back up before every destructive operation, and give the user a way to restore.
That's the path. It's hard to follow it all the way, but it's what you're aiming for.
Make it possible to undo dangerous actions.
If it's a reasonably big application or system, require separate admin access for dangerous operations as well.
Don't Make Me Think
And you can, in fact you HAVE to account for everything they might do. Because you (as the designer) as the one who gives them the ability to do all those things.
Before putting ANY item on a gui as yourself "Can this be misused?" and if it can, you might want to go with a lower level of customizability.
Example hierarchy
Button - Can be clicked.
T/F Radio Button (mandatory) - Only two options.
Combo Box - Many options, possibly "no option". more confusing.
Text field - Myriad of wildly inconsistent options. More confusing for user, more dangerous for coder.
Basically, if the user doesn't need extra options, then don't give them extra options. You'll only confuse them.
This is an old article, but it's still a great one:
Microsoft Inductive User Interface Guidelines
Never rely on anything that says "Are you sure?" The user is ALWAYS sure and that's if they even bothered to read it before dismissing.
Partition your users and have fine-grained permissions.
Define some power-user permissions that enable the "more dangerous" operations.
Power user permission is not given out lightly -- only to actual power users -- and revoked readily.
I'm of the school of thought that, in case of inclarities or ambiguousity, the user is rarely wrong, and the UI is always to blame. So, when you say "punch the user in the face", tagged with "pebkac", I'm thinking that you would do good with a slap in the face.
Unfortunately, I'm unable to give any good UX-advice, since I'm a mere programmer, and therefore more or less by definition disqualify as a good UI-designer. I'd like just to point out the possibility, that you actually could be the one who needs to get a clue, and try to be more humble towards the users.
Edit for Adam:
The little I know about UX is how little I know about it. It's an entire career path. I know for a fact that there's very little anyone can learn by asking a single make-me-good-at-this question at Stack Overflow. It's like me asking "help me write better code", with the body text formulated as a story of how my colleagues ridicule me of my code.
We, programmers, are engineers. We like order and reason and logical decisions. But the average user is not a programmer, not an engineer and, in many cases, not interested in computers themselves the very least bit.
I'm glad that people are giving you nuggets of good advice, and I'm glad that you, contrary to my first impression (I'm sorry about that), are eager to take those bits and understand the needs of the user.
But the point remains: You need to buy books (Don't Make Me Think is a great place to start, as already recommended). You need to watch how people use your software. You need to observe where they stumble, and jig things around until your UIs seem natural.
I'm sorry I still can't give you an answer. Because I don't have it. And even if I would have it, I would probably have to charge you 50EUR an hour, for years into the future.
Make the results of the user's action visible and offer a way to undo those changes.
When the changes are visible, then the user gets feedback of whether the results were what he intended to do, and if they are not, then the possibility to undo will let the user to try again to reach his goal. If possible, make the results of the action visible before the user invokes the action (for example, when dragging some element, show what would happen if the user would release the mouse button, for example visualize addition of the element where it will be moved to and visualize the removal of the element from where it was moved from).
There are a couple of types of undo. The most simple is a single-step undo (as in Notepad), but it is often not enough. Better is a multi-step undo (as in Word), which covers most of the cases, but does not allow undoing a specific action without undoing all the actions that have been done after it. That can be solved by object-specific undo, for example in a form with many fields (or cells in a grid like in Excel), right-clicking the field would show a list of previous values in that field. For deleted data you could have a store of deleted data, from where the user can restore things after deleting them (for example if the user deletes a slide in Powerpoint). And finally you could have a full version history of every change, for example as Local History works in IntelliJ IDEA - make a history entry every time the file is saved (and save everything automatically after a couple seconds of inactivity).
Confirmation dialogs don't help. The user might read it the first time, but soon after that clicking "OK" in the dialog becomes an automated process, and the user will press Enter before the dialog even shows up. Then the confirmation dialog has become just a source of unnecessary mechanical work. The user is always sure about doing some action, even when he is wrong - otherwise he would not have done that action.
Well there are a few different ways that I can/do go about these types of things.
User documentation - first and foremost give them some documentation to work with, and make the systems easy for them to use. Just general usability and descriptive names/actions for everything.
Provide confirmation screens with warnings. Full disclosure of what the action is going to do, with the warnings inside of a yellow box. It draws attention to it and helps prevent the need for the other items.
Have a roll-back plan. For large risky operations you can either simply set "deleted" flags, or offload the data to a temporary "recycle bin" of sorts should they accidentally remove/modify data that was unintended.
Require multiple approvals, for data purge operations especially go to a two-tiered approach, requiring approval from separate users.
These are just a few of the ideas that I have.
Two things immediately come to mind.
The first is the notion of progressive disclosure, i.e., only show users what they need in order to accomplish the task at hand. How many UIs have we seen that have hundreds of controls on a single dialog? Divide the controls into their respective tasks and only allow the user to do a single task at a time. An Advanced button on a dialog is one way to implement this, and this concept has the added benefit of separating the power users from the run-of-the-mill users. Run-of-the-mill users are less likely to attempt a task that is likely to be beyond their skill level.
The second is to leverage the wizard concept for complicated tasks. I know wizards have fallen out of style, but if a task is truly complicated, users usually appreciate having their hands held the first few times. A good example of this is the WinZip wizard interface. If you've never zipped a file before, this wizard uses a logical progression to walk you through the process. And then, once you've grown comfortable with it, you can switch to the classic interface to zip files more quickly.
Of course to do all of this requires a committment not only by the developers, but by management. And that, sadly, is where many of these usability battles are lost.
It happens sometimes that one feature seems to belong to more than one place.
Trivial example, let's say I've got the following menus :
File
Pending orders
Accepted orders
Tools
Help
I've got a search feature, and the same search window work for both pending and accepted orders (it's just an 'order status' combo you can change)
Where does this search feature belongs?
The Tools menu seems to be a good choice, but I'm afraid the users may expect the search accepted orders to be in the accepted orders menu, which would make sense
Duplicating the menu entry in both pending and accepted order seems wrong to me.
What would you do? (And let's pretend we cannot merge the two orders menu into one single menu)
I think the problem you've run into is that you're thinking like a programmer. (code duplication bad). I'm not faulting you for it, I do the same thing. Multiple paths to the same screen, or multiple ways to handle the same process can actually be extremely beneficial. I would guess that more than one person is going to use your program and each probably have slightly different job functions. In essence, they have different needs for the application and will approach using it different ways. If you stick to the all items have one way of being accessed, some people will find the application beneficial and others won't. Sure all people can learn to do a task a certain way, but it won't make sense to some users. It's not intuitive (read familiar) to they way they are used to processing information, which means the application will ultimately be less beneficial to them. When people find a process (program etc.) frustrating, they won't adopt it. They find reasons why the process will need to be changed or abandoned.
An excellent example of the multiple approaches to a problem is with Adobe Photoshop. Normally there are at least 2 different ways to access a function. Most users only know of one, because that's all they are concerned with, but most users are really comfortable with using one, because it makes the most sense to them. With a little extra work, Adobe scored a huge win, because more people find their product intuitive.
Having a feature in multiple locations is not a bad thing. Consider the overall workflow for viewing both pending orders and accepted orders, and think of your new feature as a component, rather than a one-off entity.
After you map out exactly what tasks a user completes in the pending and accepted order viewing process, see where having the ability to search would provide value (by shortening the workflow or otherwise). This is where your search component belongs.
The main thing to remember about UI is that all that really matters in the end is whether your design makes using your application or site a better experience for your users.
In the search example you list above you'll commonly see apps take two approaches:
Put the search feature in a single location and allow the user to filter the search by selecting pending or accepted, or
Put the search feature in both menus, already configured for the type of search to be done based on the menu it was launched from.
If you repeat the above choice for a number of factors you'll see a much more advanced (aka 'complicated') search interface for number one, and a much simpler (aka 'restrictive') search interface for number two.
Which one is best completely depends on your users. This is why many general applications have a simple search by default and a link to a more advanced search for those that want or need the additional capabilities; they're attempting to make everyone happy. There is absolutely nothing wrong with that if you're writing for a wide variety of people with different needs. If you're writing for a set of users with a restricted set of needs however, you can make some better choices.
In my experience your best bet is to work with one or two of your primary users and map out all of the steps they need to take to get each of the tasks the application will be helping them with accomplished. If there aren't a lot of branching points in that sequence of steps there shouldn't be a lot of choices or settings to make in the application; otherwise the users may feel that the app is harder to work with than it needs to be.
For the search example above, if the user has already navigated into the Pending Orders menu, the likelihood that they'll want to launch a search for Accepted Orders is very small and having to make that choice, or go elsewhere to do the search, will be an extra decision or action they'll need to take. Basic principle is if your user has already made a decision, use it; don't make them tell you again.
Use the UI you come up with as a first cut. Let your users, or a subset of them, try it out and make suggestions. If you have the option, watch them use it. You'll learn far more about how to improve the interface by seeing how they work with it than you will from what they tell you.
Generally you do not want the same menu item appearing in different menus. It adds complexity and clutter to the menu, and users will wonder if the two menu items are really the same or not. When it appears that a menu item belongs in two places, then you may have a more basic problem with your menu organization.
For instance, your example shows a menu bar that is organized by the class or attribute of the object the commands within act on. In general, the menu bar should be organized by category of action not type of object. For example, you could have a Retrieval menu for commands like Search and other means of displaying orders, and a Modify menu for processing the orders (e.g., updating, accepting, forwarding). Both menus would have menu items that apply to both types of objects, although some commands may apply to only one.
Organizing commands by object type is actually a good idea but it is better accomplished with a context menu (right click) than the menu bar.
I would try the search in both the Accepted Orders and Pending Orders menus. However, user testing will show if this is a good idea or not. But it also depends on your user base.
You are doing user testing right?
...you may already know this, but this is a good place to use the command\action pattern IMHO.
So to answer your question: IMO, yes, it is ok :) This situation is definitely warranted.
Just put it under both menus and have it open your search window, pre-configured for the order type who's menu it was launched from. Name them accordingly and voila they're actually two different actions - even though they use the same code/component.
Keep the user-selectable "status combo you can change" in the search window active though so the user still can adjust the settings without relaunching it from the other menu... and then perhaps rethink the structure, see some of the great answers in here for ideas ^^
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
This is a perennial question for me that I've never really resolved so I'd like your input. If I have actions that I know a user will not be able to perform due to insufficient privileges or object state, should the UI elements for those actions be hidden from the user, visible but disabled, or visible and result in an error if attempted? What would be the rationale for your answer? If disabled, would you communicate the reason why and, if so, how?
This is a web interface so I already know that I need to check the incoming post/get for permissions and handle errors there anyway. I'm primarily talking about how to handle the UI.
This is similar to Rules about disabling or hiding menu items, though I am interested in all types of UI elements not just menus.
Examples:
I have a New page that allows a user to create a new Event. Events can be master events or subevents. Creating a master event requires "EditMasterEvent" privilege, while creating a subevent requires only "EditEvent" privilege. I have a drop down that allows one to choose an existing event as the parent (master event) or no parent (this is a master event). Should the "Create Master Event" choice be shown on the dropdown or omitted if the user only has "EditEvent" privileges.
Deleting events requires that you be an application administrator or have the appropriate edit permission for the event type. In the latter case, the event must also be more than 5 years old. Deleting an event causes major cascading deletes of related data in the system and for legal reasons this data must be kept for at least 5 years after the event. Since this operation is rare for the normal user, the typical case is that the action is not available. Should it be shown always or only when actually possible?
Hidden - This is the best approach for actions that are never available to the current user. There is no point in having the user waste mental effort figuring out why something is disabled if there is no action they can take to change this.
Disabled - This is the best approach for actions that are sometimes available, but not at the moment or in the current context. A disabled option should convey two things: first, the action is not available right now, and second, there is something the user could do to make the action available (change some setting or permission, select an item, enter prerequisite data, etc.). If you can indicate what needs to be done to enable the action in a tooltip - all the better. Enabling/disabling actions as the user enters data or changes context provides excellent feedback about what the program requires.
Fail with an Error - This is the worst choice. You should only resort to an error report for operations that might work: you can't tell that it will fail except by trying.
As with nearly all UI questions, the answer is "it depends".
You need to weigh discoverability with user satisfaction, among other things. For example, allowing an invalid action gives you an opportunity to explain why something is invalid. This is particularly useful if the answer to "why is this disabled" isn't obvious. For an application where most users are beginners, that's important.
On the other hand, it can be mightily frustrating to see a control, click on it, only to be rewarded with a "sorry, you can't do that now" message. An app I inherited a couple years back was rife with that sort of stuff and it made using the UI an exercise in frustration.
Completely hiding functionality is probably rarely a good idea. Imagine knowing some feature "was there a minute ago" but now it's gone. Whether it's a menu item or a toolbar button or something else entirely, making it hidden can be an exercise in frustration for the end user.
Try doing a little usability testing, if only by asking the next person you see "hey, does it make sense to disable this or show you an informative dialog". Just one other opinion is often enough to get you to look at the problem from another direction.
Bottom line: do what best serves the user. All the scenarios you mention are valid under certain circumstances. As with all UI questions, ask yourself (or better, your users) what best serves their needs.
I disable the elements instead of hiding them. That way the user knows the option would normally be available, and I provide a tooltip to explain why the element isn't currently available.
It depends. Do you want the user to be aware that the action is possible, just not for them? In that case, show them the button, but disable it. An example might be if a user doesn't have delete authority, but other users do, they should know that entries CAN be deleted, so they can ask someone to do it for them if they need the action.
On the other hand, if the user is not supposed to even know about the action (for example, a user who does not have read access to audit logs probably shouldn't know that these logs exist) should not be able to see the button, so hide it completely.
Great question!
A couple of considerations:
If you place the elements on the page but disable them, there's still a remote chance that the user could doctor the system and enable them using a javascriptlet.
If you do not show them at all, the overall functionality may be a bit confusing to the general user. "Shouldn't there be an edit button here?"
If you're going to either display and disable or display and verify the elements, I would definitely do server-side validation. Don't leave the validation in the hands of JavaScript; I think the reasons for this are obvious.
I tend to handle the two different types of situations differently. Is this an action that is governed by privilege and by state of the object.
If the person does not have enough privileges to do an action, I hide the option, they do not know they can perform the action.
If the option is not available because the object is not in a state that can use that option, I disable it, allowing the option to be visible to the user, but no action can be done.
From your examples:
I would not have "Create Master Event" as an option. The user has insufficient privileges to view it.
I would have the Delete button visible to the administrators. Then depending on how you do the rest of the site (a lot of visible text, tooltips, help icon, etc) I would follow that convention about informing the user why the button is not usable at this time. And possibly putting a timer on, above, near the button with either how old the post is or how long until it can be deleted.
Depending on the item, we will either hide them or disable them. If the user has access to a large feature, but not to a smaller piece inside it, then we will hide the smaller piece. However, if the user has access to several large features, but not to others, we'll leave them visible but disabled as a marketing ploy to remind them that the features are available for purchase if they should decide they want them.
I've also seen some programs that disable the menu item and change the text of it to "Log in to do blah..."
I like this because it doesn't leave me with the "why isn't this working?" feeling and tells me immediately what to do to get it working. Not applicable in every case, but this is a nice approach if you can implement it.
The general rule is use disabling if the user can do something in the UI to get the privilege. Disabled means “you can do this command, but just not right now the way things are.” The “way things are” includes the current selection, so use enabling/disabling if the user has the EditEvent privilege for old objects but not for new objects. There should be a clear indication which objects are delete-able so users understand why the associated commands are disabled for some objects (e.g., if users generally know that records must be kept for 5 years, a simple Age field maybe be sufficient, perhaps reinforced with a graphic difference for records over 5 years old).
Use message boxes instead of disabling if there is no way to make the reason for the disabling clear to the user assuming they have average knowledge of the domain. Tooltips for disabled controls, BTW, are a great idea, but may not be sufficient by themselves.
Use hiding if the user never has the privilege no matter what they do in the UI given their current position in the organization (e.g., they are not an Application Administrator). It is cluttering and frustrating to use disabling or message boxes for this case. As far as the users are concerned, actions they don’t have the privilege for are not their job (otherwise they’d have the privilege), and so the associated controls should simply not exist in their UI. Documentation or organization procedure manuals may tell users how such actions are accomplished (e.g., “Your supervisor creates new events for you.”).
I’ve more details at http://www.zuschlogin.com/?p=40.
I would say disable with a hover containing the reason.
It prevents the user from wondering what the hell is going on while at the same time letting them know certain actions are possible under the right conditions.
I have a particular hatred of applications that disable buttons. If you're an end user - you want to know why you can't use that button. Having it greyed out doesn't tell you anything. How do you get to the state to enable it? Tooltips are one solution, but they aren't the best, a lot of users will struggle with tooltips (unless you're working with experienced users).
My personal feeling is that the elements should always be present. If the user doesn't have enough permissions to do them, they should generate an error when clicked upon.
I know that translators don't really enjoy creating a zillion different "permission denied" error messages, so this is often not done in localised applications, which tend to hide the elements instead.
In practice a lot of people tend to hide the options instead even in non-localised apps.
Other people have provided good answers with valid suggestion to avoid hiding elements and instead disable them and provide some hints for the reasons.
So, I would like to look at it from different perspective - but how to hide some UI elements in cases when user does not need to see them, no matter if he has or has no permissions for particular actions related to the elements?
For example, let's say, users of some role are given access to sellers records in the system.
But then business analyst says: "Look, there is a dropdown with sellers list in this form and we should not allow some specific roles to see it".
Developer asks: "So, we just remove the "Read sellers" permission from this role, right?" But the analyst replies: "No! This role should still be able to view the sellers on the Sellers page. It's just this single form where we should hide the list for some roles and show it to some other roles."
So, the developer adds permission called "Show sellers dropdown on the form X".
Ooops, now we have a problem. Access to the same data is being controlled by two separate permissions. Now we have to figure out how to combine both of them. And what if there are more than one form where seller's list should be hidden for some roles? How do we combine it with "Read seller's list"? For us, developers, it is somewhat clear that "Read" permission should have higher priority above "View", so even if a user can "View" a list, he still should not see it (or see empty or disabled with a helpful hint) if he does not have "Read" permission. We, developers and analysts of the system know it. But how should the system administrator know it? Should we teach him this? How can we guarantee that the admin won't confuse all those "View" and "Read" for the single data list?
As you see, it all gets messy for one reason - we are mixing data processing permissions with UI conveniences in the list of role permissions.
I have seen many projects where it gets messy because permissions on the server side get coupled too much to UI, which asks for troubles and possible security holes (because you have multiple items in your role permission editor for the same actions on the same data).
Permissions are about access and operations on some specific data. UI can only react to permissions in consistent way throughout entire system (disabling with hints, hiding etc.). We should never invent new permission entries just for UI purposes.
Now the question remains - but how do we actually hide UI elements for some system users to avoid overwhelming them with huge amount of always disabled items? One solution might be role workspaces. If we clearly know that users of some role will never ever need access to some specific data, we create a set of UI control entries, similar to permissions, but this time we don't call them permissions. And we can get really fancy here, even allowing users themselves to freely customize their workspace and choose what they can or cannot see. Of course, permissions will always take the highest priority, but it will only affect the data and state of UI elements and not visibility.
That's my two cents. Unfortunately, I myself haven't worked on such a system where permissions and UI workspace options are neatly separated because I always somehow come too late to a project, when the "damage has been done". But I hope some day I'll have a chance. I just hope to find a good example how to do this right, but somehow internet searches do not give me anything useful. Does it really mean that nobody else has came to the same conclusions as me? I don't believe it, somebody in the enterprise design pattern world should have noticed this UI<->permission impedance mismatch long ago.