Digital Notifications Platform
What is it?
The Digital Notifications Platform (DNP) is an internal tool, used by a major healthcare provider, to build and launch Emails, Push, & SMS messages to its 12 million+ patients.
The Problem
Managed to save 15 days & $200,000 in development time, to-date
The result of this work led to $200,000 saved annually, saving around two weeks of development time and resulted in 15% more errors being caught by the writing and development team.
No interface to manage or write notifications
Before the DNP’s interface was created, developers managed their notifications via a codebase. This resulted in spelling and grammatical mistakes. Additionally, information would occasionally go to the wrong recipient.
Impact to bottom line
This also impacted the company’s bottom line. Especially when they had to recall a message, or send out an additional message with the right information, as additional development time was needed.
Solution: The DNP
A shared workspace for developers and writers
The Digital Notifications Platform. A shared workspace for content writers to write notifications and developers to format, schedule the launch of notifications.
Results
Process
Interviews and Workshops
I led a series of workshops and interviews to understand/map their workflow of both the writers and the engineers, as well as understand their pain-points.
Pain-points
“We need to make sure people get it. We spend a lot of time, getting people started. This becomes frustrating when we are under a tight deadline.”
“Sometimes notifications would sit for months, and we would have no insight on what the notifications status.”
Design/Prototype:
I was pulled into this project, from another team. As such, my goal was to clean-up what was there, not reinvent the wheel. Reinvention came with user feedback.
Events List v1
Event Creation v1
One thing I tried to emphasize was comprehension. I wanted users to understand where to begin, and what to do next without being overwhelmed.
Added additional context to form fields
I provided context to critical form fields, to make it as clear as possible what a developer should be putting in the form field, as well as why it was important to put that information in that form field.
Guerilla Testing and Iteration
Due to time constraints, I informally tested a prototype with engineers, writers, members of my UX team, and family and friends.
Feedback, Events Screen
Changes
Addition: Template Creation
Additionally, I focussed on separating the workstreams. Previously, they were shared by both developers and the writers.
This separation of roles starts with the creation of templates. Each role has its work queue, and tasks it needs to complete. Template creation is limited to specific members of the team.
Separation of Workstreams
Both teams shared a single workflow. I separated these into two distinct workflows for writers and engineers, so they could focus on their tasks.
Launch & Results
The development and the writing team recognized the value of these changes, however could not implement them for MVP. Together we prioritized them for phase two implementation. Phase two launched this past January.
Results of MVP
What I learned
The importance of building and keeping relationships:
I communicated often with both the engineering team as well as my product owner, at every step. This included frequent check-ins with all members of the team. They in turn kept me in the loop during the development process.
The Importance of showing my work:
Throughout the process, I pulled in standards, from Norman Nielsen and around the web, to show best practices, and where ideas were coming from.
Get in touch
Thanks for stopping by! You rock! I’m excited to work with you!!!