Selecting new status vs. Triggering status change?

Question

I'm designing the control panel of a booking app. Guests will be able to enter some reservations, that the host will have to confirm or reject. A reservation can be in one of these stages:

• Pending
• Confirmed or Rejected
• Deleted

When the host confirms or reject a reservation request, an email is automatically sent to the guest.

[edit:] A Pending reservation can be Confirmed, Rejected or Deleted; a Confirmed or Rejected one can only be Deleted.

I'm wondering if is it better to implement the UI of the form for the status change of the current reservation:

1. As a single select (or a series of radio buttons) that allows the host to select a different status for the current reservation

2. As a series of buttons that trigger a status change (like "Confirm reservation request" or "Reject reservation request")

Consider that this User Interface will be placed on the reservation's details page.

The first solution allows to highlight the current status, display all the possible status a reservation can be and reduces accidental mistakes because it involves 2 clicks. The second solution highlights the fact that the host is triggering a really meaningful action, to which are bound several collateral effects.

I'd personally choose the first solution because it fits in the most common approach of changing the status of a generic thing, but I recognise that it is flawed because it doesn't highlight the fact that saving a new status for a reservation request is a very important action in this domain.

Answer 1

Assuming that the reservation status always starts with being "Pending" - and is not a factor of user action, there are two distinct categories of system/user actions.

• First category has both confirmation and rejection. Changes reservation state and generates notification,
• Second category is deletion. Here I assume, only change in reservation state is there and no user notification.

Considering the above, and with an intent to arm the host with sufficient information about what is the result of the state changes, here is a design suggestion -

1) Status change choice intimates the user about the system action, both about what new state and the associated secondary action.

2) It also, in case of Deletion informs that there will be NO secondary action. Making him more confident about his decision.

3) Additionally, it could be great to have the user see a preview of the email message that goes out, and optionally edit the same if needed. Again, more control leading to more confidence.

4) As a quick suggestion, you could think of terming "Delete" as "Archive Reservation" or something. That itself would make a lot more sense about its action. Again, that's strictly based on my assumption of the delete action.

Answer 2

Here changing the status is very crucial activity. Using button for such changes is not a suggested option as using a button only implies a user action with just boolean results(changing state to right or wrong , true or false) in general cases.

Here we need to make a system action, so radio buttons are best suited. Additionally, you can show a description of the effect each option will make on the system simultaneously, this cannot be done in dropdown. Then you can add a modal view for confirming the action, this will act as a precautionary step before confirming the action preventing accidental mistakes, as it will grab users attention and make him realise that this action is very important.

Dropdown is not so suited as there may be new users at the host end. They may have to select every option and see what exactly each option does, increasing their efforts. There is also a chance that an option is selected and confirmed accidentally. This can be prevented with modal window, but showing modal window after confirming the action after selecting an option from dropdown does not go properly with the flow.

So radio buttons is best suited option amongst all of the three. Check example image below.

Check link for additional description: https://www.formassembly.com/blog/drop-down-list/

Answer 3

Assumptions:

• This is a multi-device experience
• “Delete" and “Reject” can be used when a guest requests a cancellation
• There is no difference besides the email notification between "Reject" and "Delete"

Suggestion / Recommendation

It is common to have nice large buttons as actions in the mobile experience. See JIRA & Amazon examples below. Nothing UX states a drop down is better than a Button for action and vice versa. What you need to be aware of is to ensure a CTA (Call to Action) is well understood, easy to find and simple to interact with.

The buttons seem like the best and simplest solution (assuming they are not competing with anything around them). Assuming the reservation page is simple content (text and perhaps an image). Buttons offer enough of differentiating factor to serve as a CTA.

The series of pictures below, Pic 1 - 5 show an example of the mobile experience.

• Pic. 1: is an example when looking at the reservation in Pending state. I assume the host need to see reservation details before they can decide on the action.
• Pic. 2: is an example of the Confirmed reservation. If a guest changes their mind, the reservation can still be canceled.
• Pic. 3: is an example when a host clicks to cancel the reservation. Additional dialog is displayed where a host can pick various reasons (which will help you differentiate between different cancellation reasons and remove the need to have “delete” and “reject” buttons, per my understanding of the flow)
• Pic. 4: is an example of the reservation when it was canceled by the guest via phone. You can see a reason displayed under the status message.
• Pic. 5: is an example where the reservation was canceled by the host.

NOTE: I believe the application will still need “Confirm” action when the reservation is canceled. A guest may change their mind and call back in after they canceled. A reservation could be “rejected” by accident OR I assume another cancellation can open up a seat for someone else.

Summary:

If you are unsure which route to pick, you can always do a usability study to see what your customers prefer (given how the rest of the experience looks like). The proposal above is purely based on the assumption that you need a multi-device experience, such experience often suggests a responsive design and a mobile first approach in most of the use cases.

“As soon a the action takes place, let the user know that the action has started and show its progress. This is especially important for actions that are executed asynchronously in the background and need some time. When the action has finished, let the user know the result. Then the feedback cycle is complete.”

From the article: https://blog.mwaysolutions.com/2015/11/20/give-the-user-feedback-for-a-better-ux/

Answer 4

I think a status gives information inside the system, while a button triggers actions (could be inside and outside). If the host changed the status of a reservation it could imply a change inside the system only, while triggering an action with a button would change its status and perform other possible actions like sending an email.

In your second solution you could make use of a confirmation dialog for each of the actions as they are bound to several collateral effects. So that would make it two clicks as well.

Answer 5

I think this could be simplified as the state is pending, until the user takes action, therefore the DDL or list becomes superfluous, furthermore, giving the user clear response question and button text will assist the decision process.