UX/UI Design
Handshake
Overview
Code for Chicago is a volunteer-led digital consultancy that facilitates probono tech projects for not-for-profits and civic organizations. As a branch of Code for America, the team at Code for Chicago took on the challenge of creating a design system that would align all Code for America brigades on design best practices, accessibility standards, and CfA branding.
I was knee-deep with this team through the whole process — from defining problems to scoping down the work, executing visual design, building prototypes, and working with engineers to polish the final product. The team included three engineers, a product manager, and two designers (including me).
Note: Since my time at CfC, the org has separated from Code for America and is now known as Code312.
Role
UX/UI Design
Organization
Code for Chicago
Timeline
August 2022 – February 2023
User Problems
Onboarding new volunteers to the internal projects team requires a lot of effort to do it right. New developers will unknowingly create code bloat. New designers may deviate from the original design because no standards have been established. Additionally, a brigade's website often falls by the wayside when allocating bandwidth. In the past, Code for Chicago has prioritized partner projects over internal ones. Hence, while partner projects have prospered, it has been challenging to scale and grow our internal processes.
Measuring Success
Handshake is a collaborative tool that will be used to make our website and brand easy to build, manage, and scale. With so many volunteers working on it at the same time, this design system's goal is to reduce code bloat and ensure components and patterns remain consistent. We will measure if this is a successful tool based on:
Team adoption (measured through user interviews)
Handoff (measured through developer interviews)
Onboarding (measured by the time it takes a new volunteer to start contributing to a project)
Product scalability (measured by the number of website updates)
Organization scalability (measured by the number of new partners)
Original design file (i.e. chaos)
The Process
Executing this project began with an abundance of research — looking at existing examples, understanding what makes for a good design system and what to avoid. After we concluded our research and felt like we could see a solid path forward, we began to get organized. We took stock of every component we currently used on the CfC website (i.e. we conducted an interface inventory). This proved that we had a nightmare on our hands when we uncovered inconsistent fonts and spacing all over the place. At this point we decided to take this opportunity to redesign the whole dang thing, from typeface to card patterns.
Design Foundations
First things first, we decided on Source Sans Pro as our typeface since it is a versatile font with many weights, can be used in all caps, character width is average, and allows for a reasonable amount of characters per line. We set font sizes for mobile and desktop.
To determine our color palette going forward, we began with the colors of the Chicago flag and created tints as needed from there.
Components
We followed the principles of atomic design in this project, so the next step was to build components with the design foundations we had set. This was the biggest lift of the whole project and I was responsible for redesigning a vast majority of the components we would use going forward. Here are a few examples.
Patterns
After we got every component refreshed and pixel-perfect, we arranged them into commonly used page patterns (eg. content sections, headers, and footers). The content section is the workhorse that drives the page and communicates ideas. A lot of thought went into the cognitive load of these sections and there were times we went back and adjusted components that just weren't working.
Final Figma file
Documentation
The final task after months of design work was writing usage guidelines to provide a better understanding of our patterns and structure so that designers and developers can easily create and replicate designs. I did an abundance of research on this stage of the process alone, learning how best to display documentation, pulling from great examples like Material Design, Spectrum, and Carbon. Our design system is now hosted on GitBook and has been passed off to developers to work on the code reference.
Key Takeaways
Throughout this project, I grew by leaps and bounds as a designer. It pushed me to carefully balance usability, accessibility, aesthetics, AND the needs of the organization. It also showed me that the design process is not a linear path, but rather requires constant iteration. The phases of the process cycle back on themselves when new needs or use cases are discovered. If I could start over, one thing I would do differently is write documentation as we went along rather than at the end. This would have helped us to level set with the team and ensure we were all on the same page before moving on to the next step. For example, I would write all of the documentation for the design foundations before moving on to building components. Not to say it couldn't be changed later.
Handshake has already helped me to build designs in half the time as we redesign codeforchicago.org. Stay tuned for when our hard work finally goes live.
P.S.
We named our design system Handshake after the infamous Chicago Handshake.
(n.) A drink order comprised of a shot of Malört and an Old Style beer.
Let's get a round of Chicago Handshakes!
© Kathryn Lokar 2023