PROJECT
Creating a Design System and Crafting Branding for Quorum Programming Language
Introduction
At Data11y, I’ve worked on consumer products to help design and build a system of accessible tools for programming. As a UX Designer, the majority of my focus was to craft a design system for the Quorum Programming Language.
My Role
As the Lead UX Designer, I was responsible for developing and researching solutions to provide accessible designs from Code.org’s adapted AP Computer Science Principles Course and YouCubed’s adapted course. I lead major design decisions when it came to redesigning existing products with Quorum, crafting a Design System to set design standards, and collaborated with software engineers to develop new libraries in the Quorum Programming Language.
Company Goals
Create ready to use widgets in Quorum for high school students to use in Canvas for the Maryland State Department of Education for the Data Science and CSP Courses
Make widgets that have a look and feel of “friendliness” and “ease of usage” when it comes to redesigning current and future widgets with Quorum Branding
Research and implement features to enhance these widgets
Accomplishments
Provided consistent and reliable branding to the Quorum Programming Language by creating a Design System to provide ease of use among high schoolers and teachers in the state of Maryland
Improved the usability of app creation by establishing a new library in the Quorum Programming Language
Provided assistance in writing clear curriculum for the AP Computer Science Course
A solution to solve the lack of design inconsistencies was to establish a foundational Design System and implement this Design System with new and existing products.
The Brewin’ Stage: Early Work that Inspired the Design System
Before the thought of a Design System, my first task was to take a look at existing widgets made by the company prior and see if there was any design changes I could think of to make it look more professional. Essentially, I was asked to solely do UI design enhancements.
One of the major redesigns that needed to be reworked was the Integrated Development Environment (IDE, a code editor with a compiler). I needed to see what I was working with and essentially, the work was a blank canvas. The company was all for a completely new design to the IDE and not to stay tethered to the old look. Before diving in, I made some observations about what currently existed in Quorum to determine my initial design decisions.
Taking the colors that I have seen from the website, I opted to brighten them overall to make the products pop. I took the main blue Quorum had on various thumbnails and worked my way to create a color palette in that means. I also established a few greys to create variation of greys in between the standard white and black. In terms of components, what was crucial was creating some basic buttons, fields, and finding consistent icons I can use throughout many projects within the company. All of this work would result as a mini “UI Kit” that helped inspire the main design system with my future work.
What was important was thinking about the longevity of these UI components and consider the use cases for each one. I already knew I had to redesign an IDE, therefore considering different buttons on mobile and desktop was one of the important features and if including icons give more visual clarity on a button vs not. I needed to consider the many students who would be using these products and have these components be more familiar to them so they do not feel as frustrated when they were using canvas.
The IDE helped pave the way to what many other Quorum widgets would look like, thus bringing the need to create an overall Design System for the company. Similar to many modern IDEs such as VSCode or Repl.it has a much similar use case where students can seek a familiarity from these products and can trust the reliability of the embedded Quorum IDEs.
In terms of the future of my work, this meant that designing products would be more effective and consistent for Quorums brand and produce high quality and fast designs.
This demonstrates the overall process when creating the IDE. I conducted benchmarking research on products that feature an IDE. From there I crafted various layout concepts for the IDE and settled on “Layout 5” for the design and through there, wire-framed mid fidelity designs to get an idea of what final icons and could be on the IDE. This was the point where I did eventually create the mini-UI kit I mentioned previously. In the end, 3 deliverables were:
Dark Mode version of IDE + Mobile version
Light Mode version of IDE + Mobile version
High Contrast version of IDE + Mobile version
It was decided to work on 3 different color modes as the design system was in the process of being constructed to accommodate all students preferences while using these technologies on Canvas.
How I Would Work with Design Constraints
Being a sole designer leads to challenges while I work because I thrive off of learning and collaboration with my team. What I found difficult from time to time was that many of my designs were green flagged to go straight into development. While there was discussion, it went on for about a day and then it went straight to hand off my deliverables to the developer. I questioned myself: Is this design ready? As a response, while I was in the designing, to help with my sole designer struggles:
I would get feedback externally — Friends or family provided immediate feedback on layouts that worked better than others
Research — Seeing how other companies structure and build their design systems gives me a guideline and some inspiration on building my own work
Work directly with my developer — Sometimes I need to know the constraints of the project and what can my developer successfully recreate in a final design. My developer was also my 2nd pair of eyes and questioned items that may not make sense when tokeninzing the design system
The Design System in the Works
The design system was a crucial part in the success of widget creation and website refinement for Quorum.
The Challenges Before the Design System
Having to copy and paste the same components and slightly adjust them to each widget wasted more time designing than having a single place to import all components. Therefore, working solely on the design system was a lengthy task as previously:
We had no standard to what components looked like
We continuously had to recreate old components
To reach company goals, building a Design System was important to standardize visual elements. This would also help my developer tokenize these UI elements to help make developing easier and readable. This foundational design system was organized using Brad Frost’s Atomic Design Methodology. This was to help differentiate smaller UI elements such as color or typography to larger UI elements such as an image card that ingests these smaller elements.
The Design System Style Guide
In the style guide documentation, it includes:
In-page annotations (how document and layout each component within the library)
Usage states on components (to show interaction with users on a page or widget)
Playground (shows how the component should act for development)
Branding (Grid styles, spacing, typography, and colors)
The Design System in Practice
All widgets using Quorum followed the Design System standards. These widgets and tools included:
Access Charts - A chart creator that allows students to upload CSVs and generate graphs
Flippy Do - A Binary number visualizer
Color Visualizer - An image detection tool to distinguish the RGB values from people’s faces
Pixel Widget - Another tool to practice binary numbers though color and black and white squares
DataCommons Tool - An integrated tool to look up data and create your own CSV files from the DataCommon’s database
The Cipher Solver - A tool to practice caesar cipher and random substitution for students to solve
The Quorum Language Website - The official Quorum website is now branded using the Design System
Building a Website with a Design System
To tie the widgets together with the newly established Quorum Design System, it was only a matter of time to redesign the website to have all products follow within the same guidelines. For my tasks, I used the existing design system to replace old UI elements and modernize the website, comparable to many other programming language websites.
Stages of remaking the homepage of Quorum Language
Stages of remaking the learn page of Quorum Language
With all products setting a standard with each other, it was more obvious to the user what Quorum is and how it caters to be a friendly and accessible programming language.
What I’ve learned as a Designer
Drawbacks are totally normal —
When I was working on developing curriculum for the company such as content and templates for the Computer Science Course, we were about halfway done with the course. Mid-July came up where we had a review session and many of the teachers wanted more from the material. On that day, it was clear the entire course had to be redone. Moving forward, I made more careful decisions on writing content that is simple enough to explain to students and take an iterative approach to how the course needed to be designed for Students.
Always seek Feedback —
Feedback is such a goldmine in information because it helps you improve. Sometimes people have no feedback at all (meaning I’ve done a good job) but sometimes I’m met with tons of feedback and suggestions. It’s hard to be stuck in your bubble in a design for so long and I forget to step back and ask: Is this completing the task required? In any case, always try to seek feedback from your designs and don’t be afraid if you have to rethink it. It might just give you a new avenue to explore more innovative ideas.
Think About Your Programmer —
At Data11y, I also helped program some of the tools used for the course as well as helped implement my own design on the website. It is important that you are clear and concise with what you want the programmer to implement. Remember that over the top fancy interactions may not translate as well to the real deal. Designers and Programmers should work hand in hand in the development stage because they can often learn from one another. A Designer can help their Developer watch for the small details and a Developer can help their designer find a balance between what can and cannot be done.