Case study · September 28, 2022

Unifying the logistics under 1 tool

Biggest problems in any logistics business is transferring responsibilities and the communications

Crude oil and its byproducts are transported primarily through waterways, railways, roads ways and pipelines. Many times transportation happens in 2-3 different modes. There are around 12 teams coordinating the logistics, using multiple modes of communication, various tools, and means. With this project, we are trying to unify all 12 teams and provide them with a super app that can reduce repetitive work and errors.

Strategically this app plays an important role to align crude oil logistics organizations to be leaner & greener.



  • Focus group sessions with a business focal of around 15 people comprising of PO, PM, sponsor, LOB tech advisor, and the segment architect and Logistic operation leads (who would be some of the users of this app), in order to understand business goals and strategic importance for the application.
    • Affinity maps
    • Problem exploration
    • Risk appetite study
  • Stakeholder study
    • Interviews
    • Focus groups
  • Service Blueprint
  • Touchpoint study and applications/features to be built

Expected team size

  • 2 lead designers
  • 8 senior and associate designers
  • ~80 other roles (frontend dev, backend dev, DevOps, QA, data science, project management, change management, and more roles)

Stakeholder mapping

This is where we started diving deeper into the requirements. We not just started asking questions but ran design thinking workshops with POs and SMEs in order to understand users and the ecosystem from the business perspective. This exercise gave us a deeper glimpse into all the stakeholder relationships and where to focus our efforts.

Should we be innovative or conservative?

As designers, we had to understand if the business wants to be innovative or stick to conservative and proven means. When designers know the extent of innovation supported, we are well equipped to suggest changes to the system.

Problems & assumptions exploration

Businesses sometimes cannot distinguish between real and assumed problems. This exercise is intended for the business to think deeper about the problem at hand and call out assumptions by writing a testcase. In turn, it helps designers/researchers define hypotheses.

5 Whys

This is one of my favorite exercises to decipher what the stakeholder is thinking. Asking why will make them think deeper and get to the core of the problem and find a solution to the crux of the problem.

And here is the summary of our 2-day workshop

Service blueprint

This is a vast ecosystem where we are trying to integrate 12 teams into 1. This task requires more than just an app design, this would need many process changes, new services being introduced and some automation as well.

To understand all, we would need a map of teams as-is and learn how they are exchanging responsibilities and where are the gaps in communication. A service blueprint gave us precisely that.

It took us more than 2 months for us to run some surveys in order to gather some quantitative data and then switch to qualitative methods like interviews and ethnographic studies to learn deeper about each role, map relationships between roles, and validate some hypotheses.

After a detailed analysis of the service blueprint, we decided on 7 major features to comprise our application. And of course, there were many processes and service changes to follow, which are still in exploration.


Feature 1 – Supply vs Demand

We had done enough study about the ecosystem, now it was time to quickly understand the user, based on the feature we were designing and we did a quick

User journey map for Supply vs Demand module

Data flow

App flow

Supply & demand – low fidelity wireframes

Supply & demand – high fidelity designs