Aloha Smart Manager: Cash Manager
A Lesson in the Use of Design Systems
Role Product Designer, October 2022 - Present
Team 6 UX Designers, 1 UX Researcher, 10+ Product Managers & Product Owners, 50+ Developers
Background
Aloha Smart Manager (ASM) is NCR Voyix’s next generation restaurant management solution that includes administrative, inventory, labor, and sales tools to help a restaurant increase revenue and efficiency while reducing costs. NCR Voyix Cash Manager is an app designed to keep a full and comprehensive account of all transactions in the restaurant and also provides advanced cash-flow analysis—enabling restaurant managers to predict future financial positions based on analysis of past data.
In 2023, NCR Voyix announced its intention to merge the two lines of businesses, Retail and Restaurants together. As the cash management systems were the most similar products in both lines of businesses, I was tasked to use Retail’s cash management design and apply it to Restaurant’s version. This case study explores the challenges of this task and why ultimately, our team decided not to use retail’s designs.
Identifying the Problems
Issue #1: Using the same design system does not mean products will look the same! Retail and Restaurant products have historically been treated very differently, and until five or 6 years ago, even used different design systems. In a move to create more consistency between all NCR Voyix products, our designers decided to use a single design system and based it off Google’s Material Design. However, even with the use of a single design system, the usage of components, patterns, and theming were still very different and this was the first issue I encountered when I started working on the project. Even a quick glance at the pages below, you’ll notice their great differences!
Let’s take a closer look: Both Retail and Restaurant apps use button groups to enable viewing of historical data, but notice that Retail uses the “MM/DD/YY” format for dates, and Restaurant uses the vernacular with the ability to manually select a specific date by clicking on the calendar icon to reveal .
Tables (data grids) are also present in both designs, but Retail’s version uses alternating colors for its rows, the grand totals are located at the top of the table beneath the header row, and cells with no values are indicated with dashes. Restaurant’s version has same color rows, the grand totals are located at the bottom of the table and cells with no values are left blank. In addition, Restaurant’s table has a search bar and additional filters.
On Retail’s declaration page, the tender calculator appears as a card on the right side and the cash denomination calculator a modal. Restaurant has both calculators that appear as detail panels that slide out from the right when the use clicks on the calculator icon.
Issue #2: Gaps in the product requirements = different architecture. While the business goals and product requirements were similar for both products, the user flows were vastly different, and in areas where we still had gaps, there was an added challenge of figuring out where to fit certain capabilities/features within Retail’s existing architecture. For example, self-banking is when the waitstaff at a restaurant carry their own cash bank during their shift instead of using the cash drawer and makes them responsible for their own cash transactions. In retail, this concept does not exist and all employees share a cash drawer.
In addition, as you can see from the sitemap below, Restaurant’s cash manager is within an app that manages all of the backend operations of a restaurant, while Retail’s cash manager is a stand-alone app for managing cash flow only. Notice also the difference in industry terminology: “drawer” vs. “till”, “safe manager” vs “safe balance”, etc.
Solution
Since Retail’s version was already implemented and launched, our team did explore the possibility of just adopting their existing designs, however, doing this meant that it would be inconsistent with the rest of the restaurant management app (that was already built) and therefore, an inconsistent experience for our restaurant customers. In the end, our team decided that the best move forward was to leverage as much of Retail’s backend architecture (with a few tweaks for self-banking) and not to use Retail’s designs. Yes, we could have separated the cash manager out from the Restaurant app and leveraged Retail’s version, but one of Aloha Smart Manager’s main priorities is to provide a “one app” experience for restaurant management, and we knew using Retail’s cash manager was going to be a disruptive experience for our users.
Results & Takeaways
Merging products take time and shouldn’t be rushed. While the Retail and Restaurant products were similar in concept, in reality, the timeline, money, and politics involved made it far more difficult to merge. If I could go back and do things differently, I would have insisted on having a product designer at the beginning of the conversation and work together with the Retail designer to do a total revamp of both products and plan a strategy to slowly transition into becoming one experience. We ended up leveraging all of Retail designs, but it came at the expense of having this one part of the experience so different than the rest of the app.
Have confidence in your design decisions and be prepared to explain why you did what you did. Sometimes people ask questions because they are simply curious or they want to know more about your thought process.
Have patience. At larger companies, decisions need to come down the ladder and then back up again—and this happens repeatedly.
You will not always love every design that’s pushed out or agree with why. And that’s okay. Sometimes the product teams need to make a decision that is based solely on time and money and nothing else. Everyone wants to build a product that is beautiful and functional, but sometimes it just doesn’t happen. And that’s okay.