Managing Gift Card Outages at InComm
I recognize the work I did at InComm isn't the most attractive. The design of the software was in place when I was hired, and I was never able to get the engineering bandwidth allotted for a redesign. Over time, I was able to change quite a bit of the application, but honestly it never looked the way I wanted it to. Regardless, I did achieve some good while I was there.
Occasionally the systems InComm used to generate gift cards would have outages. These outages were not something InComm employees could resolve and an outage would impede InComm customers from purchasing gift cards, however InComm’s system had no way to handle outages, so customer orders would be negatively impacted without the customer understanding why.
We were approached by the production support team who managed this process. They requested a simple interface to manage and track outages. This interface would allow them to input outages as they became aware of them.
The product owner and I conducted early interviews with the team to understand what they needed. We learned there were four types of outages that could occur, but initially they only wanted to cover what they believed was the single most common type.
Outages could occur in these ways:
- Processor (the source of the gift cards) - Most Common
- Single Product
- System wide
After spending time with the team and learning what they wanted to do the product owner and I drafted some user stories. Once the user stories were created I got to work designing the most common use case.
This early design went unused for a time due to business priorities. Late in April we revisited it, and discussed the early version with the team who had requested it. They had done some additional digging into their logs and discovered their biggest needs were to cover outages concerning brands or individual products.
This was an increase in scope over the original version, as we had to cover two types of outages that had some differences in what was required on both the front and back ends. We decided this was a good opportunity to run a user test. I created a version of the mockup robust enough to use as a user test and was able to run the prototype through a testing session with each of the three members of the production support team.
View The User Test
While the results of the test were very positive, some issues were revealed. Test participants requested wording that was more friendly on some of the dialogue boxes (this wording was to warn the user that if they changed availability customers would be notified and impacted).
Changes were made to the prototype and handed off to the development team. Due to development constraints, only the two outage types from the user test were developed, and they were still missing some of the requested features (such as notifying customers via email if there was an outage).
Later in 2019 the React components used to create this feature were updated to meet the Web Content Accessibility Guidelines. Unfortunately, I don’t have images of that version of this feature.
More about Radmin