6

I have a screen which allows the user to capture bank account information (+ the account information is for someone that the user wishes to pay, either now or later - this is a banking context, not e-commerce) and then choose what to do with that information. The options are either pay or save or both. (+ the user may not be paying at this point so a solution that requires immediate payment will not work)

In my prototype (used for concept testing) I have represented these as 2 checkboxes. The user must select 1 or both. The interaction is clumsy and I'm looking for a more elegant solution.

The immediate requirement is for Web (desktop and mobile) but there may be a requirement for native app as well.

Any suggestions would be appreciated.

  • I've updated the answer I provided to match your edits. – Andre Dickson Aug 29 '16 at 15:54
5

I would go with a mix:

A checkbox, a button and a link/less prominent button.

Checkbox Save, Pay now or Save without paying

Benefit:

  • You can save the users preference, so in most cases he just has to click the single default button.
| improve this answer | |
  • That's less clumsy than the OP first design, but this way the user can't just save without paying. Maybe that's acceptable, why not? – Heitor Aug 29 '16 at 15:10
  • @Heitor This is why I provide the Link Save without paying, it should be on the bottom, less prominent. – Falco Aug 29 '16 at 15:37
  • 1
    I think this could work, and I will prototype and test it as one of the options. This supposes that Pay is the primary action here, which in some cases will be true - in other cases it may not be, for example if they clicked on a button saying Add payment details (for example) – LynnseyS Aug 30 '16 at 7:24
  • 1
    @LynnseyS If you already know from Context what the Users expected action is, you can modify the UI accordingly. - But I would argue: "The overall goal for each payment in the system is to be paid one day". So I think this could always be the prominent button, while the Link is always an action meaning "I don't want to pay NOW" – Falco Aug 30 '16 at 8:51
4

Perhaps the following can get you thinking about the interaction flow.

The way I see it, you have a collection of existing options, or the option to add a new one. This list is accessible via the [Saved Options] button. This will trigger the modal window as shown in the second mockup.

Saving a set of payment options is an available feature, but not required for a user to continue, so you can have that logically grouped with the data input rather than near the page-ending, finalizing controls for the page (i.e. the [Pay Now] button in this example).

The [Save Payment Options] button should be a button because it triggers an action immediately--adding to the Saved Options list--but doesn't navigate away from the page.

Clicking [Use Selected] from the modal can just prepopulate your form for you.

I'm not sure what fields you're dealing with, but hopefully this will help get you started.

mockup

download bmml source – Wireframes created with Balsamiq Mockups

| improve this answer | |
  • A nice approach, but if the user just wants to save the payment and not pay afterwards, he is lost. Should he close the browser-window? Won't that break something? Should he use his back-button? There is no clear way for the user to finalize/end this current interaction with just saving his payment and not paying it. – Falco Aug 30 '16 at 8:53
  • Maybe add a link besides the SAVED button "Don't want to pay now? Click here to return to your overview" – Falco Aug 30 '16 at 8:54
  • @Falco Perhaps something like that sounds good and could be integrated into the sample I provided. I don't know what the rest of his application looks like, so I focused just on the features in question. – maxathousand Aug 30 '16 at 13:07
  • But the question clearly states 3 Possible outcomes of the transaction: SAVE | PAY | SAVE & PAY - I cannot see how your answer supports the (according to the OP common) case, where the user wants only to save and not to pay ? – Falco Sep 1 '16 at 8:28
  • @Falco 1) User fills out form 2) User clicks "Save Payment Options. Again, I'm not sure what the rest of the site structure looks like, so it's hard to try and tie this into some sort of interaction flow, but this is just to help the OP start thinking of what it could look like. – maxathousand Sep 1 '16 at 13:12
2

I would like to suggest very different way so that user cannot get confuse, also it will not look like a threat as it is a sensitive information of user.

Simply show only one button "Pay". Once the user will fill the payment information and click on pay, then only show the popup "Would you like to save this payment method as your preferred option" and show 2 option "Not Now" & "Save & Pay".

Thank you!

| improve this answer | |
  • That's less clumsy than the OP first design, but this way the user can't just save without paying. Maybe that's acceptable, why not? – Heitor Aug 29 '16 at 15:15
  • Being able to save without paying is a requirement – LynnseyS Aug 30 '16 at 7:50
  • Instead of showing "Pay" you can show "CONTINUE" button and pop up will occur on clicking "Would you like to save this payment method as your preferred option" with 3 buttons Save This option will save the method & take user on the next page where you want after this action Only Pay This will not save the information but will take the user on payment gateway Save & Pay this will save the method and take the user on payment gateway. – Sudarshan T Aug 30 '16 at 8:38
2

I think you can accomplish all of it without overloading the user with options up front. I would consider giving TWO buttons: just "Pay Now" and "Save and Continue".

If the user chooses to save, that happens and they are satisfied, left at the same place in the flow. If they choose to Pay, they would be taken into that flow without any interruption, but at the conclusion of the payment process provide them the option to save their payment info for future purchases.

My $0.02

| improve this answer | |
  • Good, but for the first time they're using, users won't know what to choose when they want to pick both. They'll have to bet and that's uncomfortable. I think this is very close to an acceptable solution. – Heitor Aug 29 '16 at 15:04
  • If they save their info, do they remain in the same flow? If so, you could label the button "Save and Continue," alleviating any concern that they will need to navigate back to this spot. If the want to save and leave, they can always Save And Continue and then navigate away when done... No need for a control. – Mattynabib Aug 29 '16 at 15:17
  • @Mattynabib Maybe I'm the only one, but "Save and Continue" sounds like it will save, then take me to the "next" page (i.e. I will then "continue" in the page flow). – maxathousand Aug 29 '16 at 20:32
  • So, because of the way that the back-end works, if the user opts to save AND pay, these 2 "transactions" will be committed to the back-end at the same time. Save and continue would work really well if the information was in fact going to be saved at this point, but in reality it will only be saved at the end of the flow, when the payment happens. – LynnseyS Aug 30 '16 at 7:20
  • Has this payment information been entered as part of a purchase flow? If so, then it still seems likely that they are expecting to pay, and that payment would be the primary action. What if the other button was labeled "Save and Exit," and then at the end of the payment flow they are again given the option to save for future purchases? – Mattynabib Aug 30 '16 at 12:10
1

Elect one operation to be the main one. The screen will be about it, and the other one will be also possible. This way the screen won't be clumsy, understanding it will be immediate.

Then let the user do any of the two operations later whenever they want (i.e, pay from a contacts list or save a contact from the history of payments).

That's the same situation of dialing a phone number on the cell phone. Usually it offers three options: create new contact, send an SMS or call to the dialed number.

phone dial app

The interface has a clean design because the call button is proeminent, green, light, with an icon instead of text and is already there when the interface is shown (as you expect to be in a phone dialer); the other options are shown after you dial the number, along with auto complete suggestions, appart from the main option (green button "call"). And if you want to save the number after you have called to it, you can do it from the call history.

| improve this answer | |
  • I think this may be the best solution - one operation should be the main one. However, to support both user goals, I think that we would have 2 variants of this screen - one where pay is the primary action, the other where save is the primary action - depending on the entry point (i.e. what did the user click on to reach this page) – LynnseyS Aug 30 '16 at 7:37
0

My suggestion would be

Suggestions 1 - in this approach of transactions, Pay would be default. - save would be an optional - it's better to give Pay button and add check box to Save info.

Suggestions 2 - while collecting the bank info, add checkbox option to save the info like "save this payment info" - next screen provide option for the Payment - in this approach user would be aware of deciding the best option and it's clear approach

| improve this answer | |
  • For suggestion 2, there would be a button "next" at the end of the form? And in the following screen, there would be a "pay" button? Both suggestions are the same, correct? – Heitor Aug 29 '16 at 15:18
0

This answer has been updated.

If this choice is the primary action for this screen I would use buttons labelled with the available options instead of checkboxes. The buttons should read pay and save payee, pay, save payee. You would also need to throw in a cancel button if the screen doesn't have an exit mechanism.

However by offering three options, you are combining two operations that should probably remain separate. To make the interaction less clumsy you could separate these two operations. I think this flow might help:

  1. After information is captured provide pay now and pay later buttons.
  2. When the user selects pay now inform them that the payee has been paid and provide them with save payee and done buttons.
  3. When the user selects pay later inform them that they can choose to save the payee (possibly also include steps to pay a saved payee). Again provide them with save payee and done buttons.
| improve this answer | |
  • Hi, just to clarify, are you suggesting 3 buttons? Pay / Save / Save & pay ? – LynnseyS Aug 28 '16 at 20:49
  • I am. Three can be a lot of buttons but without more information about the screen and these options I can't suggest anything else. – Andre Dickson Aug 28 '16 at 20:53
  • I just don't agree that the excerpt says that checkboxes are not appropriate. – Heitor Aug 29 '16 at 15:14
  • @Heitor you're right. As other answers have rolled in I realize that I misinterpreted the question, I'll update my answer. – Andre Dickson Aug 29 '16 at 15:21
  • @AndreDickson, you are possibly correct that these should remain separate, and we may fall back to that position. At the moment we are trying to understand whether it's viable to combine them - the concept tested well, but the interaction design still needs to be solved. There is also the scenario that the user may want to pay this person only once and doesn't intend to save the details for later use – LynnseyS Aug 30 '16 at 7:34
-1

Additional context might help shape answers for this.

Assuming this is for a pay situation, I agree with Mattynabib's answer, above. Is your interaction is happening at a checkout?

If not, I might recommend saving this "pattern" for that interaction/pay time. That's when folks are used to (more comfortable with) indicating whether to save their personal / banking info.

| improve this answer | |
  • This is not a checkout scenario - the user is entering someone else's account details, in order to be able to pay that person (now or later) – LynnseyS Aug 30 '16 at 7:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.