Designing communication software for organizations that need to reach people clearly, quickly, and reliably.
Blackboard Connect was a large-scale enterprise communication and emergency-notification platform used by educational institutions, government organizations, and other organizations managing high-impact communications. As the primary UX/UI designer, I worked across product strategy, workflows, interaction design, visual design, prototyping, scalable patterns, and front-end implementation to help make complex communication and administrative tasks easier to understand and use.
Role
Lead UX/UI Designer & Front-End Engineer
Era
2012–2015
Contribution
Mode
Routine
Mode
Emergency
Workflow
Compose
Target
Schedule
Deliver
Confirm
Delivery channels
Target audience
12,847 households
Interface Evidence
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.
Sending a message can sound simple. But an enterprise communication platform has to support different audiences, different message types, administrative roles, scheduling, targeting, delivery channels, status, errors, confirmation, and repeatable workflows — some of them under real pressure.
The platform handled two fundamentally different modes of operation through the same administrative interface: routine communications such as schedule changes and event reminders, and emergency scenarios including school closures, lockdowns, and weather events. These modes shared infrastructure. Their stakes were not equivalent.
How do we help people make the right communication decisions under complex conditions?
Many administrators performed some workflows only occasionally. The product could not depend on users remembering complicated system behavior. The experience needed to make next steps obvious, terminology understandable, targeting clear, status visible, and recovery possible when something went wrong.
District Communications Directors
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.
School Principals & Site Administrators
A guided workflow they could complete without reading documentation, encountered infrequently and sometimes under pressure.
Athletic Coordinators & Administrative Assistants
Minimal required decisions, clear confirmation, and enough feedback to be confident the message actually went out.
Enterprise users should not need to memorize the software to use it well.
The core workflow was deceptively simple: compose, target, schedule, deliver, confirm. In practice, that could mean 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.
Compose
Write the message once, for delivery across every enabled channel.
Target
Select the households, buildings, or district-wide audience the message needs to reach.
Schedule
Send immediately or set delivery for a specific time.
Deliver
The platform routes the message across voice, SMS, email, and other enabled channels.
Confirm
The administrator sees that the message went out as intended.
Operational communication UX is not the same discipline as ordinary consumer UX. Ambiguity costs time. Mistakes can affect many people at once. Unclear confirmation creates anxiety. Status, reversibility, error prevention, and confidence are not nice-to-haves — they are the product.
“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.”
When the message matters, the interface has to get out of the way.
Rather than one unified dashboard, the interface organized around operational contexts. Each area had an optimized entry point that shared infrastructure with the others, but not surface area:
Operational Contexts
A scalable enterprise product needs navigation and hierarchy that can grow without making users feel like features are being piled onto the interface. The goal was a mental model stable enough to support both occasional and experienced users.
I served as the primary UX/UI designer across the platform. That responsibility extended from strategy through interface design and front-end implementation, working in close collaboration with Product and Engineering rather than in isolation.
Primary design ownership. Cross-functional delivery.
Front-end implementation ran alongside design rather than after it. Understanding HTML, CSS, and front-end implementation constraints directly let me collaborate with Engineering at a more practical level, which helped:
What Working Close to the Front End Enabled
Implementation was part of the design conversation.
Working closer to front-end implementation created a tighter loop between intent and execution. It let design decisions be evaluated against actual behavior rather than only static screens.
Problem
Understand the operational task and who needs to complete it.
Flow
Map the sequence of decisions the user actually needs to make.
Wireframe
Structure the workflow before visual design begins.
Prototype
Validate the sequence and interaction model.
Visual Design
Apply hierarchy, contrast, and the platform’s interface standards.
Front-End
Build the interface directly, rather than handing off a static spec.
Review
Evaluate the built experience against the original intent.
Iteration
Refine based on what the working interface revealed.
Rather than a single formal design system, the platform relied on shared patterns and interface standards developed and reused across the product:
Shared Patterns & Interface Standards
The goal was to reduce unnecessary variation so users could transfer what they learned from one workflow to another.
Formal ADA and Section 508 training produced a structured accessibility practice. Every feature was evaluated against WCAG criteria during design, not after.
The obligation ran through both sides of the platform: the admin console administrators used, and the messages the platform delivered to families.
Where Accessibility Showed Up
Accessibility was structural, not a retrofit.
Power
vs.
Clarity
District communications directors needed real configurability. Principals and administrative assistants needed to complete a task without reading documentation.
Resolution
Provide enough control for enterprise communication without exposing every option at once.
Speed
vs.
Confirmation
An emergency notification needed to go out fast. It also needed to be something the administrator could trust actually happened.
Resolution
Allow users to move efficiently while preserving clear review and confirmation before consequential actions.
Consistency
vs.
Workflow-Specific Needs
Routine communication, emergency notification, contact management, and reporting shared infrastructure, but not every workflow could behave identically.
Resolution
Reuse interaction patterns while allowing specialized communication workflows to remain appropriately different.
Feature Depth
vs.
Learnability
A principal using the system twice a week could not be expected to remember complex system behavior between visits.
Resolution
Create stable navigation and patterns so occasional users can return to the product without relearning the system.
Design Intent
vs.
Implementation Reality
Static screens do not surface every technical constraint. Working close to the front end did.
Resolution
Collaborate closely with Engineering and refine solutions while preserving the user outcome.
Problem
A communication platform is fundamentally a data system. What looks like a simple “send to parents” selection is an n-dimensional query against a complex relational dataset. A single contact could carry six delivery preferences across four time zones, associated with multiple students at multiple schools within one district.
Decision
Design the targeting controls around the actual data model rather than a simplified mental model of what a household or a class list looks like.
Interface Consequence
Targeting exposed the real hierarchy — district, school, household — and the channel preferences underneath it, instead of obscuring that complexity until it surfaced later as delivery errors.
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.
I was the primary UX/UI designer, but the product was created collaboratively with Product, Engineering, and the broader Blackboard organization.
The hardened emergency workflow gave administrators a path they could execute under real pressure. Districts used the system for actual emergency events.
Workflow improvements to routine communication reduced support ticket volume for message creation and delivery questions.
Section 508 compliance was maintained across an evolving codebase through structured design and implementation practices built in from the start.
Running design and front-end engineering in parallel produced fewer handoff failures and more technically grounded design decisions.
Good communication software doesn’t make the user think about the software. It helps them think about the people they need to reach.
The project reinforced that usability in enterprise software is often about confidence. Users need to understand what they are doing, who it will affect, what happens next, and whether the system did what they expected.
Federal healthcare reporting and regulatory submission systems for CMS.gov, built for users whose submission deadlines carry regulatory consequences.
Another platform where clear, accessible interaction design carried real consequences for the people relying on it, this one federal regulatory reporting rather than emergency notification.