POS Feature Redesign
A POS system migration project for a large fast food client
Overview
ROLE:
Product Designer (UX/UI)
TYPE:
Internship Project
TIMELINE:
4 weeks
Summer 2023
TOOLS:
Miro, Figma, Jira
Background
During my internship at EY, I worked on a point of sale system migration project for a large fast food provider client. I was in charge of leading the mobile and desktop redesigns for a future state feature on the Point Of Sale system called Site Option Override. Throughout the project, I was able to take part in many steps in the design process; initial discovery, requirements gathering, designing and prototyping, and design reviews with both my internal team and the external client. Though I worked on several other features, Site Option Override was the only feature that was completely self-led and presented independently to the client, so that is what I'll be covering in this study.
Note about NDA
I am not able to publicly share some information including disclosure of the client name, wireframe links, and brand/style guide, due to an NDA. Please contact me personally if you require more information.
01 / Define: Establishing User Needs and Problems
Overview
Challenges
Goals
Challenges
Transitioning from the legacy system to the future state features required an overhaul of the current usability. I had a lot of information to fit within the constraints of a data table with a predefined size, and I knew I would have to rearrange certain features to keep the table readable and not too crowded.
Goals for the redesign
Update the old feature with the new design and style guides
Retain usability and readability of a previously crowded data table
Assess use cases for certain features; decide if anything can be removed to save space
02 / Ideate: Creating the Framework
Overview
Desktop Ideation
Mobile Ideation
Idea #1
Since there was no way to standardize this type of data selection, my initial idea was to combine the 'default value' and 'override value' into a single column.
Left: legacy version; Right: Idea #1
Idea #2
Idea #3
Mobile
Desktop
Site Option Override customizes how the POS system appears front of house. With a lot of information to fit onto a single page, the initial design in the legacy version opted for a data table. A challenge in the process of figuring out how to condense this table were the different data types needed for the different options: users could choose between boolean yes/no answers, select time from a dropdown, and type in their own number to override the default.
Another option I explored was leaving the read-only 'default value' column in place, removing the visible 'override value', and adding in a pencil edit icon. I was hoping to simultaneously save space and improve the readability of the data table by cutting down on the amount of crowding in a single row.
From here, I had two ideas for how the user could access the override value and functionality. My first idea was that clicking the pencil icon would open the edit box (either dropdown or type-in based on value type). In this version, I changed the column name to just 'value', and decided that the value shown would be whatever its current state was.
My other idea was that a modal would open upon clicking the pencil, which would contain both the default and editable override value. This would save space, and make more sense from a usability aspect by allowing the user to see both values at once, and have a better idea of what they are changing.
The final solution I landed on ended up being the best option that I ran with going forward. Since the users have the ability to filter options in the table by category, it didn't make sense to also allow them to sort by category. Because of that, I was able to save a lot of space on the data table by making the category sub-header text under the option name, which left enough space to leave both the default and override value in the table. This seemed like the most sensible route, by allowing users to see what the default value is and not confuse them by hiding it or only having it labeled in a dropdown. I also ended up adding a tool tip button at the end of the row to define what each option name means to eliminate any user confusion.
Another difficulty for this feature was working desktop-first instead of mobile-first, which is not the way I have done design in the past. There also were not as many design conventions yet for the mobile version of this system, so I got to think about the design from a developer perspective and how to make things easy for them in terms of not having to completely redesign a page to fit a smaller screen. I tackled the design first with the general home screen, which I came up with 3 alternate layouts for.
Something I discussed with the other designer on the project was the necessity of the filter by category functionality. Was it just a nice-to-have for desktop and something that could be eliminated on mobile? I explored 3 different ways to present the filter by category function: in option 1, it's a filter icon. In option 2, it's the same dropdown as desktop. In option 3, it's a new kind of dropdown.
I ended up going with option 2 for the main screen, because it was easiest for the developers to go from desktop to mobile in this version. They could make the top bar wrap around, so everything just becomes stacked when the screen is shrunk down.
03 / Prototyping
Overview
Wireframes
Design Review
Design Review
Wireframing
I designed screens to cover several different scenarios, and prototyped a walkthrough of all the different actions a user would be able to take on this screen: updating override values, filtering by category or by search, clearing values (whether by clearing all shown or by clearing just what is filtered), and any outlier scenarios the developers may have needed. Below is the original legacy version of the feature followed by the redesigned version. There were not enough use cases to justify users being able to individually select options, so the checkbox functionality was removed.
Desktop legacy (top) versus redesign (bottom)
Mobile legacy (left) versus redesign (right)
My design process was interspersed with reviews from the senior UX designer on the team and 2 bigger design reviews. Once my initial versions were polished and prototyped, I presented them for review with an internal team and one client present. After I made the recommended changes from that review, I presented to a group of clients and stakeholders for final approval.