Taking Control Of A Corporate Supply Chain

Showcasing our projects


Corporate supply chains are complex beasts. Most companies go for off the shelf solutions or have supply chain management modules inside their ERP Software (Entreprise resource planning) such as SAP or Zoho. Our client, however, a multinational consulting group (who shall remain nameless for confidentiality reasons) opted to take the road less traveled and develop a proprietary system inside of their own ERP, despite the Massive size of the company (Over 5000 employees across over 50 countries)


February 2019 –  April 2019


Product Strategy, UX design, Visual Design:

PHASE I: Discovery

For someone who hasn’t tried their hands at a corporate job, it can be intimidating. So we start off with a swift and thorough study of the company in lights of the project at hand.

The goal of this step is the get a good sense of what we have at our hands, the requests of the clients and some early feedback from users. After a few discovery meetings with the PM, testing the products, discussions about the roadmap, we drew a diagram to help us navigate the project as well as the different stakeholders.

Our attempt was not to plot out the entire organization, it’s just to put the product and its environment in a format that we, the design team can understand and explain to other people. The main takeaway is the sheer complexity of this company’s supply chain and the number of different users that intervene at one step or another. The next logical step is to create our proto personas. Our framework for that highlights 3 major components of every persona

  • Reasons for using the product
  • Triggers for using the product
  • Goals for using the product

Through meeting with the PM, we pretty much nailed what we were looking for. We were able to pin down the interaction of each type of employee with the system. Here’s what we came up with

PHASE II: Interviewing, prototyping, and testing

Because the technical barrier to software development is getting lower by the day, the true question is not whether or not we can build it. The question is: What do we need to build. That’s where UX design comes in. Instead of speculating about what the product should look like (we’re not talking about the visual aspect here), we go right to the users and ask them. And so we did.

After discovery, it was very clear that the first thing that needed our focus is the purchasing system. There was an old system in place, but the work was going to be practically from scratch. The first thing that we needed to do is to understand the challenges of the old system and the new requirements from clients. We didn’t really get a chance to talk to them at first, so it was basically the PM and us discussing requirements. We tried to challenge the requests because they felt kind of like “client briefs” more than anything at that point. So that was a first layer of filtering that we used to come up with a prototype. So we had a lengthy discussion to come up with a “somewhat” “sort of” “kind of” primitive information architecture diagram. Again:

Putting things into the simplest diagrams greatly helps with visualizing what we expect from each component and it gives a great opportunity to rearrange elements in a way that makes better sense.

All we needed now was a prototype. For that end, we count mainly on low fidelity wireframes. But since the system was built on Bootstrap 3, we used that design system for our wireframe. We would later refresh it with a layer of proper visual design. But for the purposes of the usability test we needed to conduct, this was more than enough.

And from there, It’s off to the interviews. Oh, yes grasshopper, UX designers use Microsoft Excel toon quite extensively too. We use it almost more than our favorite design tools. When you have many personas such as this case, things can get a little out of hand, especially that we make it a rule to get in touch with at least 3 people from every persona before we validate any assumptions or learnings. Notice the importance of color coding that we keep all across the process.


Another thing to beware of is taking notes. Trust us, when you do 20 interviews in the course of two weeks, things tend to get mixed. That’s why we use Google Keep for its simple interface, organization system, and collaboration capabilities



For stand up meetings, it is essential to use a physical medium. A google jamboard would have been nice, but so would telepath too! Yes, we went back old school style and used sticky notes. that I hate to love. The great thing about sticky notes is that their small size forces you to think about what you want to note and be concise.

What we came up with


Thank you for following

Call Us!