FLOKI COMPRAS
From Concierge to a Real Marketplace in Food Service
Research · FoodService · Marketplace · 2023
6 min read
Role
Product designer responsible for the marketplace's design, working with a Product Manager, 3 Front-end and 2 Back-end developers.
Problem
A functional model, but impossible to scale
Floki Compras connected restaurants to large suppliers, acting as a Concierge: clients sent shopping lists to sales representatives, who submitted the orders on the platform. Floki specialists sought the best quotes by cross-referencing the items on the list with supplier spreadsheets, sending the quote for client approval at the end of the process.
The end client rarely interacted with the platform, and each order required action from Floki representatives and specialists. We served some clients efficiently, but scaling with this service model seemed unfeasible.
Besides being a less common model in the market (which could hinder adoption and usability), the process involved many steps and cycles, demanding much from the operations team and harming service agility.
The SaaS interface was built for representatives, not for the end client.
The original flow—three cycles, all dependent on human intermediaries.
My mission was to redesign the entire flow, transforming the system into a marketplace and ensuring any user could submit valid orders from their first access.
Fortunately, there are many good examples of e-commerce and marketplaces, which makes it easier to perform rich benchmarks and reuse patterns familiar to online users.
Solution
New perspective, new problems
In the first version of this transition, prices began to be shown on product cards, but the underlying structure remained unchanged. The company's decision aimed to quickly gain scale, but this change alone was not enough to create a true marketplace.
Submitting a valid order was still structurally impossible for regular users because the necessary information (supplier, minimum purchase amount, payment method, etc.) was not presented.
Sales representatives operated effectively in this scenario because they had access to what the interface did not show: product spreadsheets from all suppliers and direct contact with Floki specialists. They were, in practice, the information layer the platform did not provide.
Initial version of the marketplace, adding price to the card but without full flow adaptation.
Marketplace Flow V1—Fewer cycles, but representatives and manual handling still required.
This first platform shift reduced cycles, eliminating, for example, the WhatsApp approval step, but orders still required intermediation and handling them remained an exhausting process.
Valid orders were processed and sent to suppliers; invalid ones were returned for revision among specialists, representatives, and clients. We needed deeper changes until the delivered service was truly self-service.
Starting with the catalog
In the process of implementing the changes the platform needed, we began with the catalog, aiming to consistently replicate the changes throughout the flow while monitoring how subsequent steps would be affected.
We made previously invisible information explicit in the interface. Each card now displays the product, price per unit of measure (Unit, Kg, Can, etc.), and the responsible supplier.
The catalog with supplier assignment visible on each card – the information the previous model did not provide.
To clearly show minimum value restrictions without cluttering the browsing experience, we added a bottom sheet to the catalog, triggered by the cart button. It summarizes the status of open carts, relating the accumulated value to each supplier's minimum value, and is only available when the user adds at least one item to the cart.
The bottom sheet – operational restrictions at the right moment, without cluttering browsing.
Visible requirements and a clear path
For the new cart screen, we started displaying each supplier's items separately in carts represented by tabs, adding visual indicators to help understand the status of each.
Value < supplier minimum: a warning is displayed indicating exactly how much is needed to reach it, along with a button that directs the user to the catalog filtered for that supplier's products, facilitating cart completion. Additionally, the proceed to checkout button is disabled.
Value >= supplier minimum: No warning is shown and proceeding to checkout is enabled.
New flow in interfaces.
A checkout that respects each supplier's rules
The checkout began to consider each supplier's particularities, segmenting by area of operation, offering customers only delivery options within the supplier's time window and accepted payment methods.
The absence of these elements allowed orders with PIX payment and Thursday morning delivery, for example, when the supplier only accepted cards and delivered on Mondays, Wednesdays, and Fridays, requiring renegotiation with the customer.
New checkout respecting payment methods and delivery windows of each supplier.
More opportunities for improvements
During the project, we worked closely with the operations team to understand the most common problems in submitting valid orders and how these were handled.
This contact gave us the opportunity to conduct shadowing research to deeply understand each step of the operational process. As a result, we clearly mapped processes and found opportunities for significant improvements through technology team actions.
The team discussed and assessed that it would be possible to make backoffice improvements with little effort, reducing the operations process steps by about 20%, which involved continuous tab switching, collecting external information, and note-taking, making work simpler for the responsible team and potentially reducing error rates during order handling.
Information architecture defining the product's navigation structure and user entity access limits.
Testing
Two research fronts to mitigate risks
In the final phase of the project, we conducted research to map and reduce our risks with the launch:
Interviews with restaurant owners: to understand if there were unmapped problems in our solution or other impediments beyond the platform's technical limitations.
Usability tests with sales representatives and regular users: seeking unforeseen scenarios, critical errors, usability issues, and opportunities to improve the experience.
The logic behind the prototype – real conditionals calculating progress, color, and checkout availability with each product addition.
A high-fidelity prototype with logic similar to the real system
For remote usability tests, we built a prototype in Figma. The minimum progress bar, color changes between valid and invalid states, checkout button blocking, and cart counters worked dynamically and responsively to user actions.
The goal was to simulate the real platform experience with enough accuracy to capture genuine behaviors. You can explore the prototype by clicking here.
For test setup, we used Google Meet, with front camera images of the facilitator and user, screen sharing of the phone running the prototype, and recording enabled for later analysis by the design team.
The Figma prototype used for remote usability testing.
Learning from users
During usability testing, no critical interaction failures were found, and familiarity with the system happened quickly. This was likely due to leveraging patterns widely known by the online audience. Additionally, we observed that at least 3 users tried to perform an action that, so far, resulted in nothing.
When opening the bottom sheet and realizing the minimum amount had not been reached, users tried clicking on the area containing the supplier's name and logo. They said they expected this to apply a filter to the catalog, showing only items from that supplier to help build a valid cart.
Observing this behavior, analyzing test sessions, and later discussing with the team, we decided to add this feature to the release version. We understood that "reaching the minimum amount" was a key action on the platform, and a feature requiring little technical investment (this type of filter was already used in the cart notice) that helped with this was justifiably valuable to prioritize.
Supplier filter added based on usability test learnings.
Result
Value delivered
After the project launch, we conducted interviews and consultations with sales representatives, restaurant owners, and operations specialists. In our conversations with representatives and owners, we identified a significant increase in perceived experience quality, and some owners were already purchasing independently through the platform, even without Floki actively promoting the new features or encouraging autonomous system use until then.
In our consultations with the operations team to monitor delivery, we were informed that the rate of operational errors and order processing time had dropped considerably, mainly due to platform limitations implemented and improvements made in the back office.
Reduced operational demand.
Self-service experience delivered
Fewer errors
What I would do differently
The intermediate stage, where prices were added without necessary structural adaptations, offered a confusing experience for users and intense demand for the operations team. Such a transformation needs to be very carefully calculated, considering the potential damage to product perception that an incomplete and confusing experience can cause.
