Validating Alert Flow

Product

The Electronic Municipal Market Access (EMMA) is the Municipal Securities Rulemaking Board’s (MSRB) main web product which allows for analyzation of user-submitted information regarding municipal securities. It hosts a wide range of content including borrower and loan details, financial and event documents related to loans, and market analysis tools such as yield curves, market statistics, and new issue calendars.

The MSRB is the principal financial regulator over the municipal bond market and those working within it. Created by congressional mandate in 1975, its goal is to protect investors, issuers and the public interest by promoting a fair and efficient market.

Problem

The MSRB had begun a system modernization project two years prior with a slated beta in January 2025 and go-live in October 2025. This project involved a complete redesign of the organization's main web product EMMA including the process for creating an email alert for certain actions against an individual security or, newly added, a group of securities from one or more issuers (e.g. a city). These alerts are widely leveraged by a large percentage of users to keep track of various updates and regulator-required information.

A concern was raised that no validation had been carried out on the new flow, which began on an instance page of an issuer or security and then moved to an alert creation page. It would require the user to log in as part of that process if they weren’t already authenticated and a concern was raised that this might confuse older users who aren’t as familiar with technology. Additionally, there were many alert options that could be selected and stakeholders wanted to make sure users could easily find the option(s) they needed while also being able to see all possible options at one time.

What Happened

A question was brought up in a daily standup meeting about whether having to interrupt the alert process by logging in would be confusing to a user. I quickly volunteered to put together a quick prototype test to validate the full flow that could be run and have results within a week. The timing was important as developers would begin working related cards in the coming Agile sprint and project timing couldn’t afford to move them back in the sprint order.

I was able to write up a test plan and create a Figma prototype within the next two days. The test was run the following week with internal customer service staff members. The product department did not have access to external users at that point in time and customer service had been identified as the best stand-in who had the most end user knowledge around their questions, struggles, and use of the website.

A few things quickly stood out:

1. Having the alert creation flow interrupted with the need to log in was not an issue
2. Over 67% of the testers had trouble understanding how to start the process. The tested iteration of the Create Alert button was an alert bell icon button within the page’s header. It was not visible enough and did not have enough significance to the testers to draw their attention as the correct way to trigger the process.
3. Over 50% of the testers expressed being overwhelmed or lost at the number of alert options they had to look through to find their desired types, particularly with the continuing disclosure options.

Outcomes & Lessons Learned

Create Alert Button redesigned & implemented

The Create Alert button was reworked to include text clarifying the purpose and use of the button, it was also placed into the same button pattern as other buttons on the page. This further cemented in the user’s head that it was performing an action, not just visual information on the screen.

When retested, all testers were able to quickly and easily start the alert process.

Alert Options redesigned with pushback

The alert options were reworked into a few options, ranging from a high to low level of rework to the page. Higher level options included the use of frequently used quick select options or groupings and a keyword search that would surface the desired option to the top of the list. Other options also included regrouping the many options into less formal categories and into more user-friendly buckets. This might have required from additional information architecture work to perfect. A lower level option involved placing categories of options into accordions to lighten the visual load of the screen on the user.

Unfortunately, business decided that reworking the alert options was not a big enough issue to need rework at this time, even at a lower end. It was put on hold to be re-prioritized as a future enhancement.

Lessons Learned

Doesn't hurt to offer (to test)

A quick test uncovered two unknown issues, one of which would have seriously impacted the success of the addition of new alert options. With the alerts being such a widely used feature, this could have been disastrous for the launch of the updated product. Taking the relatively little time to verify the alert flow before production likely saved many users from having confusing or negative experiences, stakeholders being criticized over decision making, and future development hours to change the flow once again – potentially still not correctly identifying the original issue.