Design System Usage
#
OverviewAs part of our UX consolidation and front-end modernization strategy, our goal is to prioritize using our design system reusable components whenever possible. We have a decision tree to evaluate whether you should use it or not based on your specific use case.
#
Overall Value- Decrease design and development time with reusable web components.
- Reduce friction felt by our end-users by building consistent interactions across our products.
- Iteratively modernize our legacy product.
- Faster to market / faster release cadence for RQ features.
#
Design System Decision Tree#
Web in RQ- Once the interaction is in RQ, we can release updates independently (from full RQ releases) allowing us to iterate based on analytics/feedback and be more agile.
- We are iterating on experience consistency and modernizing our front-end technology.
- We are able to gather more analytics and insights of the user flows (Google Analytics and Sentry.)
#
Use when- The interaction is reusable in multiple places within RQ (adding a product to something, email/print receipt modal in orders and invoices etc.)
- The interaction may be updated regularly with enhancements/new features.
- We are taking an iterative approach because we don't fully understand how users interact with the feature when we don't have/can't get enough data.
#
Do not when- The interaction will block a sales rep from “tendering a sale” if there is an unexpected problem.
#
Web#
Use when- Building a new hub app.
- Building a new stand alone app.
- When modernizing a V1 or V2 app.
- When we are able to integrate React into an existing V1 app without fully rewriting it.
#
Do not use when- We are unable to integrate React into an existing V1 app and the feature is small enough that it does not make sense to rewrite the app.
#
RQMobile- Ensure consistentcy by following behavior patterns. We do not currently have native IOS or Android reusable components in our design system.