As others are pointing out, steps 2 and 3 are flawed in this design. In an effort to break out the decision steps into a wizard, the author chooses to treat the

As others are pointing out, steps 2 and 3 are flawed in this design. In an effort to break out the decision steps into a wizard, the author chooses to treat the distinction of 'test alert' vs 'real alert' as a simple configuration option whose decision was already chosen, so it doesn't need to be shown on step 2. This is the sort of designer-bias mistake that, ironically, leads to terrible interfaces like the original that precipitated this whole sequence. Test alerts and real alerts are entirely different in every imaginable way: one's normal procedure, the other is hopefully a rare event; one causes people to scoff at their phones while the other creates urgency and concern. Playing up the distinction on 'step 1' is good, but eliminating all visual indications of the choice on further steps is bad in ways a confirmation screen can't rectify. UI is only a portion of the UX and the overall operator process, but there should be as few commonalities between the process (and UX) surrounding test alerts and the process surrounding real alerts as the trained operators of the system can bear. It's even odd to have them originate in the same entry point, but as the author has done, I'll also keep my criticism focused on a UI that can do both. Concretely, I propose a simple way of rectifying the loss of context on 'step 2' is to get rid of the spurious 1-2-3 breadcrumb that doesn't communicate anything that isn't abundantly clear otherwise, and use the space for several conditional indicators that trigger in case a real alert was selected. Warning icons, clear wording, exclamation marks, attention-pulling colors or patterns should be used to distinguish the context of real alerts from text alerts in so many visual ways that accidentally confusing them, even through a momentary loss of situational awareness, is practically impossible.