About The Project
For this project we leveraged our decade's worth of experience in the kiosk industry to develop this application to run on our client's kiosks. Our client chose to replace a legacy third-party SaaS program to both eliminate the recurring subscription fee and improve upon it for their needs.
During our discovery phase, we analyzed existing software and reviewed the client needs to fully define the scope of the work. The overall purpose of our software was to allow users to deposit funds in their own account or in the account of other defined users. As with all our software projects, what seems simple at first glance often has many considerations to work through, not least of which were different hardware considerations from our typical web and mobile projects.
Architecture & Administration
This particular project was a good example of a very successful fixed-bid project. Whether you end up going fixed-bid or not, we highly recommend taking time for project roadmapping. By briefly taking this additional step up front to review all the screens you will need for your workflow before writing one line of code will save you a lot of headaches. There are often divergent paths that a user may take and we can help you outline all of those from assigning funds to various accounts to working through the different payment types and how those would be handled, to the different ways of receiving a receipt.
During project roadmapping, we created wireframes to help the client visualize the user workflow and quickly iterate through changes saving time and money. Our UI designer provided a clean and intuitive interface that's a pleasure to use. We also implemented the latest Google Material Design guidelines for a modern looking interface. To put the final touches on the design, we analyzed their website to ensure the kiosk application would be consistent with their current brand identity. In addition, we wanted any search or information input to work as seamlessly as possible, while also protecting private information where necessary.
On the administration side, we defined with the client what needed to be available for their team to efficiently and accurately run their service. In particular, the client needed to be able to manage the configuration details of these kiosks and have these kiosks update remotely to any changes.
Software & Hardware
Project planning was key. During project roadmapping, we were able to fully outline the scope of the project. With over a decade of experience in the kiosk industry, we brought a considered eye to the feature list of the project, both shoring up gaps and eliminating user stories that did not need to be a part of the MVP. These choices saved the client time and money overall. It was also important for us to fully understand all the hardware they would use from the beginning. The combination of hardware and feature set allowed us to determine the optimal tech stack on the software side. In this case, we needed to integrate the credit card reader, bill acceptor, and thermal printer with our software for a seamless experience.
With all of these considerations in mind, we used Python Django for our backend. We are able to build fast and robust applications with this tech stack. What's more the Django framework has a no-frills admin which we customized and made accessible for our client to manage certain aspects of their data and configuration. While some applications might require a fully developed dashboard with fancy graphs and charts (like our Lead Sherpa dashboard), others, like this one, only require a bare bones interface.
Common Pitfalls We Avoided
Throughout this project we wanted to also be exhaustive when we thought about the user pathways that are atypical or unintended. For example, we needed to have screens and procedures for when a user walks away, and other similar scenarios. Confirming that a user has indeed left mid-process (versus looking for money in their wallet or any other number of distractions) need to be handled with proper timeouts, prompt screens, and eventually locking out the kiosk screen and starting over. Depending on whether or not the user has already transacted funds before they complete, the kiosk may autocomplete the process to ensure those funds at still are applied to the proper account.
Likewise we considered the possibility that due to power outages or connectivity problems a kiosk may not be able to get the most recent configuration. In this case the kiosk will disable itself until it can properly update.
Another scenario worth exploring is if the user wants to apply funds to someone else's account but there are multiple people with the same name. We had to think through what kind of information the user should be able to see to identify the correct person while also protecting the privacy of people in the database.
All of these atypical or less than perfect scenarios are just a few examples of the things to think through from the outset. Ultimately, defining the features and user stories along with the hardware that will be in place from the beginning will save you a ton of money and time!