The Aggregation Confusion

Not So Smarticles
3 min readApr 14, 2021

--

A few days back, during one of our whiteboarding sessions with the engineering team, we came across an interesting problem which is seemingly basic to solve. This article will describe a few approaches attempted to solve the problem.

The Product:

The product is a mobile application that can be used by a customer to make e-commerce purchases from the comfort of their home. The customer can place an order, make the payment and manage orders from the app.

Objective:

To build an order history section in the app which can help customers manage their orders. Additionally, from an implementation perspective the solution should have a standard structure and should be scalable.

The Problem:

Through the order history section, the user will be able to view all their recent orders(latest first). On selecting an order, the user will be redirected to the Order Details section where they can view Order Item Status and cancellation or refund information, if any.

Order Status: The following scenarios could take place when a customer places an order on the platform:

Order Status table

Problem from an Implementation Perspective:

a) Supposing the order history section is paginated, will the pagination be on the Order Items (3 + 1 + 2 as defined in the wireframes above) or will the pagination be 3 orders?

b) If the pagination is on the entire order, what if one order has 15 items, one has 2 items and the other has 1? How can all these items be displayed on the screen?

How can the orders be aggregated while keeping the query less complex and standard across?

Wireframes for the Order History Section

Whiteboarding

Suggestion 1 : Cap the items displayed under each order to a maximum of 3 and display 10 orders on the page. Counter: What if an order has less than 3 items? The query will be different for all items

Suggestion 2: Display each item as an individual entry and paginate on order item instead of order. Counter: Fetching the item price and item status could increase page load time when the number of orders increase

Suggestion 3: Look for inspiration! While checking the order history section of a few e-commerce apps, we realised that most of the order history sections consist of orders that are grouped by vendor/merchant/brand and no pricing or status information is displayed on the order history page.

The Current Approach

While all the three suggestions are seemingly plausible(or not!), the one that resonated with the product team the most was Suggestion 1 wherein, the order history will be grouped by Order and capped at displaying 3 order items per order. Suppose the order has < 3 items, only the 1 or 2 items will be displayed and the user can select the order to view order details.

Sign up to discover human stories that deepen your understanding of the world.

Free

Distraction-free reading. No ads.

Organize your knowledge with lists and highlights.

Tell your story. Find your audience.

Membership

Read member-only stories

Support writers you read most

Earn money for your writing

Listen to audio narrations

Read offline with the Medium app

--

--

Not So Smarticles
Not So Smarticles

Written by Not So Smarticles

Curious about product development. Coffee not tea.