Responsive Point of Sale Web Terminal2018-09-03T19:32:10+00:00

Box Office Ticket Platform

The UniversityTickets web ticket platform is used by Box Office managers at 200+ schools internationally to create, market, sell, print, and report on their tickets to on-campus events.

View Prototype

OVERVIEW

For several years UniversityTickets has wanted to offer a way to sell tickets to customers at events from a mobile device.

I put forward a proposal to, instead of building the app completely natively, make the web app responsive and build a native app wrapper around the web app to enable the web app to connect with Bluetooth printers, credit card swipes, and laser-based ticket scanners—though it may be worth exploring building it as a Progressive Web App (PWA) instead.

TASKS

Collect requirements
Information Architecture
Wireframing
Prototyping
Presenting
Feedback and iteration

OBJECTIVES / GOALS

– Maintain all existing functionality in the system

– Redesign it to be responsive: to automatically resize to any size screen and work across PC and mobile devices

– Improve flow for selling all inventory types

– Improve usability

– Integrate feature requests from clients, as well as features of competitors

– Create a more cohesive, holistic design

– More efficiently integrate features that had been tacked on over the years in non-optimal locations (including in-progress orders, suspended orders, and settings)

Before Redesign

PROCESS

Point-of-Sale

1. Sketched the steps through POS checkout.

2. Using a mobile-first methodology, I transferred all the existing functionality to mobile screen frames in OmniGraffle and restructured fields into the order in which an admin completes them.

3. After transferring existing functionality I integrated new feature requests and made changes to solve issues that had been raised through discussions with users.

4. Next, I expanded the mobile screens up to the desktop size.

5. Using Bootstrap, I built a prototype of the system.

6. I then presented the prototype over several days of cross-team meetings. Each screen in the process went through an in-depth critique. Each day I showed the updates to the prototype made with the previous meeting’s feedback, then the next screen went through an in-depth critique.

Prototype (made with Boostrap)

Admin Menu

The responsive Point-of-Sale update would require an update to the admin menu. This was, therefore, an opportune moment to also fine-tune the information architecture.

  1. Transferred all current sub-menu items to post-it notes
  2. Rearranged post-its on the wall until all items were grouped with the smallest number of groups and sub-groups that made sense to me in the mindset of a user, based on my deep understanding of the system and many conversations with users.
  3. Using OmniOutliner, documented the post-it groups in a digital outline of the new admin menu structure.
  4. Created a visual mockup in OmniGraffle of the outline for internal feedback.
  5. The initial plan was to build a new responsive Point of Sale system separate from the rest of the admin system. However, due to time constraints, it was decided to only make the admin menu itself responsive. This required some minor adjustments including the integration of the internal feedback.
  6. Several adjustments were made after a final review; including taking out the build item button, splitting “donations” out into its own first-level menu (as it was before), moving venues back into Settings, and restructuring the Settings menu.
  7. Finally, as a starting point for the developers, I created an HTML prototype using the Bootstrap CSS framework; which we had used the previous year to build the third version of the customer-facing side of the system.

* Management did not approve of conducting user research for this project.

Card Sorting

RESULTS

“This platform is much more intuitive and is very easy to use.” – User feedback

It was decided that instead of building a new responsive Point-of-Sale (POS) web app, that we would integrate as many of the improvements that we arrived at in the prototype into the existing web app.

It was going to take too long to build the new web app from scratch, and management wanted to make improvements in the near future as more clients were beginning to use the existing web app, and the existing issues were thus compounding.

Since the responsive web app was put on hold, we have updated the current web POS system to be much more usable. A new responsive admin menu has been built in preparation for making a responsive POS web app. The current web app, while not responsive, closely resembles the prototype I had built; and continues to get closer to it every week. The features and functionality not built from the prototype can now be added at a future date in a logical place, instead of being tacked on in haphazard places by the development team, as the update has been designed with those future goals in mind.

Furthermore, I believe that we can build upon the work we have done with the existing POS web app, and update it to be responsive. This would save time as opposed to building a new web app and would achieve the original project’s goal.

NEXT STEPS

  1. Add button to create common item types. This was in the wireframes, but was removed to reduce the amount of work required to create the new admin menu.
  2. Merge packages and rollers into one page in order to reduce complexity in building rollovers and simplify the admin menu further.
  3. Card-sorting should be done with a larger number of users to make a more informed refinement of the information architecture in the future.

Version 31 (Working Web App)

More Case Studies

LemonAid