B2B Compliance Management Platform

Key Tasks:

- Identify User Pain Points ( User / Industry Research )
- Stakeholder Journey Mapping
- User Story & User Flow
- Information Architecture ( IA )
- Low Fidelity Wireframe
- High Fidelity UI Prototype
- AB Test & User Test

Understanding the Industry:
Define Problem Statement, Early Stage Task Flow & User Journey Mapping

Before jumping straight into designing for the client, it is important to learn about my users & the business industry I am getting into. I believe as a UX Designer, it is an extremely valuable skill to use the least amount of time & effort to quickly get to know the users and to learn the basic knowledge required from the Industry.
Gather Business Requirements & Stakeholder Interviews (functional/non-functional)
Expectation, Project Vision, Business Goal, Value Proposition, Competition, Customers, Context & Workflow?
The Supply Chain Industry has remained unchanged for decades. Phone calls. Emails. Outdated ERP systems. Invoices. Spreadsheets. When it comes to QA/QC management, it can get super frustrating overtime. Therefore, by using the following simple template of user story:

As a < type of user >, I want < some goal > so that < some reason >.

As I would be able to know,
1. Who are my users?
2. What are the issues / pain points?
3. How would I solve the problems?
The User Flows (movement within an interface in a blueprint type fashion) below do help stakeholders to see what options the user has on each page, and if the routes are available, this may help the user accomplish a task smoothly without wasting any extra time.

Information Architecture (IA)

Building a good IA is very critical, since it would give the product a competitive advantage. Users want to perform their tasks with the least amount of effort possible and will choose to use the product that creates the easiest, most pleasant experience for them.
Especially when it comes to a complicated product as such, mapping out the entire IA not only can help managing the project scope, but it can also help designers to communicate a lot easier with programmers at later sign off stages.

Lo-Fi Wireframing

Lo-Fi or Low Fidelity Wireframes are basic representations of concepts that would aid me in the process of validating concepts during the early stages of a design process. It is also a great way to ensure my stakeholders and I are on the same page after gathering certain requirements.
This can be considered as a technique that encourages listening instead of selling. It will open a conversation that aligns and discusses the goals of the stakeholders, intentions of the designers as well as needs of the users.

While rapidly throwing those box & shapes together, do not hesitate to add a moderate amount of colors as well; as long as it does not distract stakeholders or business team to receive the idea, it might even provide a closer view/imagination of how the structure of the product will look like.
While progressing to Mid-Fi, there are only limited interactions & design efforts to be used to describe the design alternatives, initial concepts and screen layouts. Also, the main purpose would be informing, educating and communicating with everyone that’s involved in the design process.

Hi-Fi Wireframing & Prototyping

Before producing the final design, a High-Fidelity Wireframe may give the client a pretty good idea of how the platform will look and feel, before going through the entire software development lifecycle.
And here are some more hi-fidelity wireframes from a different module that later has been combine into the same management platform.

Bear in mind that these wireframes are not real deliverables, and they mainly work as a platform for designers and developers to create real deliverables. So, the primary goal of this is to ensure that the design and development teams understand the client’s vision.
With the Aid of Figma & InVision Studio, I could easily generate interactive prototypes with just a few clicks. The main purpose of creating an interactive prototype is for the use in the usability testing of the product & having target users to validate it. It is important to test the platform before launching it in the market to foresee any issues or failures.

The more interactive and realistic the prototype is, the more realistic the user will interact with the prototype so that the user will provide optimal insight as when they interact with the actual management platform.
To sum up, this was my very first time to be solely responsible for the design process of an entire complex B2B product that includes 6 core modules, along with multiple brand new features, that took up to 4 months of planning & designing in total plus a month of user testing in a Waterfall Development Methodology.

During the development process, I believed that it could have been smoothened up & improved time-wise due to unexpected business requirements enumerated gradually overtime; however, I am still very satisfied with the result of the outcome and how much I have learned from the process of conception to testing & deployment in these few months.

With the equipped fundamental design skills & knowledge, I suppose the next critical skill following design thinking would be the ability to rapidly understand the required industry knowledge (Supply Chain Compliance in this case) as a UX Designer.

Design Sprint for V.2 Revamp

Since our product team was hoping to get stakeholders actively involved in creating the solutions for optimal v.2 revamping results, we decided to give the Design Sprint Framework a try.

Day 1 - Note-n-Map & HMW

To kick off on Day 1, we started with mapping out our Understanding of the product target & target user needs by Asking the Experts to formulate further strategy.
Note-n-Map is a technique for speeding up and simplifying the map-making on the first day of the sprint workshop.
Ask the Experts. We interviewed experts on our sprint team to ask about the vision, customer research, how things work, and previous efforts. A tip is to pretend like I am a reporter. Update long-term goal, questions, and map to proceed.
How Might We notes. Distribute whiteboard markers and sticky notes. Reframe problems as opportunities. Then stick all the How Might We notes onto a wall in any order. Move similar ideas next to one another. Label themes as they emerge. Then vote.

Day 2 - Lightning Demo & Crazy Eights (Diverge & Ideate)

For Day Two, our main goal is to develop lots of solutions from the HMW problem statements from the previous day.

Lightning Demo. I sketched a thumbnails on the whiteboard to serve as a reminder to highlight other products that are similar, dissimilar, or even competitive to what was being explored in the Sprint.
Crazy Eights. Now it's time for participants' turn to sketch out potential solutions, 8 per each Topic / HMW problem statement. And then let them pick 2 of their best sketches to do a more detailed sketch based on that.

Day 3 - Sticky Decision & Business Canvas Model (Converge & Decide)

Sticky Decision. I followed these 5 steps to choose the strongest solutions from the final sketches of Day 2.

Art Museum (Tape sketches on the wall in a row).
Heat Map (Have each person review the sketches silently + 3 like votes stickers).
Speed Critique (3 mins per sketch. In groups, discuss the highlights of each solution).
Straw Poll (All at once, each person silently chooses a favourite idea).
SuperVote (Give the Decider three large dot stickers, will prototype those).
Business Canvas Model. After a heated open discussion, operation team suggested that we may still need to narrow down further for our topics that will highly affect the key functions of our product. So we ended the sprint & started working on a business canvas model instead, to tackle the core issue of the product.
Even by the end of the Design Sprint, we could not come up with a solid solution to our core problems, but with the new issues that we brought up with the stakeholders, we had a clearer path of how should we reconstruct our backend structure.