Bridge POS

My Role

UX Research
UI Design
Usability Testing
Development Oversight

Date

2023

Duration

4 weeks

Tools

Figma
Adobe Creative Suite
Hotjar
Asana

Project Overview

Bridge POS is a unique POS system, tailored for restaurants that doesn't require any hardware. A simple web app that you can run on desktops, tablets or phones. It is aimed to be simple and easy to use, with its advanced features reserved for those that need it without affecting the main functionality of the system. Additionally, it integrates with partnered delivery apps giving the restaurant owner a complete view of performance and finances.

The desktop version was already developed. For maximal responsiveness, a native mobile app was to be developed from scratch as well that could be used as a stand-alone product and planned to later be adapted for non-restaurant merchants as well (i.e. retail, service stores, etc.)

My Role & Responsibility

I was tasked with re-designing the native mobile and desktop web application, aiming to improve UX without creating any flows or changes that contradict with the currently built database and infra.

Research & Constraints

The research consisted of mostly observing the application being used, noticing any points of confusion or difficulty. The user research was segmented to those restaurants/staff that were already onboarded and using the application for some time as well as those that were new to its use -- to uncover if there were any critical features/flows and identify which ones took time to grasp and which ones were pain points despite continued use.

There was a major constraint. Since the tablet version was already fully developed, that meant that the database and APIs were already built. In an effort to save development time, I was restricted to fixing the UX without needing to do any major changes to the database.

Approach

I am a huge believer of the mobile-first approach, but for a POS system, a desktop-first approach would make more sense -- especially since this is where most of the use will be and because POS systems can get incredibly complex real fast. Nonetheless, since the mobile app was earlier in its development cycle, that meant I was virtually designing it from scratch and giving the desktop version a UI revamp, I went with an unconventional approach.

I decided to go with the mobile-first approach for two reasons:
1. Designing from scratch would give me a better approach, seeing opportunity more than constraints, to discover better flows.
2. Since Bridge's USP is simplicity and easy of use, being able to simply capture the complex capabilities of the system would aid in the overall representation of the product and staying true to its intended purpose.

Nonetheless, I took a holistic approach at first to redesign the main two features: taking orders and tracking orders for mobile and desktop simultaneously. Once that was finalized, I continued with a mobile-first approach first.

The Redesign

- One of the main usability challenges was the size of the components and pop-up drawers. Since most of the merchants were using smaller tablets with majority of screens being 1024 x 720 pixels, having a navigation menu on the left and right-sided drawers left very little space for the main interface (middle). Upon observation, most waiters/cashiers used only the two tabs:
1. Home (where they took orders)
2. Orders (where they tracked orders and changed their status).

By making the menu retractable, wait staff/cashiers would still clearly learn the icons for their two main tabs. This, however, left significant room to play with in the redesign of the flows -- from simple ones to multi-step complex flows.

I followed a similar navigation for the native mobile application as well. Home and Orders was were the most daily usage was, following by inventory, where stock in/outs would be recorded periodically. The rest of the advanced features were all fit in the "Manage" tab. Again, the USP of Bridge POS was ease of use and I wanted to stay true to that.

Next, despite the short duration of the iteration, I felt creating a set of components and a basic designs system would be incrementally helpful during the development cycle. The desktop version followed a dark theme while the mobile application followed a light theme. The colors and components were handed over to the developers prior to the final UI handover. This sped up both the design and development cycle significantly.

Another critical design decision I made was that there would be two sets of primary CTA buttons -- one for the interface and one when it involved the order flow/payments. A bright neon green (despite clashing with the rest) sacrificed UI aesthetic, but tested to be very effective in terms of the UX. Users knew that the green neon color signified critical actions while the blue (different shades for light and dark) signified clickable components/interface CTAs.

Desktop UI - To be Added Soon