Concessions Platform
Matches
Overview
Matches wanted a business application that could help them set up and authenticate concession brands that the business sells. It also allows any new concession brand to seamlessly integrate their systems with ours and it will be used by both buying, logistics and finance teams.
Role
Product Designer
Platforms
Web app
Skills
UX/UI (using Figma)
Stakeholder negotiation
Presenting
Jira
The Problem
Matches moved to a concession based retail model but had no platform for connecting with our concession partner's internal systems. This new platform needed to enable both parties to set up the new brand and monitor data that's being shared via API calls.
The Outcome
The platform was launched and is being used daily by Matches and its concession partners.
How we got there
The process
Initial stakeholder discussions
The difficulty with this project was; the users, product manager and developers only had a vague idea of what they needed. This was because we didn't know what all of the data would look like, nor had we seen or worked with a tool like this before, so the user research that could be done was limited. Therefore, the design of this platform was based off other applications that I had designed in the past that we new worked, plus a lot of back and forth discussion with all stakeholders about how they thought it should work, while trying to manage everyone's ideas and expectations.
Because these designs were iterated so much and there is a lot of technical background information, I will only explain the final screens for this project.
User flow
Early on we had an idea of the user flow but this was also iterated as the the project progressed.
This is an overview of the six business processes that power Econcessions.
How might we?
As a result of initial discussions with the Business Tech Product Manager and developers, we decided to focus on how we might design and build as quickly as possible, while iteratively seeking feedback from the users and adapting as new requirements come in.
To achieve this, I used the new Matches Design System components because this allowed me to adapt my designs quickly in response to feedback. It also allowed developers to build out the components quickly and create a library which can be used to update old and new business apps. I also used my past experience of designing similar business tools to help me design the foundations of this new platform.
Homepage
The app needed to be divided into two areas. Setting up a new brand, and then being able to view various data sets. So it made sense to divide the homepage that way.
Clicking on a card would take the user to a new page.
Creating a brand
During the on-boarding process, there will be a two-step authentication step up.
The first step involves entering initial information about the brand such as Brand Name and Vendor Number which will have character verification.
The second step will be authenticating the brand. First the brand partners will provide authentication details which the user inputs into the Client ID and Client Secret fields. Then, the user inputs the URLs that help connect with their APIs, and mark them as disabled or enabled depending on what information we can send and receive at that point in the set up process.
Viewing a brand
After the authentication is complete. The user will be taken to the View Brands table (which they can also access from the menu or homepage).
Upon landing, it will show a green snack bar saying that the brand has been created. This new brand will also appear at the top of the table.
There will be an orange indicator on rows where not all URLs have been enabled as a reminder to the user. They can see which URLs these are when they click 'View more' under the Brand Systems URLs column.
If the user expands the Client ID/Client Secret accordion (or clicks Edit) they will see the Matches authentication details which were created during set up, they can now copy this and send it to the brand.
The user can also apply filters, search, and download this table to CSV.
Editing a brand
The user can edit a brand from the View Brands table. This page includes all the previous set-up details.
They cannot edit the brand information but they can amend the URLS and enable/disable them.
They can also amend the brand authentication details but they cannot amend the Matches authentication details, they can only copy this information.
Once amended they can save their changes.
About Consignments
A consignment (also known as an Advance Shipping Notice or ASN) is created by the brand (Consignment Created) partner and sent to Matches systems.
Matches needs to know about inbound consignments. Without this, we will be unable to receive stock.
Before brand partners can send us any consignment requests, Matches will need a Product Library from the brand partner that maps with our Product Library. This is to ensure that we have all the SKUs in our systems to process consignments as quickly as possible.
If all the items in the consignment are available in the Product Library, a 202 Accepted response will be returned. If any SKU isn't present in the Product Library, a 400 Bad Request response will be returned, indicating that the creation request was unsuccessful.
Following some background processing where we create any missing items in our systems based on the Product Library, a 'Released Consignment Status Updated' message will be sent.
Upon receiving the physical goods, our Distribution Centre will start sending partial receipts (Consignment Receipted) from the Matches systems to the brand partner API.
Viewing Consignments
The Consignments table shows users statuses for each consignment, and next to this column header is a tool tip for explaining what each status means.
Replaying a consignment recalls the status information.
Clicking 'View more' on any row will take the user to a new page showing further consignment details.
The user can also filter, search and export this table to CSV.
Viewing Stock Snapshots
Once a day, Matches creates a Stock Snapshot of all of our inventory in our warehouses. Upon completion of the Stock Snapshot, Matches sends the data via HTTP to the brand partner.
The first table gives a brief overview of the brands and then by clicking the 'view more' button, users can see the stock snapshots that have been periodically created.
Viewing Daily Sales
Sales information (shipped and refunded only) will be shared with the brand partner on a daily basis via an API call.
The first table gives a brief overview of the brands and then by clicking the 'view more' button, users can see orders that have been placed. Each order can include multiple item lines so each row is expandable to reveal these.
Viewing Return to Vendor
Brand partners can send a request that Matches return some of their stock. This is called a Return To Vendor (RTV). When our Distribution Centre receives the RTV Requested message, they'll start processing it. During the processing of the RTV request, Matches will send brand partners RTV Status Updates. When our DC has packed some or all requested items, Matches will send brand partners a RTV Completed message.
The first table gives a brief overview of the RTV requests for each brand and then by clicking the 'view more' button, users can see further details of the RTV request.
User feedback
Throughout each stage of creating these designs we had routine meetings with the users, the Product Managers, and Developers from Matches to ask for their feedback. I also wanted developer and stakeholder input because they were able to tell me and the user what was feasible or not, so that I could work with any limitations and design something that worked for all stakeholders.
Project success
The Business Tech Product Manager announced to the company that they recently launched the new platform alongside launching Max Mara as one of our new concession brands.
