This case study is password protected.
Enter the password to view it.
Incorrect password. Try again.
Modernizing Blackboard Learn's voice: building a content system.
Building a single source of truth to unify a fractured product voice across 20+ languages.
The problem
Blackboard Learn was a legacy learning management platform (LMS) and its voice was disjointed — each part of the experience felt like a different product. I didn't just need to fix the typos; I needed to build a single source of truth that would scale globally and empower everyone to write with one voice.
Snapshot
- Process
-
- One fiscal quarter for the POC, 2022
- Audits, user interviews, workshops, surveys, competitive analysis
- Cross-functional meetings with product and engineering
- Multiple content quality reviews with feedback
- Key results
-
- Localized for 60+ countries and 20+ languages.
- Created a single source of truth for a global, cross-functional design team.
- A smoother transition for legacy experiences into a modern, unified brand voice.
- My role
- This wasn't just a writing project; it was a cultural shift. I led workshops with product and engineering to gain buy-in, transforming a "lean voice chart" into a comprehensive content system adopted across the entire organization.
- Scope & constraint
- Blackboard Learn had just been acquired by Anthology when I arrived. The content was messy, the brand was in flux, and my job was to define a single modern voice for the entire platform — one that had to work in 20+ languages. That meant building a system, not just a document, as fast as possible.
Finding a way forward
I reviewed every button, label, modal, and microcopy pattern across the platform that I could find (there are some dark corners in that software), then benchmarked it against competitors to understand where Blackboard Learn stood. I even asked the development team to pull content strings. They begrudgingly agreed; however, it proved to be virtually impossible as Blackboard Learn was a product in limbo between being self-hosted and updated to a SaaS application.
Research proposalIt's easier to get buy-in from stakeholders when you have a clear path forward. So I put together our first research proposal — a simple study to gather voice and tone insights in a survey.
Research, test, and iterateSurveys and group sessions surfaced how users and teams actually talked about the product. From there I built a voice and tone chart, developed writing practices, and ran workshops to test whether the guide actually worked in practice.
Two audiences, one voice
Going into the workshops, I assumed both groups would want roughly the same thing — a cleaner, more intuitive platform. I was wrong.
I led workshops with student and instructor committees to understand how each group related to the platform. Students kept using words like fun, colorful, exciting. Instructors kept using words like invisible, reliable, out of the way. They weren't describing two preferences — they were describing two completely opposite relationships with the same tool. We discovered the two user groups, students and instructors, want completely different things.
This tension shaped everything. One group wants fun, the other wants to get their work done and the tool to not get in the way. We couldn't build two products. We had one platform, one codebase, and a slim budget. It really needed to be agnostic.
To test early iterations of the style guide, I ran workshops with the wider design team — applying the new writing principles directly to real Blackboard Learn screens. The exercise "One message, many possible tones" asked designers to rewrite the same legacy modal copy in different tonal registers, then compare. The workshops did two things: stress-tested the guide, and built early buy-in by making the principles tangible. Designers weren't just reading guidelines — they were rewriting live copy in real time and seeing the difference firsthand.
Creating artifacts
I translated the workshop findings and survey data into journey maps and user personas, giving everyone a shared reference point. Adam McLean became a shorthand the team actually used when debating copy decisions: Would Adam understand this? Would this slow Adam down? Grounding the style guide in real user language — the exact words students and instructors used in workshops — meant the principles felt earned, not imposed.
Scaling the style guide
Version one was intentionally lean. It was a proof of concept. I needed to prove that even the smallest amount of guidance would make a difference. A focused reference covering voice, tone, grammar, and punctuation across three product principles: Efficient, Helpful, and Accessible.
Built to be scanned, not studied. Any writer or designer could open it and find a clear answer fast.
What started as a lean voice chart grew into a complete style guide — covering UX writing principles, voice and tone, plain language standards, error messages, and localization guidance for 20+ languages. One document. Every team. One voice.
Key takeaways. Buy-in is the deliverable.
The biggest lesson wasn't about writing. It was about systems thinking. A voice and tone guide only works if people trust it, and taking the team along in the creative process was a great way to do this. Running workshops with product and engineering early wasn't a nice-to-have. It was the reason the system got adopted at all. Buy-in isn't a final step; it's built into every step.
The most unexpected insight came from user research. Discovering that students and instructors wanted completely different things from the same platform reframed the entire problem. The voice needed to resonate for both user groups — efficient enough not to get in the way of real work, while still being human.
If I were to do it again, I'd document the cultural change alongside the content deliverables. The style guide exists because of these shifts and the buy-in from the greater team.