How to plan for console migration to Paste for Account Security BU (Office hours Feb 4, 2021)

[mjanssen2021]

The specific questions I have are...

• What exactly is the "migration to paste" meaning exactly?
• What is the current timeline that all twilio console products are expected to be migrated to paste?
• Is my team behind in this migration?
• What about specific components? Are there some we should migrate first for whatever reason?
• My team is working with a toggle button however the current developer (Roland) created a new toggle component that overrides the old one to migrate to paste. It functions exactly like the old one but he will need to replace it with the paste component when that comes out in Q3.

Background: I am a newish designer to the account security BU and hear concerns from some front end developer on the migration to paste. I am trying to wrap my head around timelines for the migration to paste, what it means, and how I can help my team plan for this in conjunction with the console Beta updates.
Stage of design: Discovery
Research: N/A
Links to mockups or prototype: None

[serifluous]

Hi @mjanssen2021, welcome to Twilio + Paste. Thanks for reaching out!

We'll go through your questions in more detail in just a bit, but because we haven't worked too closely with the Account Security BU in the past, some more info could help us out:

• Can you share some sample screenshots of products/screens you're thinking of migrating to Paste? (especially the screen with the toggle you're referring to)
• Do you have sample screens/products that you're most unsure about whether your team can migrate to Paste?
• Do you know if your products are using components from the Console React Components library right now, are they built in PHP, or something else?

Generally, migrating to Paste means that your product is using Paste and its components as your primary front-end and design library. There are a few ways to adopt Paste outside of just our styled components—we have tokens and primitive (unstyled) components (read more) for cases where our current set of components doesn't quite fit your needs, which you might find helpful for something like the Authy mobile app (since it can't use the Paste components built in React).

But! We strongly recommend using Paste components whenever you can so your product aligns more closely with the rest of Twilio products, and your team gets a clean & safe upgrade path for design updates. It's more straightforward to update an out-of-the-box component of ours than updating something more custom.

There's no deadline or expectation we give about when Twilio products should migrate to Paste. We don't have full insight into every BU's priorities, so it's up to the BUs when they feel it's appropriate to migrate. We've generally seen that teams tend to migrate to Paste on a feature-by-feature or flow-by-flow case, rather than take on a whole migration of their product at once—This is also what we usually suggest so that a migration can be done a little more safely, and you have room to test out the implementation while releasing a product feature update.

Regardless, we're super happy to work with you and your team to plan out a migration! Constraints vary from BU to BU, so we can give more tailored suggestions based on what you know of your product priorities and timing. Definitely invite the engineers and PMs on your team to office hours if you can, and we can chat more in-depth.

[serifluous]

@mjanssen2021 Hey Margot! Rounding out the convo here from office hours on the toggle:

We recommend using a Checkbox or Radio instead of trying to build a custom Toggle for now. Toggles are a little bit tricky to build and use, especially when they're on the same page with a lot of form fields. There's still some vetting we'll want to do with the legacy console-style Toggle, too.

(I'm not sure what Roland's public GitHub username is, but feel free to direct him to this thread to follow up if he has more questions, too!)

[mjanssen2021]

@serifluous Thank you for all the help!