User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It only takes a minute to sign up.
Sign up to join this community
Considering I have a grid with a number of buttons for actions the user can perform. It looks like this.
I have a number of similar grids in the system. I am wondering peoples opinions on if I should.
This is a screen that the users don't use on a regular basis, maybe just once per day on average. Speed (1 vs 2 clicks) is probably not a major problem.
There's a similar situation at the Youtube Studio Video Editor that can help you getting ideas, a mix of icons, drop down options menus and interactivity.
From an accessibility point-of-view I strongly advise you to only have one interactive element per table cell. It greatly improves navigating the table with screen-reader. At my place of work we had a similar table; some of the cells would be read aloud by the screen-reader for 10-20 seconds due to all the various content in the cell and in its table header.
As is: ugly but functional. I think it would read better with the same array of buttons on each line, with the useless ones greyed out. It's just easier to deal with tabular data when every row has exactly the same form. I'd also style them smaller, though if it is Bootstrap it's a bit of a pain to do this. (Why oh why did they remove btn-xs ?)
Drop down: if the act of selection triggers the action, then this interface will have a higher incidence of mistakes because operating a drop-down is physically more error-prone. If it's select an action followed by clicking a button to make it happen, that's fine.
You could put al the options in a context menu and disable the ones that can't be used at that point due to the status of the item. This way the user always has the same list of options (and you might can explain why an option is disabled).
Also isn't it posible to make the view option not a button but just a click on the row itself?
Without further context it's hard to answer your questions. How do users use your table? How often do they interact with it. Is it clear to the users what actions are possible in the different states?
Here are some thoughts, without knowing the context: As is, might not look very pretty but it has some advantages compared to a dropdown. It is clear, that not all actions are available in all states. All possible actions are visible at a first glance. The user can click directly on the desired action without clicking a dropdown first. If you change this you would have to consider these advantages. But there are some drawback as well. The UI is very cluttered. There is a lot to process for the user.
The question is, what is the goal of this table. Should it help the user to be very efficient in performing the task. Should it help to give the user a fast overview over states and interacting with items is secondary and not always necessary.
I would say maybe you can use a mix of solution 1 and 2. Have the most used action available and add the not so often used actions in a dropdown. The difficulty might be, that the main action is not always the same depending on the state of the item.
But at the end your users will know best. So what I would do is testing this with a simple prototype and testing it with real users. You will not need the test it with a lot of users to see which solution will work best in your context.
We can discern three types of action on an order. Split those, and group actions within a type.
First of all, I would give the button for the only option that the orders have in common, which is to view them (I'm assuming here that there's no objection to viewing a new order), its own, more predictable location. Now it's jumping all over the place, depending on the other options available.
When editing an order, the user first needs to see what's in there. So remove the edit button here and make the edit option accessible from the view screen.
Now we're left with sending, resending, recieving, cancelling, and uncancelling. You can use a dropdown, but these are a bit more finicky than regular buttons, so perhaps a grid of five buttons would be best. Don't hide the options that are not available, but disable them, so each button will always be in the same location.
Or, as per Annemiek's excellent suggestion, make viewing available by clicking on the row. Remove all buttons and relocate them to the view screen, if an extra click per order is not a problem. That depends a bit on your users. It does create an extra check, sort of, because a user has to view an order first before acting on it.
I have a number of similar grids in the system
The screenshot you shared has different actions on each row. Having all these buttons / actions available upfront on each row is not a good choice in terms of visual clutter, cognitive load for the user and also from an accessibility standpoint like Tobias mentioned. If there is one action which is present on each row and user performs that action frequently, you could keep that button on the row and rest of the secondary actions can be grouped inside a kebab menu (Three vertical dots icon)
You can keep on hover actions for each row. So once the user hover on some row, he will see a dropdown option, which provides list of actions.
It seems confusing to have different options for each items in this view. Typically in a grid or list, the user expects the exact same interface for each element.
You could keep the "View" button (maybe convert it to an icon, but that's not important), since that action is available for all items and move the other options into whatever UX elements are exposed when the user "View"s the item.
Additionally, viewing is not a destructive step, whereas the other actions do some kind of work, which may not be reversible. Imagine the user trying to cancel ORD-123455 in a list, sandwiched between ORD-123545 and ORD-213455. By adding an additional action between viewing an item and acting on it you add a small amount of friction, but also give the user more confidence that they have the correct item selected.
This is a case where I would use icons instead of buttons
In your situation, all the actions your system needs have icons commonly associated with them that most users can identify with immediately. For further clarify, show a tooltip on mouseover that describes the action
Option 2 is fine too if you don't like icons
