The complexity of product pricing in a farm-to-kitchen food distribution app.

I faced the challenges of designing a flexible but simple pricing system while working on the app for REKO — a farm to kitchen food distribution system. Right now, producers use Facebook posts to advertise their products. They have complete freedom to price their products as they see fit because there is no backend that keeps track of units and prices. Therefore it is crucial to balance the ease of use and the diverse variety of products and pricing methods, as producers can easily ignore the app if they feel it doesn’t satisfy their needs for flexible pricing. In this short article, I’m going to share my process through which I landed on a suitable solution.

First version of creating a produc + pricing

Version 1

In the very first version I did not take into consideration the complexity arising from the variety of products and producers. I designed a simple product creation process with only one way to set price, however later I had to face my own ignorance about the complexity of pricing when I wanted to recreate an ad from a real Facebook post. I could not set the pricing, units, quantities and other information right. So I went back to the drawing board and worked on understanding the structure and logic behind pricing, product units, purchasing units and bundled products.

1. Product card mockups

First, I translated some Facebook ads into products in the app. I looked at what information the producer included in the FB post and how I want to organize that information in the app version.

2. Analyzing pricing method

Then I looked at many different Facebook ads, selling many different kinds of products priced in many different ways. I analyzed the pricing methods, and established six main ways producers pricing their products.

The 6 main types of pricing in REKO

3. Reverse engineer

When I understood the pricing methods and what the producers are looking for when selling, I started to think backwards: if I want to see X and Y on the product card, then what options should I provide during the product creation process? I created a list of options that I wanted to include in order to keep all the flexibility the REKO producers are used to on Facebook.

Sketches and notes from my reverse engineering process

4. Best practice research

In order to understand how pricing and units work in other apps, I visited many real and fictitious grocery store websites. I found some useful instances, however no online store covers for the wide variety of product types and pricing methods used in REKO.

Analysing other solutions

5. Version2

After reverse engineering and best practice research I created a more complex UI that allowed for bigger flexibility. After a few tries and user testing I had to realize that even though this system was more flexible, it was unclear and thus less usable than the simple but limited version.

Version 2 wireframe

6. Simplifying

In order to create a more usable solution, I decided to settle between flexibility and simplicity. I simplified the pricing which increased ease of use, but at the same time reduced flexibility. I prioritized the functions and reorganized the possible options in a way that allows for multiple type of product cards.

7. Final version

The final version is a compromise between simplicity and flexibility. It provides different ways of pricing in a way that is manageable in an app.

Final version of product creation and pricing process

Reflection nr1: This is a ‘good enough’ version for launching. If it was a real product, I would continuously monitor and improve this part, due to it’s critical role.
Reflection nr2: Compromise is not the only option to make something easy to use. Looking back, I could have taken into consideration other options: for example improving labeling and naming or work more on the UI design so the process is clearer. I could have taken into consideration an onboarding flow, that explains how the priing works. Also, I would do an onboarding with this simplified version as well, to make users comfortable with the UI.
Reflection nr3: During the project I realized that a complex process like pricing could be easier and more efficient to manage from desktop. So in further development, I would extend this mobile app for producers (first) to be able to use on desktop.