Challenge    I was responsible for creating an error/outage alert system for multiple systems we are  supporting. At first, I had way more questions than answers, so I decided to use the help of my  future clients and users in the design process. I created a questionnaire and interviewed all  stakeholders to determine what exactly they were looking for.      Selection     I decided to use Visualization as my design tool. I created mock up messages for each of the  errors and shared them with the project team to get their corrections and other feedback. Later  in the process, I also used Learning Launch to adjust error thresholds and severity on as needed  basis. I also used storytelling to find the best notification channel(s) (email, chat, text),  frequency and other parameters.      Application     At the end of the interviews I had a list of over 80 alerts I needed to create. I chose 10 as a pilot,  coded and implemented them. If alerts are informational, only support team gets them. Severe  alerts are sent to the clients. After refining and adjusting the pilot alerts I proceeded to  implement the rest of them and applied the learnings from the pilot to them right away.

Insight     What I learned in the process, is that engineer’s opinion should not be the final say in the  design and implementation. It is important to listen to and hear the clients/users of the system  and incorporate their valuable feedback into the design. By establishing exactly what users  needed, I was able to create alert system that only alerts the clients when error rates are above  established thresholds.  At the same time, the informational messages that support team  receives tell us that alert engine is running.    Approach    I am so glad I got a lot of user input during the design phase. I had no way of knowing that some  messages are severe and need client notification after only a few in the last hour, while others  do not need to send an alarm unless there are over 500 of them in a day.  The other eye opener  for me was that some alarms need to run every 15 minutes or every hour, while others can run  daily or even once a week.

In addition to alarms, I also created multiple transaction reports that users can access when  they need an in-depth look at what is going on.


Challenge I was responsible for creating an error / outage alert system for multiple systems we are supporting . At first , I had way more questions than answers , so I decided to use the help of my future clients and users in the design process . I created a questionnaire and interviewed all stakeholders to determine what exactly they were looking for . Selection I decided to use Visualization as my design tool . I created mock up messages for each of the errors and shared them with the project team to get their corrections and other feedback . Later in the process , I also used Learning Launch to adjust error thresholds and severity on as needed basis . I also used storytelling to find the best notification channel(s ) ( email , chat , text ) , frequency and other parameters . Application At the end of the interviews I had a list of over 80 alerts I needed to create . I chose 10 as a pilot , coded and implemented them . If alerts are informational , only support team gets them . Severe alerts are sent to the clients . After refining and adjusting the pilot alerts I proceeded to implement the rest of them and applied the learnings from the pilot to them right away . Insight What I learned in the process , is that engineer ’s opinion should not be the final say in the design and implementation . It is important to listen to and hear the clients / users of the system and incorporate their valuable feedback into the design . By establishing exactly what users needed , I was able to create alert system that only alerts the clients when error rates are above established thresholds . At the same time , the informational messages that support team receives tell us that alert engine is running . Approach I am so glad I got a lot of user input during the design phase . I had no way of knowing that some messages are severe and need client notification after only a few in the last hour , while others do not need to send an alarm unless there are over 500 of them in a day . The other eye opener for me was that some alarms need to run every 15 minutes or every hour , while others can run daily or even once a week . In addition to alarms , I also created multiple transaction reports that users can access when they need an in - depth look at what is going on .