Why edX needs a design system
The Paragon component library used by all microfrontend applications today has no corresponding design source of truth. A lack of patterns and confusion around what patterns exist slows down both designers and engineers. The design team is committed to creating a design patterns and using them in the design process moving forward.
A survey of several team members across product, design and engineering highlight these challenges and others that slow us down or result in inconsistent user experiences:
We don’t have a robust set of patterns or components. This costs edX time, promotes inconsistency, and hinders visual quality (and in turn perceived brand value or trustworthiness). | |
“...often i’m in need of conducting ad-hoc/mini competitive analysis of a particular component to better understand all the variations that exist on our site in order to determine whether a. i’ll need to design something completely net-new or b. reuse an excavated component as is, or c. make a slight tweak to improve the desirability/usability/accessibility” “lack of more robust pattern library hinders me from delivering work that looks more cohesive as a whole on our website” | “Would like to get away from good-enough and have patterns and libraries that i can use to build interfaces with the vis designer and plan the handoff work with them would be awesome.” “There are always a lot of edge cases/error cases/loading screens and things that we gradually add as we notice they’re missing.” “I almost want some sort of checklist” |
The patterns we do have are out of date or slow to evolve. This results in long standing bugs or in teams building their own (potentially similar) components. | |
“Another thing that slows me down is when a Paragon component isn’t up to date/using our best practices.” “Paragon in general isn't as well supported as I think it should be. Theres a few bugs within components that have been unaddressed for a while.” | “Managing different versions of paragon in different repositories [slows me down].” “Paragon components [are] great, but the feature set on that library evolves slowly.” |
Documentation of existing platform behavior is hard to find. It makes our product difficult for us to understand and slows us down. | |
Regarding existing business logic: “There’s usually none or very little documentation existing so I often rely on my checkins with [a PM]” “Documentation is not easy to find” | “Due diligence in tracking down previous work that may exist on the feature from UX or others in the organization [slows me down]” |
There is some duplication of work. This results in inconsistent user experiences and wasted effort. | |
“I feel like … minimizing duplication … is not our default position at edx.” “[I duplicate work] all the time. Less so now ... but a lot of the designs that matched b2c were the same thing redone for the enterprise branding.” | “We duplicate the effort and use case, but we may not actually duplicate the pattern” “Course cards, dates/time display format, messages (information vs alert vs warning), header/footer on student portals, learner dash, and program progress page - they are similar, but may contain different context specific information there.” |
It’s difficult to keep versions of the Paragon library up-to-date. This makes it difficult to switch between projects and slows us down. | |
“One problem I've run into is across different frontend projects are different architectures (ie learner portal/enterprise portals are built differently from say the account settings page). Although they use the same tools (pretty much talking about redux here) there are still some pretty hard line differences.” | “Figuring out if the paragon component can be used in my code base [slows me down]” “Managing different version of paragon in different repositories. Managing different MFE environments [slows me down].” |