META · CONTENT DESIGN · ACCOUNTS CENTER

Building a new contact-point management experience.

I worked across teams and functions to develop a new experience in Meta’s Accounts Center to help users manage their contact points on Meta’s family of apps. This required deep product knowledge, an understanding of backend complications, and the ability to clearly explain to our legal and privacy partners any functional complications and how they impacted user-facing language.

THE PROJECT

A new place to manage contact information across accounts.

Accounts Center was a cross-company effort to create a central hub for people to safely and seamlessly control all account-level settings across one or multiple Meta accounts and profiles, simplifying how people manage their accounts and associated settings while removing redundancy across apps.

For the team, our goal was to build a new experience for managing contact points across linked accounts without introducing additional legal or privacy risks. The launch started with Facebook and Instagram, with other connected apps to fast follow. The apps didn’t treat contact points the same way, across product flows or backend logic.

MAJOR BLOCKERS

MAPPING THE OBSTACLE COURSE.

Two very different backends

Differences in backend app logic impacted contact point states. And those inconsistencies broke the Accounts Center mental model. We had to solve for all of it to move forward.

Moving targets

Our designs needed to account for future scalability (more Meta apps, more user profiles), yet some functionality solutions fell outside project scope. The scope we had agreed to was also getting new requirements by the day, affecting lots of little details.

Too many cooks

Since other settings and experiences were being simultaneously migrated across Accounts Center, negotiations with outside teams were required to bring parity across experiences. I also needed to create alignment on our team—across product, engineering, legal, privacy, policy, and design leadership.

FIRST THINGS FIRST

understanding the system.

I spearheaded a cross-functional audit of contact-point flows and backend behavior. The work gave the team a shared picture of what existed, where the apps behaved differently, and which requirements were still missing. Content design became a way to make the system legible to the organization, not just to the person using the UI.

Required user actions

• Adding a contact point
• Deleting a contact point
• Replacing a contact point
• Adding an existing contact point to an existing account (like taking your number on Facebook and adding it to your Instagram account so you can use it to login)

Contact point states

• Visibility (where you can see it)
• Reachability (how Meta uses it on the backend)
• Pending (whether it’s been confirmed)
• Shared (whether the contact point is being used by multiple users)
• Recycled (when a new user claims a previous user’s contact point)
• Security contact point (contact points added specifically for security purposes, which impacts their usability by Meta)
• Last contact point (IG and Facebook had different rules around number of contact points)

INTERWOVEN WEB

designing for exceptions.

The solutions couldn’t just work for the cleanest version of the flow. It had to account for different deletion states, unreachable contact points, overlapping account states, security-only contact points, disclosure requirements, and situations where one app could complete an action the other couldn’t.

Rather than create a different experience for every edge case, we reused shared components, introduced dynamic messaging where behavior diverged, and built fail-safe paths for states that couldn’t resolve cleanly.

ADDITION AND SUBTRACTION

managing a contact point.

A user’s main objective would be adding and deleting. My main objective was making it as easy and clear as possible while working around overlapping rules and constraints.

Progressive disclosure

If the number already belonged to another linked account, the experience had to explain what would change before the person committed. Using progressive disclosures nested into the flow allowed a clean design for a heavy amount of information.

Adding to another account

One of the missing pieces content design influenced in the 11th hour was making sure you could add any linked accounts to existing imported contact points.

Final disclosure copy

A big part of this project was making sure not to expose the business to new risk by making users aware of how Meta would be using their contact points.

Deleting a contact point

Deletion behavior depended on the state of the contact point, so the copy and available actions changed with it.

STATE + VISIBILITY

MAKING IT CLEAR WHO CAN SEE WHAT FROM THE GET-GO.

I advocated for clearly surfacing contact-point state and visibility. Product design leadership initially pushed back, but existing research supported showing it. When I brought the problem to our team discussions, privacy and policy team members agreed and pushed for even more required visibility disclosure. User need and compliance pointed in the same direction.

Because visibility options were owned by outside teams, we could expose behavior without controlling the flow.

FINDING A REPLACEMENT

GOING BEYOND A DEAD END.

The audit surfaced a missing replacement-contact-point flow and a missing requirement for adding an existing number to another account.

Rather than create new bespoke behavior, I proposed reusing existing components and built a content matrix that made the states and messages explicit. Those solutions avoided additional engineering work and helped protect launch timing.

STATES OF MIND

SCALABLE BEHAVIOR FOR contact point STATES.

Clearer surfaced information around overlapping contact point and security contact point states.

States requiring action

Pending or incomplete states had to be visible enough that people could understand what needed attention.

Indicating states & their meaning

A contact point’s state needed to be clearly surfaced and explained since behavior and disclosures differed across states.

ENSURING ALIGNMENT

disclosure approval process.

END TO END

A clearer system.

Once the underlying states were clear, the work became much more concrete: give people the right action, disclosure, and recovery path for the state they were actually in.

The final work aligned product behavior, disclosures, component reuse, and cross-functional understanding around a system that spanned multiple apps.

Consistency across the broader Accounts Center experience (making sure our designs were in line with all the other newly created settings).

Clearer surfaced information about contact point and security contact point states.

Accounts Center-specific disclosures for initial launch (bridging a gap between individual app disclosures and a future Meta state of a single login).

Interim solutions for reachability (business) goals, like prompting contact point confirmation.

Additional risk mitigation for highly scrutinized flows.

Fail-safe solutions for current and future edge cases (the more app intermingling, the more edge cases).