As the UX/UI distinguished engineer at Discover Financial Services, Lise Noble is charged with helping Discover employees identify ways to employ best practices for user experience (UX) and user interface (UI). Using design thinking practices, Lise and her team evangelize these good UX/UI practices and reexamine the way that Discover designs, develops, and manages interfaces.
In this Q&A, Lise answers questions about the intersection of design, accessibility, and open source.
What is the scope of your UX/UI work at Discover?
It's so broad! UX/UI affects internal Discover employees as well as our customers. Of course, most people think of UX/UI in terms of websites and other digital assets like email and PowerPoint. But it also extends to non-digital, physical assets like paper bills or credit card statements—all of these can be improved with UX/UI best practices. My job is to help teams adopt these best practices, and we often do that through design thinking.
What exactly is design thinking? When do you encourage teams to use it?
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 underlining problem that needs to be solved. Design thinking ensures that you are solving the right problem for the right people.
Design thinking 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.
Can you tell me about a project where you’ve been able to use these different skills?
It's actually the open-source project that we're working on right now called Theme Builder. The project is design-related, but we got input using design thinking methods from designers, engineers, business development folks, and others.
It started as a small idea, but we were quickly able to go from concept to reality using both design thinking and open-source principles.
What problem were you trying to solve by creating this project?
When I was applying design thinking to the creation of our UI at Discover, I noticed 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.
This got me thinking: 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?
How does Theme Builder solve this problem?
These days, design languages are 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 shot. 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.
Theme Builder current outputs those changes in two distinct types of code—one is CSS and one is JSON. JSON helps you render a whole digital library and CSS renders your whole digital library. Now you have two reusable artifacts: One for the designers, one for engineers.
Essentially, Theme Builder is using the benefits of atomic design and incorporating it into the development tool chain.
How do you envision Theme Builder being used to increase accessibility?
It goes back to the problem we were originally trying to solve: How do we make our applications and web properties more accessible from the beginning of the development process and in a way that changes can be quickly implemented? How can we ensure that design, engineering, and accessibility all have equal representation when building digital or physical properties?
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. I can envision a world where a person who is dyslexic and has a tough time reading could change a setting that changes all the fonts and their user experience to use dyslexic font. 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.
What are some areas where collaborators can add value to the Theme Builder project?
There are so many opportunities for collaboration! We want to extend Theme Builder in numerous ways and think that inviting collaborators to contribute innovative ideas and designs and code will help us create an even more effective project.
We obviously would love help from designers to make the underlying design elements more accessible and to incorporate their experiences and perspectives into what we’re building. We’d love to have them use their experience with various design systems to inform how we build out Theme Builder.
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 we’d love help from engineers and developers to 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.
