The Role of Design in Open Source
By Lise Noble, Distinguished Engineer of UI/UX at Discover
Every customer deserves access to a high-quality digital experience on the web. It means someone with a disability experiencing web-based services, content and other digital products will have the same successful outcome as someone without a disability. As a UX/UI engineer at Discover, my team and I are charged with helping identify ways to employ best practices for user experience (UX) and user interface (UI). Using design thinking practices, we take UX/UI practices and re-examine the way that Discover designs, develops, and manages interfaces.
Design thinking
Design thinking refers to a series of methods that help you brainstorm and produce innovative solutions to your problems. The key to good design thinking is approaching it from a human-centric manner where you come to know your end users. Often, the problem that you start with is not the true underlying problem that needs to be solved. Design thinking ensures that you are solving the right problem for the right people. It is not just for creating interfaces or a visual design element — you can use design thinking for truly any problem that needs creative problem solving, whether developing processes, policies, and practices or tackling career questions or family issues.
Using design thinking we found that many teams were not finding accessibility issues until they were at the end of the development cycle when they were much harder to address. Some of the challenges are there are often gaps in the cascading style sheets (CSS) provided in design files, leaving the developer with more questions. Other times it’s unclear if an element in a design file is an existing component or a new component, so engineers often recode something previously coded. When designers find issues that require CSS styling edits, they are often labeled as cosmetic, not prioritized, and put in the backlog. As a result, designs are not as they were intended, and the design systems are not as consistent as they should or could be.
These findings led me to ask two questions: What if we could embed these accessible elements into the development cycle from the very beginning? What if designers could easily select accessible design elements that were easy to reuse and replicate?
Open source and design
Open source software is code that is designed to be publicly accessible — anyone can see, modify, and distribute the code as they see fit. With open source, designers and developers can improve the user experience for all. And while most designers aren’t aware there is an opportunity to contribute to open source, at Discover we are working to change that.
Discover’s first open source project — Theme Builder
Design languages are often created using an atomic design system. This type of system starts with the smallest elements of design that you can’t break down any smaller — things like colors, fonts, and grid systems. In this system, we call these atoms.
You can put those things together to create a molecule. In this instance, a molecule is a button that uses the color and shape (atoms). After molecules, you create organisms. An example of an organism is a digital card that has a title, a button, an icon and maybe a beveled edge or drop shadow. The next is a template, a series of components put together, and then you start creating pages from those templates.
So, you start building small, repeatable elements that can be combined and grow in complexity.
If a component is changed in one place — for instance, to make it more accessible — the change gets rolled across all the components, both in the design library and in the digital component library. Theme Builder currently outputs those changes in two distinct types of code — one is CSS and one is JSON. JSON helps you render a whole a design library and CSS renders Mui, React components. Now you have three reusable artifacts, all aligned: One for the designers, two for engineers — a CSS library and a Mui React component library.
Theme Builder enables us to make accessibility changes to the underlying design atoms or molecules and have those accessible changes automatically rolled out to all digital properties that use those design elements. In addition, Theme Builder assures the components and their styling are applied in context of the background they are used on to assure accessibility is maintained. Utilizing this technology, I can envision a world where a person who is dyslexic could change a setting that changes all the fonts and their user experience to use a font that was designed to support people with dyslexia. In addition, we could increase the line height and color contrast to improve the usability based on their cognitive needs. The user could also select to see their paper bill in a way that is inclusive of their dyslexia and Theme Builder would make that easy to implement across all digital or physical entities.
Developers and engineers can get involved in helping to build and scale the capabilities of the tool. For instance, right now our tool rallies around Figma as the design system source, but with help from more engineers and developers we can expand and extend into different tools. What if you could export it into PowerPoint or into Xcode? The possibilities are endless, so there’s much room for collaboration.
