This product feature solves the problem of erroneous recognitions in our employee engagement platform being reversed through a completely manual process – from communication via the submitter to a client admin, from the client admin to a Maritz admin, then to a developer, who in turn had to reverse each recognition by digging into code. Believe it or not, there were a great deal of these reversals requested by clients each week, but even with batching the requests, it was taking up a lot of unnecessary administrative and coding time.

The problem was rather obvious, but what about the solution? In order to gain a greater understanding, our team dug in to the process, figuring out all of the touch points. Here are some initial whiteboard drawings and pencil-and-paper sketches.

After quite a bit of sketching and discussion with our client operations people and amongst our team, we ended up with a journey map of the ideal state.

However, in the grooming process with development, it was determined that the effort to achieve the ideal state, combined with the juggling of other priorities, would not allow us to get to that state in MVP. Here is the adjusted journey map.

With the simplified journey in place, we discussed the concept of a transaction management page, which would eventually contain a history of all transactions in the system, recognitions just being the start. However, this would also be the vehicle for admins to “reverse” recognitions. The transactions would live in a table (existing pattern in our product), with the ability to filter them (leveraging existing filter patterns). One speedbump we hit was that loading so many transactions was creating long load times with our usual infinite scroll pattern, so we had to figure out a way to handle pagination (loading only 20 records at a time) while also giving the user to be able to “select all” (or at least multiple) records to perform a bulk action on them – something that ended up not making it to MVP. Here is an early iteration on a wireframe.

Initially, we had the reversals occurring within a modal window, but the amount of content within the modal became too heavy, so we ended up moving it out of a modal and onto the page, utilizing yet another existing pattern. Here's another iteration on the wireframes during the middle of the process, and the final wireframes that we settled on.

Once the wires were in a good place, the visual design was fairly easy, as it was mostly a matter of leveraging existing patterns and styles, with the notable exception of the pagination pattern.

The delivery of MVP into production allowed an administrator to reverse recognitions without the involvement of a developer, although the system-generated notifications to the admin and from the admin back to the client will be addressed through a future improvement.