Messaging Client

This messaging client consisted of three parts – which required design and development. It consists of a restricted kiosk application for use by inmates, a responsive webpage to support a broad array of devices, and dedicated mobile applications. The intended goal of this client was to provide inmates with the ability to communicate with their loved ones in near-real time. The client borrows many words from the world of postal mail. Stamps indicate available credits. These credits are sold by each facility and purchased by the inmates loved ones. Currently, a message may only be initiated by a loved one. They may send text and images to the inmate. If they so choose, they may provide “return postage” for the inmate to draft a text-only reply. The client’s limited functionality is related to the security measures required to ensure no illegal communications occur.

Prior to the implementation of this messaging application, a variant was already in existence. Our organization acquired the business and set about stripping the application down to the back-end code and building it back up to suit our needs. My design process began by studying and understanding the current application. Additionally, I was able to learn from the previous owners what things could have been done differently and what improvement opportunities existed. From this, I materialized a set of users flows for both user personas.

From there, I met with our business analysts and product owners to understand their project goals and to discuss how we might go about implementing them. Once I had a strong understanding of our organization’s goals, I set about revising user flow diagrams and initial wireframes, keeping in mind our user personas, the goals identified by the organization, and the improvement opportunities identified by the previous owners.

Once the initial wireframes had been completed, I again met with our product owner, business analysts, and back-end architects to review initial screens and ensure they not only met the business goals, but were also technically feasible based on the current back-end framework. Several improvement opportunities were identified around the checkout process and the use of stamps. These improvement opportunities were then wrapped up into an initial set of mockups – stylized wireframes adhering to brand style guides and finalizing content placement and styling. Again, all teams involved in the process met to discuss the flow, the incorporation of all business goals, and the back-end feasibility.

After finalizing the mockups, I progressed to generating front-end code. To begin, I mocked up all back-end services and created simulated API calls so that I could test functionality prior to back-end services being available. I focused first on the kiosk application which inmates use to interact with the product. This application is created as one of many modules which are displayed on a kiosk terminal within the prison facility. Inmates have access to these kiosks at certain hours throughout the day and may use the provided services. Once completed, I moved to development of the responsive web application. This application serves the friends and family members of the incarcerated individuals. This application required much more development time as users have additional functionality including purchasing stamps and their actual composition capabilities. Back-end developers were then left to remove mocked API calls and replace with correct services. Throughout my entire design and development process I not only met with our product owner and business analysts but I also reviewed my progress at a weekly meeting with those individuals within our organization involved in UX and UI. Any feedback was incorporated into the final designs, where applicable.