.png)
Overview / A full stack development project I got to work on as part of my internship @ResQ
Tech stack / React, TypeScript, GraphQL, Python
Role / Full stack developer on a team of 3 other Developers, a Designer and a Product Manager
Timeline / 1 month
Status/ Shipped š
%201.png){kind=small}
ResQ provides Repair &Ā Maintenance services to restaurants so they work closely with Service Partners who can provide the best possible services to those restaurants.
Previously, every time a new Service Partner would need to be added to ResQ's system, the Operations team would have to manually call them in to get the relevant information so they can build their profile. If they couldn't get a hold of them, their profile would still get built with the whatever information was available. This worked for the time being but it created data discrepancy in the system. Having inaccurate or incomplete information meant that as ResQ was moving towards automation, wrong Service Partners could be scheduled for service which would have a direct impact on the business value that ResQ was aiming to provide.
How might we build a solution that would allow Service Partner's profiles to be built with the most accurate information and require the least amount of manual work from the Operations team?
āConsistency:Ā Ensure a consistent way to collect the most accurate data from each Service Partner
ā
Empowering Users:Ā To truly make them Service "Partners" of the business, we want to empower them so they have full control over their own business's information.
ā
Require minimal manual work:Ā Enable a new go-to-market strategy by providing a simple and scalable solution to any Service Partner with minimal ResQ involvement.
A Self-Serve Onboarding flow that would be built on top of the existing Partner Management Centre that the Partners currently use. Each Service Partner who would be interested in working with ResQ would get an invite link sent to them where they can create their own profile by logging in and going through the flow to fill out the most accurate and up-to-date information.
The end goal for this project was a fairly complex flow with lots of dynamic sections of information to it. However, to deploy the first version of the Onboarding as fast as possible and get Service Partners to start using it, we only aimed to implement the core parts of the flow in the first few sprint.
The core steps were narrowed down to the following:
ā
Terms of Service
General Info
Service Categories
Dispatch Info
Rates
To make each "step" as re-usable and modular as possible, I used React's component-based system and Material UI's component library and its APIs. The intention behind modularity was because I planned on re-using the same components across multiple products in the near future.
One of the main components IĀ developed was a re-usable Category selection module which was built using Material UI's Chip component. The same Chips were also used to build the Dispatch module
To ensure a consistent styling system across multiple features and products, I followed the following design guidelines:
The same components were then re-used in two more instances
Bridging the gap between Design &Ā Development
ā
Working with a design system on Figma was cool and so was building small modular components and watching them come together. However, to make this entire process even more efficient, I would build those "reusable" components and then move them to a shared UIĀ Component Library such as Storybook.
This would help front-end developers reuse components but and also easily interact with multiple states of the same component without building them out first. It could also help designers explore how the components are actually modularized in the code and they can further build their design system based on top of that.
