Research and Discovery

The research and discovery work focused on understanding how teams manage on-call coverage and escalation behavior, which information must be visible during configuration, and where ambiguity could create risk during incident response.

Key discovery considerations included:

• How responders are grouped and assigned to operational coverage.
• What information users need to identify a responder quickly, including name, email, phone, and group.
• How schedules are structured across days, weeks, time blocks, and templates.
• How escalation chains should communicate delay, type, responder or schedule, phone, email, and call-out order.
• How users review call/SMS or issue history after an event.
• Which actions should be available from list views versus detail or editing views.
• How to balance a dense administrative data set with quick comprehension and safe editing.
• What developers needed from a reusable style reference to implement screens consistently.

The research direction was to treat the experience as an operational configuration system rather than a simple contact list. Users needed a clear relationship between responders, schedules, escalations, and notification outcomes.

Experience strategy and customer journey

The strategy was to create a task-oriented management system organized around the four most important operational activities: responders, schedules, escalations, and logs. The home screen acts as an orientation point, while each area provides focused tools for review and management.

The strategy was guided by five principles:

1. Operational clarity:
   Make the purpose of each management area immediately understandable.
2. Configuration confidence:
   Show enough context for users to understand what they are editing and how it affects notification behavior.
3. Structured management:
   Use consistent tables, filters, forms, and editing patterns across different data types.
4. Reliable escalation:
   Make timing, sequence, channel, and call-out order visible in escalation configuration.
5. Reusable implementation:
   Provide a style guide and repeatable UI patterns so the product could be built consistently and extended over time.
6. Business value:
   Deliver an internal experience that supports the operational need while reducing dependence on expensive third-party licensing.

This strategy created a direct relationship between the product structure and the operational workflow. Users can enter through a clear management area, review the relevant data, make a controlled change, and return to the broader system without unnecessary navigation.

Information architecture and content structure

A significant part of the UX work was organizing the management system around the relationships between people, coverage, escalation behavior, and notification history.

The experience includes:

• Responders: A searchable or filterable list of responder email addresses, first names, last names, phone numbers, and groups, with controls for managing records.
• Schedules: A schedule-management area for reviewing and creating coverage schedules, including group selection, schedule names, and editing actions.
• Escalations: A configuration view that presents delay, escalation type, schedule or responder, phone, email, and call-out order in a clear sequence.
• Call/SMS or issue logs: A record of notification or incident activity, with information such as group, ticket or incident identifiers, modification details, responder information, and accepted channel.
• Home dashboard: A simple orientation screen that directs users to Responders, Schedules, Escalations, and Call/SMS Logs.
• Shared style system: A developer-facing style guide screen that establishes common patterns for layout, navigation, colors, controls, forms, tables, and statuses.

The information architecture was designed to reduce cognitive load by separating configuration tasks while keeping the relationships between them understandable. Responders feed schedules, schedules and responders support escalations, and logs provide a way to review notification activity after configuration is in use.

UX/UI design and visual system

I designed the complete interface experience through mockups and prototypes, then carried the design into the initial development of the application. The work included the dashboard, navigation, cards, tables, filters, forms, buttons, icons, status treatments, and action placement.

The uploaded screens make the design approach visible through several reusable patterns. The design work included:

• Creating a dashboard with four clear entry points for Responders, Schedules, Escalations, and Call/SMS Logs.
• Designing responder tables that support scanning of names, contact information, and group assignments.
• Designing the schedule-management experience with group selection, schedule naming, weekly time-grid presentation, and editing controls.
• Creating an escalation configuration table that makes delay, type, schedule or responder, contact details, and call-out order visible together.
• Designing issue-log tables for reviewing notification-related activity and supporting follow-up.
• Establishing consistent layouts for list views, detail views, filters, dropdowns, action icons, and edit/delete controls.
• Creating a visual hierarchy that distinguishes primary actions, configuration fields, informational content, and operational records.
• Designing the style guide screen as a practical handoff tool for developers, not only as a visual reference.
• Aligning the experience with Cox branding while maintaining a focused operational identity.
• Considering accessibility, contrast, readability, responsive behavior, and reusable UI patterns.

The design intent was to make a complex operational system feel organized and dependable. The interface uses familiar patterns so users can focus on configuring accurate notification behavior rather than learning a different interaction model for every section.

Development and design-to-build collaboration

The development phase included initial development work in addition to the mockups and prototypes. I used the design work to establish the first implementation patterns and created the style guide screen specifically to help developers lay out additional screens consistently.

The design-to-build process included:

• Translating mockups and prototype flows into initial application screens.
• Communicating page structures, navigation behavior, data relationships, and interaction expectations.
• Providing a style guide reference for colors, typography, spacing, controls, tables, forms, cards, and recurring layout patterns.
• Supporting the implementation of responder management, schedule configuration, escalation configuration, and issue-log views.
• Reviewing working screens to identify gaps between the intended experience and the implementation.
• Refining layouts, labels, field visibility, action placement, and status treatments based on build realities.
• Balancing the need for a dependable operational system with maintainability and future configuration needs.

The style guide reduced ambiguity during development by giving the team a shared visual and interaction language. It helped turn individual design decisions into reusable patterns that could be applied across the solution.