Portfolio
Includes a case study from my time at Meta to help show my thinking process, working style and experience.
FYI: All my work at Meta is subject to NDA. The info included here is public, and I've redacted or obscured anything confidential. Any views or methods I express are my own.
Case study:
Murphy's Law of social media
In the summer of 2021, Meta (known then as Facebook) was booming. The COVID-19 pandemic had seen more people using its suite of social experience products than ever before.
But as the number of users grows, so do the odds that something will go wrong in the user experience. Hacked accounts are one of the things that can and do go wrong.
I led the content strategy and design for Meta's response to this problem: a new Live Chat feature for hacked users.
Humans want help from humans
How do I contact Facebook when things go wrong?
More accounts = more account compromise.
By 2021, Facebook has a user base in the billions. FAQ libraries are one avenue for support, but they're static – always written in the past. They can't help every user who can't get back into their account after compromise.
How might we help these users? With a live chat support feature that meets them there in the product they are trying to restore normal access to.
Facebook Help article and one of many Reddit discussions
Designing for the disgruntled
How do you design something people would rather not use?
Good content design starts with setting principles and insisting on them. The principle here was that we were creating something based on user need, not user want. No one browses app FAQs for fun.
When you're making something, it's natural to want to give it a name. But as the lead content strategist and designer on this project, I quickly made this the guiding principle we would all refer to: live chat the verb, not live chat the noun.
Every UX content decision I made – what to call this feature, how to word the entry point, how to summarise the benefits of use to an obstructed and unhappy user – flowed from this paramount design principle.
Live chat is not a 'surprise and delight' moment
Planning for the spontaneous
Twenty heads are better than one
How do you design a conversation?
You can't. Conversations, even those that people enter to reach an objective, are spontaneous. What you can do is to draw upon frames of reference.
Using collective intelligence, that's what I did. By identifying and bringing together the people who could best infer what a victim of hacking might ask, pooling, and then parsing, their ideas, I was able to plan – and forward plan – agent-user conversations.
In the room is where it happens
Making the final call
Disagreeing and committing
"I don't like that word."
Every content designer will know how challenging it can be to get all invested parties to commit to a 'final' version. But when designing a support feature, language has to be, at core, utilitarian – design ≠ taste.
Having the confidence to welcome feedback, and the expertise to take the constructive and leave the not-so, smooths your path to launch. Stalemates result in stale content.
The product; opening and initiating a chat
In the wild
Releasing the real thing
My design thinking throughout this project was as careful and comprehensive as ever.
But when data and insight starts to roll in – and when users start talking to each other about their experience of a product – you have to move quickly, adjusting initial decisions and assumptions to respond.
{How I did this... putting the insight back into the product}
Facebook live chat is a talked-about feature
Making room for the future
Scaling up
Even when – as in this case – you're tackling multifaceted problems and deep technical complexity, a robust content strategy will have something to offer to forthcoming projects.
Transferring not just stuff – content hierarchies and pattern libraries, frameworks, playbooks – but wisdom.
A robust content strategy makes room for the future. It scales to other projects, transferring frameworks, patterns, playbooks and above all wisdom.
MISSING: edge cases/testing/realising -- how to cope with large amounts of info