Blackboard Connect
Mass notification platform for K–12 and higher education
Era
2012–2015
Role
Lead UX/UI Designer & Front-End Engineer
Platform
Enterprise SaaS · Educational Technology
Communication infrastructure for the people who run schools.
Blackboard Connect was the notification platform for a significant portion of North American educational institutions, used by school districts and universities to reach students, families, and staff simultaneously across voice, email, and text.
The platform handled two fundamentally different modes of operation through the same administrative interface: routine communications such as schedule changes, event reminders, and attendance alerts, and emergency scenarios including school closures, lockdowns, safety alerts, and weather events. These modes shared infrastructure. Their stakes were not equivalent.
At scale, the system delivered millions of messages per year across thousands of institutions. The administrators sending those messages ranged from district communications directors managing daily high-volume operations to school principals who might use the system twice a week.
- Platform Type
- Enterprise SaaS · Mass Notification
- Delivery Channels
- Voice · SMS · Email · Push · TTY
- User Scale
- Thousands of institutions · Millions of households
- Compliance
- Section 508 · ADA · WCAG 2.0 AA
- UX Ownership
- Strategy · Interface design · Front-end implementation
- Accessibility Testing
- NVDA · JAWS · VoiceOver · Keyboard
- Design Tooling
- Figma · Sketch · Front-End Implementation
- Era
- 2012–2015
Two user populations. One interface. Contradictory needs.
District-level communications directors needed depth: contact management across hundreds of buildings, message segmentation by grade, language, household type and delivery preference, reporting granularity, and operational efficiency for daily high-volume use.
The interface they needed was a professional tool. Powerful, configurable, and designed on the assumption that they knew exactly what they were doing.
Principals, athletic coordinators, and administrative assistants needed to send a message without reading documentation. They encountered the system infrequently, under varying conditions, occasionally under pressure.
The interface they needed was a guided workflow. Minimal required decisions, clear confirmation, and enough feedback to be confident the message went out.
“An administrator initiating a lockdown notification needs to complete the workflow in under ninety seconds. Every interaction in that path was reviewed against that constraint.”
The core workflow is deceptively simple.
Compose. Target. Schedule. Deliver. Confirm. Five steps that in practice involved targeting a message to twelve thousand households with different preferred contact methods, multiple languages, opt-out histories, and accessibility requirements.
The interface needed to expose this complexity without surfacing it until the user needed it. Progressive disclosure at platform scale: the default path was streamlined and assumed common-case parameters. Advanced targeting, delivery customization, and multi-language management were accessible without being intrusive.
Emergency notification received distinct treatment. The workflow was shortened, confirmation was made explicit, and delivery feedback was immediate and prominent. Speed and clarity were the only design requirements for this path; every other consideration was secondary.
Key decisions that shaped the system.
Context-Separated Surfaces
Rather than one unified dashboard, the interface organized around operational contexts: routine communication, emergency notification, contact management, and reporting each had optimized entry points that shared infrastructure but not surface area.
Progressive Disclosure at Scale
Advanced targeting, multi-language message management, and delivery customization were available to power users but removed from the default workflow path. The standard experience was designed for occasional users; the full system was reachable when needed.
Design and Engineering in Parallel
Front-end implementation ran alongside design rather than after it. This allowed design constraints to inform component architecture and vice versa, and ensured that accessibility and responsive behavior were built into structure from the start.
Emergency Path Hardening
The emergency notification workflow was treated as a separate design problem from routine communication. Time pressure, cognitive load under stress, and the irreversibility of a district-wide alert shaped every decision in this specific path.
Notification workflows at two levels of operational complexity.
Mode
Routine
Mode
Emergency
Workflow
Compose
Target
Schedule
Deliver
Confirm
Delivery channels
Target audience
12,847 households
Alert Workflow
Message creation and delivery across five structured stages
A single workflow surface handled both routine district communications and emergency notifications. Emergency mode shortened the path, made confirmation explicit, and prioritized speed above all other design concerns.
Emergency notification path was treated as a separate design problem. Every interaction reviewed against a 90-second completion constraint.
Targeting hierarchy
Washington Unified District
1,899 households
Adams Elementary
612
Jefferson Middle
489
Lincoln High
798
Preferred channel distribution
Voice
68%
43%
SMS
31%
TTY
4%
Contact records carry up to six delivery preferences across multiple time zones
Recipient Structure
Hierarchical targeting with multi-dimensional contact preferences
A single contact record could carry six delivery preferences across four time zones, associated with multiple students at multiple schools within one district. Targeting looks simple from the outside; the data model underneath is n-dimensional.
Designing with the actual data model in mind (not a simplified mental model) changed how targeting controls were structured.
Section 508 compliance was a structural requirement, not a retrofit.
Formal ADA and Section 508 training at Blackboard produced a structured accessibility practice. Every feature was evaluated against WCAG criteria during design. The admin console used semantic HTML throughout, with full keyboard navigation across complex data tables, multi-step message creation forms, and reporting interfaces.
An organization responsible for communicating with millions of students and families (many with disabilities) cannot treat accessible administration as optional. The obligation ran through both sides of the platform.
The messages delivered by the platform themselves needed accessible design. Voice scripts were reviewed for phonetic clarity. Email templates used semantic structure, meaningful alt text, and appropriate heading hierarchy. TTY delivery channel support addressed hearing-impaired household needs at the infrastructure level, not as an afterthought.
Accessibility was not layered onto an existing interface. It was part of how the interface was constructed, which is the only approach that actually holds across a codebase evolving over time.
Understanding the data model changed the design.
A communication platform is fundamentally a data system. The UX work was as much about information architecture (how contact records, message history, delivery reports, institutional settings, and compliance records related to each other) as it was about screen-level design decisions.
A single contact in the system might carry six delivery preferences across four time zones, associated with three students at two schools within one district. The targeting interface looks fundamentally different when you hold that reality in mind rather than designing for a simplified mental model.
What appears to be a simple "send to parents" selection is an n-dimensional query against a complex relational dataset. Designing with that understanding, exposing the right handles at the right moments, was the difference between a system that worked for power users and one that obscured complexity until it surfaced as errors.
What changed.
These reflect the operational reality of the work rather than fabricated metrics. Blackboard Connect served institutions whose communication needs were genuine and consequential.
Emergency Communication Reliability
The hardened emergency workflow gave administrators a path they could execute under real pressure. Districts used the system for actual emergency events, which is the only performance metric that matters for this use case.
Reduced Administrative Overhead
Workflow improvements to routine communication reduced support ticket volume for message creation and delivery questions. The interface answered more of its own questions, which is what good operational UX does.
Sustained Accessibility Compliance
Section 508 compliance was maintained across an evolving codebase through structured design and implementation practices built in from the start rather than through retroactive auditing. This approach held through multiple platform iterations.
A Replicable Delivery Model
Running design and front-end engineering in parallel established a delivery model that subsequent projects replicated, because it produced fewer handoff failures and more technically grounded design decisions.
Enterprise communication platforms are trust infrastructure.
An institution's relationship with its community runs through this interface. A parent receiving an emergency alert about their child's school is not evaluating a product. They are depending on it to be clear, fast, and correct.
The UX work on Blackboard Connect was never primarily about aesthetics. It was about the reliability and dignity of getting an important message right: to the right people, through the right channel, with enough clarity that no one has to wonder what it means.