Monolite: An Interactive exhibit for public engagement
Posters & Invites
Apparel Campaign
Apparel Campaign
Apparel Campaign
Monolite: An Interactive exhibit for public engagement
Multi-user system for data verification & accuracy
Communicate, maintain and verify data
Green Story is a sustainability intelligence platform that revolutionizes how fashion suppliers and brands approach environmental responsibility through supply chain tracing and ensuring data accuracy and transparency.
This project was a joint effort with an awesome team of our CEO, 2 Product managers, a junior UX designer and me, where I was responsible for User experience and the User interface of the platform.
Project overview
To ensure data security and accuracy in a product’s footprint, acquiring reliable data from suppliers was crucial. The required data included process information (e.g., electricity, water, chemicals) consumed during the manufacturing of components, as well as certificates or documents to verify the accuracy of the data and details about the facility. However, this process was currently at the discretion of the brands providing supplier data, and there was no way to verify if that data was accurate. Additionally, some suppliers preferred to keep their identity anonymous to the brands while still providing necessary data.
We realized that the data supplied to us was often not primary data, nor was it verified, which meant the footprint calculations and projections were not 100% accurate. This posed a risk to the company’s image and market positioning.
Thus, we aimed to create a secure and accurate platform for the transaction of this data.
Research
Interviews
I conducted interviews with 5 brands and 5 suppliers to understand gaps and limitations of both the user groups.
Suppliers
-
Unorganized data
-
Apprehensive about losing the client if they know where they source their raw material from, so would want to protect their network of suppliers.
-
Not an expert in using advance software or technology
Brands
-
Some of them get their product from a middle man or a third party. Are not directly in touch with the supplier
-
There are a lot of delays in receiving the information. A lot of back and forth goes in this process.
-
It’s hard to keep track of multiple request sent to suppliers.
-
Positioning themselves as a certified sustainable brand
It was clear that there was a major communication gap and need of verified data for both the user groups. This got us to defining our goals.
Goals:
-
To create a smooth and verified exchange of documents and certificates, process data and facility data
-
To keep the identity of the suppliers and brands anonymous
Direction
With our goal and insights from user groups in place, I quickly mapped out the next steps. Green Story (GS) already had a platform for brands to conduct lifecycle assessments of their products. To ensure secure communication through the platform, suppliers also needed access. We introduced a Supplier Portal, which mirrored the platform used by the brands but with supplier-specific features.
To enable communication between suppliers and brands, we added a "Request" module to both user logins. The types of requests included: inviting a supplier to the platform, requesting process data, documents and certificates for data validation, and requesting missing information about the supplier’s facility. We also explored various use cases and scenarios to ensure smooth functionality.
User flows and scenario
Scenario 1: Brand invites the supplier to join Green Story
Scenario 2: Brand adds the document and invites the supplier
Scenario 3: Brand adds the document and requests the supplier to verify the document
Design
I decided to do some design exploration based on the scenarios to visualize and validate the flow.
Inviting supplier to Green Story
When inviting the supplier, they would login to the platform and provide, organization details, personal details and account details to successfully onboard themselves to the platform.
Invitation email
Onboarding step 2
Signup screen
Onboarding step 3
Onboarding step 1
Taking action on the invite
Validating or providing a document by the supplier
The type of requests were categorised into three categories, tracing request, certificates and document and audit. Under each category there were multiple types of request with unique actions for each.
Tracing request
Tracing request with actions
Tracing request with expanded view
Certificates and documents
Walkthrough & Feedback
I conducted a walkthrough of the flow with 3 brands and 2 supplier, we could not get large number due to unavailability and urgency to roll out the MVP. However, we did get some feedback on the the information flow and UI.
-
The onboarding flow was too lengthy. Account details and some personal or organizational information did not need to be collected immediately.
-
The request categories were confusing for users.
-
The actions required to complete a request were buried under multiple layers, making them hard to find.
-
There was insufficient information provided within the request details.
-
Keeping the UI consistent with the overall platform made it familiar and quicker to learn the new flow.
-
When there is an update on the request, the user should be notified through system notification
Final design
Changes were made both to the design and business requirement doc to incorporate the feedback.
1. Simplified the onboarding flow, eliminated non mandatory information
2. Reorganized the types of request by giving them individual real estate which also made the action items easily accessible.
3. Elaborated on the request details by adding request number, request type, status and action. The request details had the reference details, the request itself and notes for back and forth communication.
4. Implemented system wide notification and auto updates to receive and complete the request
Feedback & learning
By analyzing the sessions , we observed a 90% success rate in goal completion, with an error rate of just 7% and a user satisfaction rate of 95%. Feedback gathered through interactions with the customer success team indicated that clients were very happy with the new flow, as it made communication between them and the other party much smoother and faster. There were still a few changes we made post production based to smoothen out the flow and reduce time to complete the task.
Keep it simple. When building something from scratch, it can be challenging to identify the exact features your users need. By default, there's a tendency to include everything. However, it's important to truly listen to your users and take a phased approach, especially when multiple scenarios need to be addressed.