group-income
group-income copied to clipboard
okTurtles
Improve overall experience of sending / receiving monetary contributions
Problem
As discussed on the 2019 hackathon, Group Income's main function - to send or receive payments to or from members - needs to:
- Allow for Bitcoin payments;
- Display a history of payments made to someone, and their respective status (e.g.: I'm sending a payment via Bitcoin, there were 2 attempts to pay and both failed, the third one was successful);
- Allow users to change the amount of money sent if they wish to;
- Be a great user experience - as @taoeffect said "We need to do one thing and be great at it";
Solution
We did a workshop together, in Bulgaria, where all team members brainstormed and discussed what an ideal payment system would look like. We took the opportunity to think outside the box, and focus 100% on our user's experience, not paying much attention to technical limitations. These are some of the main ideas that came out of it:
- The payment should be as automatic as possible;
- Members should be able to add more than one payment method;
- Using a traditional bank, Paypal, Venmo and other similar non-crypto systems should be an option;
- Have an option to process all payments automatically;
- Send emails with a summary of that month's transactions to members;
- Notify users by email that it's time to send their payments.
Now, I don't believe we need to implement or discuss all of these possibilities for the MVP. The ones I think are really important are:
- An email notification saying that it's time to do the monthly payments. I am aware that we are trying to avoid using email at all costs, but we cannot expect our users to always remember to do their payments or to check our app regularly. If users do not remember to do their payments (and receiving members are shy / afraid to ask because it might be rude), this could render the whole thing useless. I am, of course, open to discuss this. I am not aware of any methods that can work as well as email for this, but if any of you are, please share them!
- Having a way to do all payments automatically - this would be opt-in, of course, and only available for Bitcoin (I am not sure if this is possible) and other digital methods. The goal here is for it to be possible to have a subscription-type payment, where users don't even need to go to the app to send their monthly contributions. Psychologically, it can be damaging to be reminded every single month that you are giving money away. If people had to go every month to a website and click a button to pay for their gym subscription, for example, there would be a lot less unused gym subscriptions around. Of course that, in the example I just used, this would be a good thing for everyone, but for Group Income, I believe we should reduce the emotional / psychological burdens to a maximum when it comes to these contributions, and help people focus on the great things that come from sharing their resources with each other (and not the resources themselves);
- Having some more traditional payment methods - what services could we use here?
@taoeffect after reading all of this, I would appreciate it if you could help me figure out exactly which problems listed above should be addressed for the MVP!
Thank you again to @taoeffect, @dotmacro, @pieer, @sandrina-p and @SebinSong for participating in the workshop and sharing your ideas for this!
@taoeffect can you please elaborate on what users will need to do to have a Bitcoin setup? More specifically:
- Are transactions done from one member's BTC wallet to another directly? Or will there be an intermediate wallet? And if there's an intermediate wallet why is that necessary?
- What information do we need to ask from users? e.g.: their BTC address, etc
- What are the possible statuses for transfers? Error, Success and Pending?
Are transactions done from one member's BTC wallet to another directly? Or will there be an intermediate wallet? And if there's an intermediate wallet why is that necessary?
We will most likely use the Lightning network for payments, which is a layer on top of Bitcoin. It will be from one Lightning wallet to another (direct). Intermediate wallets (lightning or not), should not be needed (or wanted).
What information do we need to ask from users? e.g.: their BTC address, etc
Group Income will likely have wallet(s) built into it for the various currencies we support. Ideally those wallets will exist in the clients themselves (and not the server that hosts their Group Income group). This means that when they register their user they will automatically be given BTC/LN addresses into which, if they are paying others, they will need to transfer funds.
So it would be more like, "Please fill up your wallet with funds.", with an address they can copy and a QR code they can scan using mobile wallet software.
What are the possible statuses for transfers? Error, Success and Pending?
All payment networks have roughly the same statuses, the most basic ones are "Pending", "Completed" and "Error". Other statuses are possible too, like "Cancelled", and "Reversed". Some payment networks don't support these other statuses, and some do. Some networks might have additional statuses, but these are the basic ones I've seen.
Having some more traditional payment methods - what services could we use here?
PayPal and Stripe seem like decent candidates for traditional payment services. It's also possible that we could add custodial cryptocurrency services (i.e. "hosted wallets").
But really we need to just first pick one digital payment method and do it really well. Then we will have manual payments, and a digital option that can be automated. It will be much easier to move forward from there.
The ideal solution is Interledger (#752), which is a generic payments protocol that supports everything imaginable. Hopefully, by the time we're getting ready to implement all this, they will have some decent code we can use.
It's also possible that we could add custodial cryptocurrency services (i.e. "hosted wallets").
This is a bad idea. We do not want to be a custodian because we are not and do not want to be a "money services business". Users must pay each other directly.
This means that when they register their user they will automatically be given BTC/LN addresses into which, if they are paying others, they will need to transfer funds.
I'm not understanding how this is different from "hosted wallets". Can you elaborate?
This is a bad idea. We do not want to be a custodian because we are not and do not want to be a "money services business". Users must pay each other directly.
I think you misunderstand - a hosted wallet doesn't mean that users don't pay each other directly - they still do - it just refers to a setup that is closer to PayPal than Bitcoin (i.e. users not owning/controlling their private keys, and letting a company do it for them).
I'm not understanding how this is different from "hosted wallets". Can you elaborate?
"Hosted wallets" refers to wallets that are hosted by a website, i.e. a company, and are not controlled by you. I.e. Kraken is technically a hosted wallet (in addition to being an exchange).
I think you misunderstand - a hosted wallet doesn't mean that users don't pay each other directly - they still do - it just refers to a setup that is closer to PayPal than Bitcoin
PayPal is a "money services business".
(i.e. users not owning/controlling their private keys, and letting a company do it for them).
Like BitPay?
"Hosted wallets" refers to wallets that are hosted by a website, i.e. a company, and are not controlled by you. I.e. Kraken is technically a hosted wallet (in addition to being an exchange).
I'm still not understanding how this is different from what you described. Kraken also "automatically be [gives] BTC/LN addresses" and has an "address they can copy and a QR code they can scan using mobile wallet software." Can you clarify what I'm missing?
Like BitPay?
Yep. We would not be like BitPay, but we could add support for a service like theirs (unlikely, but that's what my statements above meant).
I'm still not understanding how this is different from what you described. Kraken also "automatically be [gives] BTC/LN addresses" and has an "address they can copy and a QR code they can scan using mobile wallet software." Can you clarify what I'm missing?
Kraken holds your keys, whereas with a normal wallet your keys are stored locally on your computer.
OK, thank you for answering - I have a clearer idea of how this will work now. However, I also have the same question as @dotmacro: if Group Income creates a wallet for me when I signup, I can't use my personal wallet, that I have somewhere else, right? I would always have to send it from my wallet to the Group Income wallet and eventually to another member's Group Income wallet and they, again, would send it to their wallet somewhere else. Am I missing something here @taoeffect ?
I'm hearing different questions from the two of you, one mainly related to legal concerns, the other related to design concerns...
if Group Income creates a wallet for me when I signup, I can't use my personal wallet, that I have somewhere else, right?
You can, but that would require you choosing the manual payment option. There is no way for Group Income to automate an unsupported wallet.
I would always have to send it from my wallet to the Group Income wallet and eventually to another member's Group Income wallet and they, again, would send it to their wallet somewhere else.
Ah, I see where you're going with this. This is correct for the sender. For the receiver it would be OK for them to simply enter their LN address (or maybe BTC address if we support that), which can be managed by a totally separate wallet. But for us to be able to automate sending multiple payments to multiple people with 1-click, that requires us to have control of the sending wallet.
@mmbotelho A note regarding what I said here:
This is correct for the sender. For the receiver it would be OK for them to simply enter their LN address (or maybe BTC address if we support that), which can be managed by a totally separate wallet.
That approach would, however, also assumes that they have a LN/BTC wallet, which for most people isn't true. So maybe some users do have an external wallet, and some don't. For those who don't we'd need to give them the built-in one. If we're managing a wallet for them anyway, we might as well do it for all users (is my reasoning).
Does this mean that we need to have all the functionality associated with a Bitcoin wallet in Group Income? By this I mean, having the option to send money, receive money from someone external to Group Income, manage addresses, etc etc etc? @taoeffect
Does this mean that we need to have all the functionality associated with a Bitcoin wallet in Group Income? By this I mean, having the option to send money, receive money from someone external to Group Income, manage addresses, etc etc etc? @taoeffect
With a Lightning wallet (which is somewhat similar, I think). You are asking good questions. It would be a pain for us to have to have a full-fledged wallet implementation, so we're unlikely to do that. We'll implement only the bare minimum we need, and we can use code from existing open source lightning wallets to do so. We don't need a full-blown wallet UI.
There's also still the question of whether or not we'll go the Interledger route, and how that would work. That's really an unexplored question TBH, as it's still a new protocol that has few implementations for it. For now I'm inclined to include a basic LN wallet implementation and see what we can do with that.
Here's a possibly useful article: https://blog.bitrefill.com/top-11-lightning-network-wallets-bitrefill-328b5465b1b4
Ok, I need us to converge now and come up with a clear list of tasks for what I have to design for the prototype. I am 100% sure that we need to:
- Add the option to send partial amounts to users (for all payment methods);
I have questions about:
- Do we want to implement some type of digital payment option for the prototype? If yes, which one exactly?
- Do we want to add the option to send payments with Stripe and/or Paypal for the prototype? If yes, which ones exactly?
- If any of the options above is true, then is it technically possible to have a way to click one button and pay everything? Or, even better, will we be able to create an opt-in feature where users can create recurring payments?
- Should users be able to set one or more payment/receiving methods? I think this would be a good experience;
- What about the emails? We didn't discuss that yet. As I mentioned in the issue, I think it's very important to notify users via e-mail about payments (whether they are sending or receiving).
I can only continue working on designing these flows if I have all of these questions answered. cc @taoeffect @dotmacro
I forgot one question - I remember @taoeffect mentioning during the hackathon that this feature is also essential for the financial survival of the Group Income project in the future. Can you explain in a bit more detail how you were picturing that (in the context of this feature)?
Do we want to implement some type of digital payment option for the prototype? If yes, which one exactly?
No. For the prototype it will only be manual payments, but we need a UI for the PayGroup page that would also work with digital payments if we had implemented them, just like we have for the Income Details modal.
Do we want to add the option to send payments with Stripe and/or Paypal for the prototype? If yes, which ones exactly?
Hard no. Unlikely to do that even for the 1.0.
If any of the options above is true, then is it technically possible to have a way to click one button and pay everything? Or, even better, will we be able to create an opt-in feature where users can create recurring payments?
So, when we get to implementing in-app payments, we will do so with a single digital payment option. Lightning Network seems the most promising option right now. In the very very distant future, we can add other payment options if users want them, but for the sake of our sanity, it is best to pick one, do a good job with it, and re-evaluate other options after we have something working well. All of the other payment options are implicitly supported by the manual payment option. You might want to think about UIs for this, for example, do we want users to be able to say, in the UI, "I manually payed Bob via PayPal"? If so, is that just a note that gets attached to a manual payment? etc.
Regarding recurring payments: the moment you start talking about those is the moment you involve a trusted third party into the equation and you have to start wondering about the legal issues @dotmacro was raising before. We can certainly implement recurring payments into the backend, so that the server operator is treated as the custodian of your $, and you trust them to not run away with your money, but for now let's just focus on the 1-click approach.
Should users be able to set one or more payment/receiving methods? I think this would be a good experience;
I think it would be good for the UI to allow users to specify, for example, their PayPal email, or whatever else. This will make it easier for other users to pay them manually without having to ask them for their payment info. Just because they enter their PayPal email, however, does not mean we will be able to do the PayPal transfer for them. For the prototype, this would certainly be a manual payment done by the user, with them copy/pasting the PayPal email out of the Group Income UI, manually transferring the displayed amount in PayPal to that email, and then back in the Group Income UI clicking something to tell Group Income that a manual payment was sent, entering how much was sent (if different from the total needed), etc.
What about the emails? We didn't discuss that yet. As I mentioned in the issue, I think it's very important to notify users via e-mail about payments (whether they are sending or receiving).
Yes, as it so happens I'm working on implementing our own newsletter server, and I can use that to also implement sending emails. The backend of Group Income will likely connect to several servers, including email, Lightning, etc.
Can you explain in a bit more detail how you were picturing that (in the context of this feature)?
Sure, each payment that is done within the app can have attached to it a small optional donation to support the project. And similarly, users can additionally add the Group Income dev group into their group (although that is a longer way off).
but we need a UI for the PayGroup page that would also work with digital payments if we had implemented them, just like we have for the Income Details modal.
Why do we need this? And what does this mean in practical terms? That I should design how it would look if we had it? Is this design just for us or is it for our users as well? I don't understand exactly what you mean here. Another way to ask this is - what is our interface not doing at the moment that you think it should?
I think it would be good for the UI to allow users to specify, for example, their PayPal email, or whatever else. This will make it easier for other users to pay them manually without having to ask them for their payment info.
I think this is a great idea! This makes both our users and our lives easier. Nice.
Yes, as it so happens I'm working on implementing our own newsletter server, and I can use that to also implement sending emails. The backend of Group Income will likely connect to several servers, including email, Lightning, etc.
Awesome!
Sure, each payment that is done within the app can have attached to it a small optional donation to support the project.
Since we will only have manual payments for the prototype, I'm assuming that this is for the 1.0 right? @taoeffect
Another way to ask this is - what is our interface not doing at the moment that you think it should?
Right now we have a single button on the PayGroup page that says "Mark As Paid".
What we need instead is a button that says "Send Payment [v]" with a drop-down-to-modal or "Send Payment" directly to a modal.
From that button I need to be able to see that I have the option of sending a Bitcoin payment via Lightning. This can be unimplemented, like it is in Income Details, but it needs to be there. The other option I need to see (that will be implemented soon; cause i'm working on it :P), is the manual payment option, which needs to let me specify how much I'm sending, along with a note or something, so that I can send a payment that tells the other user how I paid them (via cash, paypal, bitcoin, etc.), and anything else relevant to the payment.
This needs to create a payment. I should be able to send multiple such payments for different amounts, up to the point of sending them the total that Group Income says I need to send them.
On the receiving side I should see all of the payments received, from who, via what method, and all the notes (if any are included) for each payment, along with the payment status, and for manual payments, be able to say that I didn't receive them.
Since we will only have manual payments for the prototype, I'm assuming that this is for the 1.0 right? @taoeffect
Yep!
see that I have the option of sending a Bitcoin payment via Lightning
I don't think this is necessary. It will only confuse users and add unnecessary information and complexity to the most important user flow in the app. What is the point here? To show which features are coming in the future? If that's the case, we can do it in a more elegant way, maybe with a text label saying that support for Bitcoin payments via Lightning is coming soon. I have a big problem with this, however, and that is that it's very frustrating for users to see a "coming soon" for 6 months or more. This is a bad experience and gives a bad image of the team developing Group Income. I think we should only promise things when they come tied with a very strict timeline, which we don't have yet. This is also true for the Bitcoin option we have in the Income Details modal.
Everything else you mentioned about partial payments sounds good to me, and it's very in line with what I already started designing.
On the receiving side I should see all of the payments received, from who, via what method, and all the notes (if any are included) for each payment, along with the payment status, and for manual payments, be able to say that I didn't receive them.
For the prototype, it's only possible to send manual, right? So the "via what method" part is not necessary. Showing the notes, however, is very relevant (great idea by the way @dotmacro, that email you designed in the hackathon was awesome).
Other than that, everything else you mentioned sounds good to me. I must say that I'm still a bit worried that the experience is not as automatic as it should/could be, and very labor-intensive for our users. I believe we should be able to do that once we start playing with Lightning.
and that is that it's very frustrating for users to see a "coming soon" for 6 months or more. This is a bad experience and gives a bad image of the team developing Group Income. I think we should only promise things when they come tied with a very strict timeline, which we don't have yet
OK, well, can we at least say somewhere that additional payment methods are coming?
For the prototype, it's only possible to send manual, right? So the "via what method" part is not necessary.
It will need to be there eventually. We are definitely planning on adding additional payment methods. So it would be helpful to see the payment method, even if for the prototype the column says "manual" for each payment. Otherwise we'd be implementing a design that we know we have to change, and for what? To add a single column? Let's just add that column now and avoid the minor redesign to add it later. EDIT: it's possible there's a misunderstanding going on here, but we can figure this out as some of the designs are starting to form, or on a call.
OK, well, can we at least say somewhere that additional payment methods are coming?
We can and we should! But when it comes to our communication strategy, it's very important to identify the right moment to "advertise" something, and the moment to keep communication as simple and functional as possible so that users can perform whatever action they need to as fast as possible. A good place to advertise this would be, in my opinion, social media, blog posts, newsletters, and other similar mediums. When we do have a definitive timeline for the feature to be released, we can bring it inside the app and communicate it there as well in some non-obtrusive place. Github has something similar:
Note that they place it on their dashboard, a very non-obtrusive place (as opposed to a PR page or something similar).
Otherwise we'd be implementing a design that we know we have to change, and for what? To add a single column?
Well, this is an interesting difference between the mindset when we are coding vs. designing. My job is well done when I present only the necessary information that users need at the moment (in other words, providing the least amount of information for the maximum amount of meaning). Therefore, adding a column that users don't need now, just so we don't need to spend a max. 1 hour adding it in the future does not have the best interest of our users in mind. I can, however, mock it up and pass it on to @pieer or @sandrina-p, so they know what's coming in the future, and code the interface with that in mind. But I would advise against showing that information to the user if it's redundant @taoeffect .
OK, well, can we at least say somewhere that additional payment methods are coming?
I have a suggestion (based on some flows I saw in other websites): When informing the user other payments are coming, there's a link to a page/form asking the user what's they prefered method from a list of payments where they answer if they use it or are interested on it. (It can even link to a issue/forum page for them to add their direct feedback). That way we are more confident about what payment method we should focus on.
A lot of good thoughts have been discussed here, I would like to leave just my opinion about what I agree with:
- The user should receive an e-mail notification about payments - a reminder to pay or a summary of payments received.
- Option to send partial payments.
- Optional to leave a note about the payment.
- The layout should be as simple as possible. We should remove "coming soon" whenever possible for the reasons mentioned by @mmbotelho.
- Have a place to let users specify their own receiving payment methods (paypal email, bitcoin address, wtv...) visible to the payer, to facilitate the "manual" payment.
I'd like to emphasize that our work, as designers and developers, is a constant work in progress. We'll be always ~redesigning~ evolving design and code files based on the users' needs. Trying to predict/guess the future is a lost game. I'm totally okay with "picking" at @mmbotelho's designs to have a better sense of how the code should be shaped, but that shouldn't influence/compromise the final user experience.
I have a suggestion (based on some flows I saw in other websites): When informing the user other payments are coming, there's a link to a page/form asking the user what's they prefered method from a list of payments where they answer if they use it or are interested on it. (It can even link to a issue/forum page for them to add their direct feedback). That way we are more confident about what payment method we should focus on.
I think this is an interesting idea @sandrina-p ! Good way to collect specific user feedback. What do you think @taoeffect ?
Another thing I noticed based on this thread: The way we refer to "manual payment" vs "bitcoin payment" basically is the same: both are "manual payments" because in both cases the user needs to perform manual steps. For me, anything different from "subscription mode" is manual.
I think we should rename the way we approach each one. At the moment we have 3 payment variants:
- custom payment: a payment that we don't support/facilitate the process, such as PayPal, IBAN transfer, cash, etc...
- assisted method: a payment that we (will) facilitate, such as "bitcoin payment", but the user still needs to do a manual recursive step such as click "send payment"
- automated method: a full automated/subscription mode, where the user only needs to setup once and we (GI) will take care of the rest. something easier said than done.
Hey everyone! I have a VERY ROUGH figma flow to share with you. Please be aware that the whole payment system re-vamp is very complex and that all the pieces of the puzzle are not on the mockups yet, but that I do have a general idea of how they’ll fit together. I don't usually share my work at this stage, but because this is such a critical feature, I want to move slowly and surely - so keep in mind that this is not ready yet.
What's on these screens ATM?
- How to add your payment information;
- How to record payments on GI;
- A rough draft of a possible member profile;
The feedback I need ATM:
- The flow itself - can it be more user-friendly?
- Copy - is everything clear?
- Possible missing actions or features.
You can also leave feedback on the UI itself, but please remember that after all the flows are figured out, I'll be reviewing that in more detail.
Another change I think is relevant to mention here (might not be clear in the mockups) is the idea that our application should be more optimistic - in this context, this would mean that all payments are marked as successful once they are recorded, and only if a user explicitly says that they have not received a payment, we notify the sender. Since all payments are manual, we can also assume that the other platforms / systems the users are using already notify them if there's a problem with their payment. This saves a lot of work and makes the app easier to use.
Thank you!
https://www.figma.com/file/mxGadAHfkWH6qApebQvcdN/Group-Income-2.0?node-id=6189%3A54453
What do you think @taoeffect ?
I think we should hold off on thinking about that for now for a few reasons:
- We do not have a place to collect user feedback yet, except these github issues.
- We do not have users yet. We should get those first after launching our prototype.
- The payments design isn't finalized yet for the prototype
I also have a strong preference for implementing Lightning as the first payment option, regardless of what users think they want, because as we know, users usually don't know what they want or what is possible, and also because as mentioned in the Slack convo, it's very much needed for the survival and sustainability of the project.
Once we have all of the above we can certainly proceed forward. But even Github did not start introducing these "coming soon" banners until after they had an established way of financial survival that worked.