Corporate Purchasing System

Taking Control of A Corporate Purchasing System

(Detailing my UX design process)

Client
Multinationa consultancy (Unnamed for NDA)
Year

2019

Scope of Work
  • UX design
  • Visual design
Deliverables
  • UX research
  • Wireframes
  • Usability Testing
  • High fidelity designs

How can we organize the purchasing of a multinational corporation with a half a billion Dollar turnover?

Frame

I worked on the first two sprints of this design project while I was working as an in-house designer on the span of 8 weeks. The project is given a white label and visual design has been altered since.

This case study is an in-depth look into my UX design process with rediculous details. It’s not pretty, but it sure is detailed

About the project

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. This project, though, consisted of going the road less traveled and developing a proprietary system inside of the client’s existing propriatry ERP, despite the Massive size of the company. Sheeesh!

01. Discovery

Understanding the organisation

Getting started

For someone who hasn’t tried their hands at a corporate job, it can be intimidating to try and solve a problem of this magniture. So I started 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 I have gotten myself into, the requests of the clients and some early feedback from users. After a few discovery meetings with the PM, testing the existing products (a tomorary fix), discussions about the roadmap, I drew a diagram to help me navigate the project as well as the different stakeholders.

I can't stress it enough: Write things down and use Diagrams. When you first land in a new organization, you don't speak the same language as them. Diagrams are language agnostic.

MeEvery chance I get
01. Discovery

Understanding the roles

Getting started

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

When embarking in a new organization, especially in an office with hundreds of people, keeping track of names can be tricky. That’s why it’s important to
The event that happens and pushes the user to launch the product. It’s not the goal, it’s the reason
The goal is the basically the expected result after using the product
Success metrics are an important factor in making sure the designs actually solve a measurable problem. Otherwise, the outcome of the project is my word against yours.
02. Research

Interviewing, Prototyping & 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:

Diagrams, diagrams, diagrams

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.

Organising interviews

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.

Try to have at least two people from each proto persona. One person’s opinion can skew the work beyond repair so it’s important to have multiple contact people and contrast opinions to each other. After getting a user’s feedback, one phrase I usually use: “It is my understanding that XYZ, would you say that’s an accurate caracterisation of the situation” or “I’m given to undersand that XYZ. In your experience, is it true that ABC…”. Don’t make it about specific people.

Keeping Track Of Everything

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 I use Google Keep for its simple interface, organization system, and collaboration capabilities

For stand up meetings, it’s nice to use a physical medium. A Google Jamboard would have been nice, but so would telepathy too! Yes, even I sometimes go back old school style and use those sticky notes that I love to hate. The great thing about sticky notes is that their small size forces you to think about what you want to note and be concise. But I’d take miro’s sticky notes any day of the week

What we came up with

So the outcome of this project was a first version of the purchasing system in which users are capable of passing their own purchase orders to existing suppliers from the database. They can also introduce their new suppliers and wait for them to be vetted and approved.

Web

PO Home page

Right off the bat, the dynamically generated home page solves many problems that drove many users astray. That includes searching and filtering POs, getting diret visual access to different POs based on status. We also managed to put a lot of information in a limited space without it being crammed or too dense.

Web

Making New purchase orders

In a giant corporate structure, making a purchase order necessitates the intervention of multiple departments that want diffenret types of information. There is no going around the fact that the Form is going to be lenghty.

That’s why we opted for the form wizard that divides the process into easily navigable sections. making sure that each field is in the right format (input, dropdown, radio, checkbox) also aids a lot in reducing errors.

End of the first round

As I said before, I was only around for the first round of design so I obviously don’t have more to show. The next step would have been to launch as early as possible and start collecting feedback from users as well as collecting quantative date via tools like Hotjar. But that’s for another case study. Cheers!

I can build one for your

Need To Get Things Done?

Leave your contact information and let's schedule a call

Get in touch