We are all familiar with the Canvas by Instructure interface – for better or for worse. As students, we use it every day to check assignments, communicate with professors, and to submit assignments.
What’s the deal?
Canvas, as ubiquitous as it is, has inconsistent design choices, unclear text hierarchies, and ambiguous calls to action. Overall, the site reads as one that was built by a million different designers over the course of many years – a pastiche of impulse design decisions made on the fly. Our team set out to create a more consistent set of rules and components with our design system, so that future iterations of the platform will correct those inconsistencies we found.
Personal Contributions and Challenges
On a personal level, my role included making high level decisions about areas of focus for component design, trimming the proverbial fat of our documentation, and tailoring the storytelling structure for our pitch.
Our main challenge was the sheer breadth of the site itself. Canvas is full of nested web experiences with context specific tokens and components, so a major roadblock was figuring out which aspects were most important for us to focus our efforts. This challenge was echoed at every level – determining foundational tokens revealed similar levels of inconsistent, context specific use of color, typography, and function.
Our Process
To begin, we deconstructed the entire site. Yes, you read that right – we broke down every single page of the interface. It took a while, but provided us with extremely valuable insights on redundancies and areas in most need of our attention.
After completing this step, I became a bit skeptical of our site choice: did we bite off more than we could chew? Time would tell!
Once we deconstructed the pages individually, the team came together to assess the overlap, and combine it all into one inventory.
My earlier reservations about our choices were alleviated once our inventory was completed. Our overlap eliminated some of the excess, and I helped lead the effort to trim even more redundancies. I did so by assessing the functionality of each element we identified. For example, tables and certain lists within the system employed nearly identical design decisions, and so we treated them as one component.
At the same time as assessing the components themselves, we also took stock of the design tokens; specifically spacing, color, and typography. It’s no surprise that Canvas’s foundational tokens were all over the place.
To ameliorate the state of the color and spacing tokens, we decided on a simple, scalable system for each. Spacing would be broken down into vertical and horizontal dimensions, with specific pixel values that corresponded to each potential use-case.
We hit some bumps along the way of this process: our spacing theory did not quite translate to making pages fit together, and some of our colors were repetitive. My response was simple: let designers assess their needs, and just provide better standards – we kept the tokens as is, and in the documentation we made it clear that hierarchies should be instituted in the form of a grid system.
As for colors, we accepted the repetition as a necessary redundancy in order to maintain order.
Introducing… Palette!
Our tokens were defined and our components were outlined. All that remained was making the darn thing! With a divide and conquer approach, we split up component creation amongst our team members.
I was responsible for the table, tooltip, tab, and toggle components, which demonstrate our goal for simplicity and modularity.
A major issue we wanted to address was all of the inconsistency contained within the Canvas interface. Our system mitigates this by cutting the excess, creating versatile components, and providing clear documentation.
Reflections
If I were to do this project over again, I would choose a different site. Despite our best efforts, our system does not account for all of the edge cases within Canvas, and there was simply too much going on to give any one aspect full attention. What we ended up with definitely solved the problems we found, but there is still more solving to do! If I were to pick this back up again, I’d start by troubleshooting our components, and refining some of the token hierarchy.