[CRITICAL] [Splits] Show Split bill in global create, separate out the split and request flows

[kevinksullivan]

DESIGN DOC

Problem

As it's been discussed in this thread and elsewhere, our approach to merging both split and request into a single flow is very confusing, for a few reasons:

1. It makes seem like you have to split a request with someone, when in reality the more common flow is requesting money from one person
2. It's not clear that there is a path to requesting "normally", which can be done by tapping the row outside of the split button. This means each row has two very different possible actions, but only one is visible in the UI

We've had 10+ people at our company mention this as a point of confusion when requesting money from friends or while testing the Collect experience as a member requesting repayment from a workspace.

Solution

Let's address this problem by:

1. Bringing back a dedicated Split bill option within global create, under the Request money option. This will help us differentiate between the flows, and promote a use case we want users to be aware of.

2. Removing the "split" button from the request money flow

Outstanding considerations

Going to jot down a few thoughts on this one here, just so I have it written down.

How should the split bill flow work for making a single selection v. multi-selection?

We have a few options that I can think of, and likely many others:

1. Making any selection go straight to the 1:1 confirmation screen, and then showing a + icon on the confirmation screen, as shown here).
2. Keep it similar today, where the button says something like Add to split for split, and and tapping that option supports multi-select, or tapping outside of the button goes straight to the 1:1 confirmation screen (doesn't address the problem of one row two actions)
3. Anytime a user makes a selection, showing Continue, before landing them on the confirmation screen, making it clear you can select multiple users. This makes the 1:1 split flow less efficient, but I think that is going to be a pretty rare flow if we have a dedicated request flow.

Should the Request money flow allow for adding multiple people to a request?

Today we don't allow requesting money from multiple people at once. It has to go through the split flow. So, do we want to change that? I'm on the fence. I've long used venmo to send requests to a bunch of people at once. But now, they've essentially baked that into a split flow, and I can see a pretty clear case for not needing it at all.

### Implementation

Implementation issues created, will be implemented in the following order:

1. External [vip-split] [Split Expense] Cleanup all instances of "request" and "send money" in App #40070 @shubham1206agra @getusha
2. External [vip-split] [Split Expense] Refactor Participant Selector #40071 @getusha @shubham1206agra
3. Internal [vip-split] [Split Expense] Update copy changes in backend #40072 @mountiny
4. External [vip-split] [Split Expense] Implement route changes in NewDot for updated Global Create #40073 @shubham1206agra @getusha
5. External [vip-split] [Split Expense] Clean up instances of request terminology in HelpDot #40074 @shubham1206agra @getusha
6. Internal [vip-split] [Split Expense] Clean up the money request terminology in app to use expense #40075 @mountiny

[melvin-bot]

Triggered auto assignment to @shawnborton (Design), see these Stack Overflow questions for more details.

[melvin-bot]

Triggered auto assignment to @kadiealexander (NewFeature), see https://stackoverflowteams.com/c/expensify/questions/14418#:~:text=BugZero%20process%20steps%20for%20feature%20requests for more details.

[kevinksullivan]

posted this ^ as a quick pre-design

[shawnborton]

@kevinksullivan let me know when and where I can help with this. Maybe we just need to see how the pre-design settles first and then we can create final mocks from there?

[kevinksullivan]

pre-design went out here. Next step I think we follow up with an option that show's option 3 from the pre-design in more detail than I presented it, then we can explore a mini-doc or just GH it. @shawnborton what do you think?

[shawnborton]

Posted some ideas for ya here.

[kevinksullivan]

Working on the doc

[MonilBhavsar]

I have read and reviewed this Design Doc!

[isabelastisser]

I have read and reviewed this Design Doc!

[nkuoch]

I have read and reviewed this Design Doc!

[trjExpensify]

I have read and reviewed this Design Doc!

[jliexpensify]

I have read and reviewed this Design Doc!

[amyevans]

I have read and reviewed this Design Doc!

[quinthar]

I have read and reviewed this Design Doc!

[JmillsExpensify]

I have read and reviewed this Design Doc!

[mountiny]

Implementation issues created, will be implemented in the following order:

1. External [vip-split] [Split Expense] Cleanup all instances of "request" and "send money" in App #40070 @shubham1206agra @getusha
2. External [vip-split] [Split Expense] Refactor Participant Selector #40071 @getusha @shubham1206agra
3. Internal [vip-split] [Split Expense] Update copy changes in backend #40072 @mountiny
4. External [vip-split] [Split Expense] Implement route changes in NewDot for updated Global Create #40073 @shubham1206agra @getusha
5. External [vip-split] [Split Expense] Clean up instances of request terminology in HelpDot #40074 @shubham1206agra @getusha
6. Internal [vip-split] [Split Expense] Clean up the money request terminology in app to use expense #40075 @mountiny

[shubham1206agra]

@mountiny The order of 1 and 2 is wrong. We will do 2 first.

[pecanoro]

I have read and reviewed this Design Doc!

[getusha]

@mountiny The order of 1 and 2 is wrong. We will do 2 first.

@shubham1206agra the current order makes sense to me 🤔

[shubham1206agra]

@getusha See design doc.

[grgia]

I have read and reviewed this Design Doc!

[mountiny]

Daily updates in the vip-split room. We are chugging along well to meet the Release 1 deadline

[shawnborton]

I see this one is implemented in the product already, right?

[kevinksullivan]

Yes, this is live! I'd say we can close this out. @mountiny lmk if you think differently!