New collective flow

[xdamman]

Here is the wireframe version open for feedback.

Please have a look.

Prototype:
https://www.figma.com/proto/KinuveYf4WUlRIXzMTnmIsmO/OC.COM-XX1-Lab?node-id=1198%3A18753&viewport=743%2C489%2C0.08176331967115402&scaling=min-zoom

Figma overview:
https://www.figma.com/file/KinuveYf4WUlRIXzMTnmIsmO/OC.COM-XX1-Lab?node-id=638%3A12661

[Memo-Es]

Good! We like it

[alanna]

Overall, it's great! So much better than the current experience!

I especially like:

• That you get up and running very quickly with minimal data entry.
• How you arrive to your new Collective page and the design guides to add more content and activate sections.
• Splitting all the questions out into different screens so you're not overwhelmed with too much info at once.
• Putting extra options in places where it feels natural, like suggesting they add tiers after they've activated financial contributions.

Notes:

• When creating new user instead of "add" it should be "invite". The person should receive an invitation and click accept. At that point we will show them the terms of use, etc.
• We decided not to use the word "team" to refer to core contributors. The terms are "core contributor" and "Collective Admin" (or just 'contributor' and 'admin' is fine here).
• Why add other core contributors before the page has been created, while we push everything else to after the creation step? To me it makes more sense to treat it like all the other sections on the blank new Collective page that are encouraging you to take actions, such as activating financial contributions, making an update, etc. Adding more contributors could be like this, to make the initial startup experience even more simple and quick.
• What is the purpose of including the "values" screen here? Is it meant to just be a friendlier version of the content of the terms of service? I think we should be careful of the wording because not all Collectives allow anyone to join and contribute, sometimes for good reasons.
• The 'contribute' section should come first when you arrive at the new Collective page. Activating financial features is the first thing most people will want to do, so it doesn't make sense to put it below updates.
• Should be "select or create organization" (so people who know they don't have one yet aren't confused) and if they are creating one it should say "create organization" not "create user".
• If they select an existing organization that they are not already an admin of, will it send some kind of validation to the org admin to accept them? Or should we assume no one would have a reason to say their money is held by an organization if it's not true? Would this be a "side door" way to get your Collective in a fiscal host without going through their approval process?
• Next to "connect stripe" and "add bank account" can we have "add paypal" since it's the next most common? The truly ideal feature would be user-defined payment methods, so a group who uses Venmo or whatever can just define that. Then these would show up as the contribution options. This is probably out of scope, but we're also facing this with the expense redesign (we will need to enable hosts to define their accepted payout methods so expense submitters can select from them) so I'm wondering if we should just take it on properly.
• One issue with applying to a fiscal host - as designed here, I don't think the user has had a chance or been asked to input much info about their Collective, such as description, website, etc. It seems likely this will result in host admins getting applications without any information to judge the Collective by. How can we deal with this? My dream solution would be to enable hosts to define some questions the applicant needs to fill out when applying, but I assume that's more part of the host dashboard project than this project, right?
• If a user clicks "apply" to select a fiscal host in this flow, does it take them out of the flow? Currently I think you end up going to the fiscal host's page, but if it's possible to keep them in this flow and just trigger the application, I think that would be better, because if they end up on the host's page then we kind of lose them before completing this creation experience.
• It seems like this design "silently" creates a host for self-hosted Collectives without really talking to them about "fiscal hosting" as a concept. That's perfect, and will be great for that use case. I assume this will set the toggle for "accept applications from Collectives" to OFF in their fiscal host settings?
• Instead of "go back to your Collective page" how about the button says "finish"? It's a pretty complex process they've just gone through and it should be clear when they've reached the conclusion.

When we will be able to see the screens for after they click the "open source" option at the start? I think there are some issues to sort out there, like:

• Not all Open Source projects want to join Open Source Collective. What happens to them if they click the open source option at the start? Some will want to be self-hosted, some will want to join OC EU, etc. (Although the majority will be looking to join OSC).
• Can we please fix the bad experience people are having who want to join OSC but do not want to verify using the Github stars flow? This comes up a lot and our current design is confusing.

[piamancini]

Great progress, this is brilliant. Two comments:

Page 9: should be People not Peoples

Page 11: Account holder should be bank account holder, otherwise it's confusing with the holder of the open collective account (owner of the profile)

When we will be able to see the screens for after they click the "open source" option at the start? I think there are some issues to sort out there, like:

+1

[Betree]

This is good! The only feedback I'd have is that having the Create an account and Login forms on the same page is confusing to me (too many fields, two primary calls to action).

[xdamman]

Thanks for this extended review @alanna ! :-)
See my responses below.

When creating new user instead of "add" it should be "invite". The person should receive an invitation and click accept. At that point we will show them the terms of use, etc.

ok

We decided not to use the word "team" to refer to core contributors. The terms are "core contributor" and "Collective Admin" (or just 'contributor' and 'admin' is fine here).

ok

Why add other core contributors before the page has been created, while we push everything else to after the creation step? To me it makes more sense to treat it like all the other sections on the blank new Collective page that are encouraging you to take actions, such as activating financial contributions, making an update, etc. Adding more contributors could be like this, to make the initial startup experience even more simple and quick.

The idea is to make sure that after the creation process flow you know and you can already share:

• the URL of your collective
• the email address of your collective (which requires you to understand who will receive the emails sent to this address)

What is the purpose of including the "values" screen here? Is it meant to just be a friendlier version of the content of the terms of service? I think we should be careful of the wording because not all Collectives allow anyone to join and contribute, sometimes for good reasons.

The goal is to make a more fancy "please accept the terms and conditions" and share the general values in plain English.

Those should be values that can apply to all collectives. Do you want to take a stab at suggesting what those should be?

If one shares code on Github, they share the value of "transparency", "anyone can contribute" (which doesn't mean that all contributions are accepted), etc.

The 'contribute' section should come first when you arrive at the new Collective page. Activating financial features is the first thing most people will want to do, so it doesn't make sense to put it below updates.

That might be true for the OSC because collectives haven't had any financial contribution/transaction before creating an open collective. And their goal when creating an open collective is to collect money.
So let's definitely make sure that this is the first section for them.

For self hosted collectives, the priority should be given to the budget (and manually recording transactions).

Updates should be the first thing returning users see on a collective page, in the same way that when you open facebook, their first show you "new things you haven't seen yet".

Should be "select or create organization" (so people who know they don't have one yet aren't confused) and if they are creating one it should say "create organization" not "create user".

ok

If they select an existing organization that they are not already an admin of, will it send some kind of validation to the org admin to accept them? Or should we assume no one would have a reason to say their money is held by an organization if it's not true? Would this be a "side door" way to get your Collective in a fiscal host without going through their approval process?

You can only select an organization that you are an admin of.

Next to "connect stripe" and "add bank account" can we have "add paypal" since it's the next most common? The truly ideal feature would be user-defined payment methods, so a group who uses Venmo or whatever can just define that. Then these would show up as the contribution options. This is probably out of scope, but we're also facing this with the expense redesign (we will need to enable hosts to define their accepted payout methods so expense submitters can select from them) so I'm wondering if we should just take it on properly.

Out of scope, but yes, I would totally love to add that. This design makes it easy to do so in the future.

One issue with applying to a fiscal host - as designed here, I don't think the user has had a chance or been asked to input much info about their Collective, such as description, website, etc. It seems likely this will result in host admins getting applications without any information to judge the Collective by.

That's a great point.
Note that in this process, you first get to see your collective page (and therefore get the opportunity to make it look good with logo/cover/description) before you get to apply for fiscal host.

However, it is indeed very possible that some people may apply before providing all that info.
I'd suggest that we disable the 3rd option with a message "before you can apply for fiscal sponsorship, please make sure that you have added a proper description to explain in more details the activities of your collective and how you plan to spend the money that you will be collecting".

How can we deal with this? My dream solution would be to enable hosts to define some questions the applicant needs to fill out when applying, but I assume that's more part of the host dashboard project than this project, right?

That would be indeed great. But yes, I'd keep that for another project.

If a user clicks "apply" to select a fiscal host in this flow, does it take them out of the flow? Currently I think you end up going to the fiscal host's page, but if it's possible to keep them in this flow and just trigger the application, I think that would be better, because if they end up on the host's page then we kind of lose them before completing this creation experience.

There is one default / recommended host where they can just apply and then they end up in the screen where they can edit their tiers.

If it's not one of the recommended hosts, they can click on it to know more about them.
Maybe you'd prefer that we show directly the apply button below each host card, assuming that they can open in a new tab the page of the host if they want to check them out?

It seems like this design "silently" creates a host for self-hosted Collectives without really talking to them about "fiscal hosting" as a concept. That's perfect, and will be great for that use case. I assume this will set the toggle for "accept applications from Collectives" to OFF in their fiscal host settings?

Yes. By default, most people don't want to bother with someone else's collective. They will start by hosting their own, maybe a second one where they are also involved. It's a much more advanced feature to start hosting other people's collectives.

Instead of "go back to your Collective page" how about the button says "finish"? It's a pretty complex process they've just gone through and it should be clear when they've reached the conclusion.

I like that.

Not all Open Source projects want to join Open Source Collective. What happens to them if they click the open source option at the start? Some will want to be self-hosted, some will want to join OC EU, etc. (Although the majority will be looking to join OSC).

Yes, just added that in the flow. If you select "manually", it goes to the default flow for creating a new collective and the default host that will be recommended if you want a fiscal host will be the OSC.

Can we please fix the bad experience people are having who want to join OSC but do not want to verify using the Github stars flow? This comes up a lot and our current design is confusing.

This is fixed with the link below the "connect with Github" so that it gives a way for people to skip that flow (see screenshot above).

[znarf]

"Create Account" will still be confusing. People not familiar with our platform don't understand if they're creating a personal account or a collective there. We need to provide some hints.

[znarf]

The "Recommended fiscal sponsor" screen is too close to what we have today and doesn't address any issue that were highlighted in our preliminary discussions.

[xdamman]

@znarf We cannot address all issues at once. What issues in particular do you think that we should address in this first iteration in regard to that "Recommended fiscal sponsor".

I see your point for the create account. Then I'd suggest we simply reuse what we have today (but without the first name / last name since we are consolidating everything within Collective.name):

[znarf]

@xdamman The magic recommendation with one host based on tag and currency is just wrong and should be absolutely re-considered.

I would recommend to not try to filter by tag and currency, display a full list of hosts open for applications, with an highlight on "OSC / Europe / UK / Brussels / Paris" on top.

[Memo-Es]

For what I've been reading, it seems that this "Fiscal Host Application" needs to be designed as an individual experience and connect with different parts of the platform like this flow. Still, I imagine that this is a future project.
In that case, I would keep it as simple as possible and take the proper care to design this, and other flows to be navigated as a smooth, nicely wrapped experiences.

[alanna]

Thanks @xdamman ! Responses below....

• adding contributors

The idea is to make sure that after the creation process flow you know and you can already share the URL of your collective and the email address of your collective (which requires you to understand who will receive the emails sent to this address)

Personally I would still put adding contributors alongside all the other actions to expand your Collective after the initial creation, because lowering the barrier to initial creation is such an important goal of this redesign. As long as one admin at least (the creator) is getting the messages, it will be fine. If it's a priority for them to add people, they can do that first thing after creation.

• fancy terms & conditions screen

The goal is to make a more fancy "please accept the terms and conditions" and share the general values in plain English. Those should be values that can apply to all collectives. Do you want to take a stab at suggesting what those should be?

I support the impulse to make this interaction more human and warm, since accepting Tc&Cs is so cold usually. However, due to the importance of simplification in this project, I suggest leaving this out for now. There are too many variables to get right and also if we're changing it here we should change it every time we ask someone to accept the terms. Let's treat this as a seperate project for the future.

• order of sections after creation

For self hosted collectives, the priority should be given to the budget (and manually recording transactions).

Collectives using our system for manual expense recording, including self-hosted ones, are extremely rare. The vast majority some to us specifically for the financial features, namely enabling contributions. Until we have any other evidence, I think we have to respect how people actually use the platform. I understand you're trying to shift that with this redesign and I support that effort, but we still need to make sure the most common use cases can easily find what they are looking for.

Maybe trying to solve this with section order is the wrong approach, however. Upon initial creation there could be some kind of banner or helpful guide bubbles or something to help users understand all the actions they can take at that point to expand their Collective, regardless of which they want to focus on first. I have seen this in other apps and it seems to work well.

• ensuring Collectives have info hosts can judge by

I'd suggest that we disable the 3rd option with a message "before you can apply for fiscal sponsorship, please make sure that you have added a proper description to explain in more details the activities of your collective and how you plan to spend the money that you will be collecting".

I don't think this is the way to go, because it puts up a big barrier to the flow if someone is creating a new Collective and applying to an existing host. Instead, if they choose the fiscal host option can we just require them to fill out their "about" section as part of the flow? I'm wondering if we should actually ask all Collectives to fill that out as part of creation - you say you want them to be able to share their link immediately, so don't they need at least a basic description from the start? The other main field I'd suggest requiring in setup is website (they can leave it blank if they don't have one, but if they do have one it's the key info for fiscal host consideration).

• applying to host from within flow

Maybe you'd prefer that we show directly the apply button below each host card, assuming that they can open in a new tab the page of the host if they want to check them out?

Yeah I think this would be good, to keep them in the flow. It's important users check out the details of the host acceptance criteria, but they can click into their page to see that if they need to.

• Open source projects trying to join non-OSC host or self-host

If you select "manually", it goes to the default flow for creating a new collective and the default host that will be recommended if you want a fiscal host will be the OSC.

I still am not clear on how these flows will work for different cases. Can you create screens for:

• Open source project joins OSC
  • option 1: using github verification
  • option 2: using manual verification
• Open source project joins OC EU
• Open source project self-hosts

[xdamman]

I would recommend to not try to filter by tag and currency, display a full list of hosts open for applications, with an highlight on "OSC / Europe / UK / Brussels / Paris" on top.

@znarf ok - on it

lowering the barrier to initial creation is such an important goal of this redesign. As long as one admin at least (the creator) is getting the messages, it will be fine. If it's a priority for them to add people, they can do that first thing after creation.

@alanna I see. What about this:
Instead of asking the creator of the collective to add people (which I agree could take time and get in the way of getting things done quickly), what about we focus this second step on "email" (step one is "collective name / url", step two would be "collective email"). We could offer 3 options:

• info@:collectivelSlug.opencollective.com (default) (in which case we should show the current design where people can add more people that will receive the forwarded emails)
• another email address (simple email input field)
• a public url (e.g. link to your github issues page, or contact form on your website)
• none (people can only contact you by creating new conversations on your collective page)

Then the "continue" button. If people just click on it, the default will be the collective email will forward only to the creator of the collective.

• fancy terms & conditions screen

We anyway need a step to accept those. So let's get something simple done here.
I'll create a dedicated issue for it.
It's only text anyway so it's not blocking.

• order of sections after creation

I took note of your input and I'll make sure it will be working great for the OSC.

• ensuring Collectives have info hosts can judge by

Good idea. Let's make sure we ask them for a description and url if they haven't provided one yet.

• Open source projects trying to join non-OSC host or self-host

That's the flow. Unless they use the github auth, they fall back to the manual create collective flow

Whenever they will want to activate financial contributions, they will be given the classic options of self host or find a fiscal sponsor.

If they choose the latter, they will be given the option to apply to OSC or OC Europe or others.

But following @znarf's comment, we will redesign that screen to not recommend one host in particular but just surface all the hosts with a way to filter them by tag.

[alanna]

Ok sounds good @xdamman

I still think people are going to trip up trying to escape Github validation. To further improve the experience, I request the following:

• Instead of a big button for github and tiny text for manual, have two buttons of equal weight on that screen.
• Change the text to "Verify using GitHub stars" and "Request manual verification".
• I'll do an update to the text on that screen soon to help it be even more clear (no need to wait on that to move forward with your flow though).

[piamancini]

Instead of a big button for github and tiny text for manual, have two buttons of equal weight on that screen.

@xdamman + 1 to this - The current design you shared is optimized for github integration, but both pathways should have the same weight.