As part of our commitment to improving the accessibility and usability of Guru, we have a dedicated design system “pod” that focuses on creating consistent, accessible, and beautiful experiences across Guru. Today, we’re sharing an interview with the leaders of that pod to provide a look into their thoughtful and deliberate process of creating a great design system.
Thanks for joining us today! To start, can you share a little about yourself and your role at Guru?
Homer: My name is Homer Gaines, and I am a certified accessibility specialist who has been working in the accessibility space since 2001. Now, I’m the Staff UI Engineer at Guru, leading the Design System team.
Jake: I’m Jake Sauer, and I’m the Lead Product Designer on the Design System and Search teams. I’ve been with Guru for a little over four years and have been in product design for about a decade.
What brought you to the design system team at Guru?
Homer: I’d worked with some of Guru’s engineering leaders before and held a similar role where I focused on accessibility and helped build the design system. When they came to Guru, they brought me over to help set up the design system and get Guru up to speed from an accessibility standpoint.
Jake: I was the second product designer at Guru, and we didn’t have any semblance of a design system at the time. In my second year, we were looking to re-do the hierarchy of our product, which led me to build out the first honest attempt at a short-lived design system (I even called it “SAGE,” which is what our new design system is called).
At the time, it was only adopted by designers—we never thought of it as a holistic system that would be useful to engineering and design. When we stood up the design system working group again last year, I was the natural candidate for design lead.
Can you share some of the goals of the design system team and the goals of the design system at Guru?
Jake: Designers can typically move faster than engineers when it comes to prototyping and ideation, but it still requires a lot of upfront building. So my goal is that the design system allows designers to think less about the components of the UI and more about the user’s experience, which helps with the velocity of iteration.
Also, I was historically the single source of truth on design system patterns, so other designers would have to come to me for questions about styles of buttons, text, etc.
I didn’t want to be the “shoulder tap” for the answer—I wanted to build out a system that would empower all designers to make decisions for themselves, keeping the best user experience in mind.
Homer: And for engineers, our goal is to have the design system create parity between the engineering and design teams. This increases the confidence of our designers because they know that when they’re building a new experience, they’re pulling from pre-vetted, accessible components that already exist in the product.
This also gives the engineer that ends up building the project similar confidence because they know they’re working with elements that already exist in the product. They can easily go “grab” those components from the SAGE library, rather than needing to build them out from the ground up, which improves speed and efficiency.
It also ensures consistency with our brand voice—when you use a design system, the whole application looks like one cohesive product, even if it’s built by several different teams. You want to create a seamless experience that feels consistent across all pages of the product.
Lastly, the design system allows us to bake in our accessibility needs right within the components. We can be sure our code has correct semantic markup, has been tested for screen readers and keyboard inputs, and that components are focusable when needed.
We have one single source of truth that ensures the integrity of these features, and we can be confident that our quality won’t degrade over time.
What are the benefits of having a design system in place?
Homer: The design system improves the employee experience for designers and engineers. It increases collaboration and confidence between the team that we’re building consistent and accessible experiences.
Jake: The design system increases consistency, clarity of use, reusability, and ultimately, flexibility within the guidelines. It’s really important to have accessibility baked into every experience. Now that we’ve shored up Guru to meet the current design system, it allows us to iterate and improve more quickly because we can update components across the whole app.
Homer: Yes, the designer experience is key. It’s one thing for the designers and engineers to just grab components and put them into the interface and call it a “feature,” but the design system explains the why behind how all of these experiences are built.
It also impacts usability across both paths: usability for those who are abeled and usability for those who are disabled. For example, assistive chat works completely differently than someone using a mouse, so we need to be cognizant of how the design system works with different forms of assistive technology.
What are the impacts of not having a design system in place?
Homer: CONFUSION!
Jake: Yes, confusion! There’s also sometimes a “shiny object” mentality with designers that leads them to want to completely rebuild experiences they’re unhappy with.
The design system takes away some of that flexibility, which doesn’t actually hinder the designer—it frees and challenges them to think, “how can I combine these components and UX patterns to create what I do want to build?” It takes away the guesswork of “do we have a button that looks like this already?” or “what do we call these types of users?”
Homer: Without a design system, you run into situations where developers end up building out two sections of an application with similar features and functions that are coded entirely differently. This makes it hard to maintain the code–a test that passes for one section could completely fail for the other.
The design system also allows the engineers to worry less about the presentation layer because it’s already taken care of for them within each component. Without it, you’d have to track down every area of the application that feels similar every time you want to make a stylistic change.
The power in the design system is how it cascades: If we make a change to a button in the design system, it’s automatically changed everywhere that button lives throughout the application.
Jake: Something unique about Guru is how tightly our Product Managers, UX Designers, and Engineers work. In some organizations, designers will end up “tossing designs over the wall” for engineers to pick up, making it much harder any time designs need to be updated. With a design system, the engineers don’t have to worry about tracking down designers if something is a pixel off-center. Instead, they can be confident that by using design system components, everything will be correct.
Can you share your perspectives on where we are regarding the usability and accessibility of our product?
Homer: From a usability perspective, we’re in a much better spot than where we were a few years ago, simply because the UI is becoming more unified. We still have a long way to go, but we’ve taken our “first pass” to shore up most of the most confusing parts of our application. Now, we can go back and make those fine tweaks that make all the difference.
When I say “usability,” I also mean accessibility because usability should be for all of our users.
Jake: I agree. I think we’ve come a long way thanks to the design system and the usability project we recently completed. One of the best things about our design system is that it’s made our designers more cognizant of how important accessibility is—we’ve moved away from picking colors because they’re “pretty” or designing experiences that are just “cool,” and now take time to assess accessibility from the onset.
Homer: We’ve also come a long way in terms of in-app copywriting (microcopy). We link out to Guru Cards that detail our microcopy standards right within the design system, which helps everyone make sure in-app copy is accessible.
Can you both share your vision for the design system team and accessibility at Guru?
Homer: My vision for the team is to be the central hub for design and development documentation and usability of every area of the app. I see us maintaining standards for global experiences across the app and working with partners across the company to make that happen.
Why is it important to build a highly usable product in our industry (knowledge management) specifically?
Homer: Roughly 10% of the global population has a disability. When we think about that, we usually think of physical disabilities—but the largest group of people with disabilities have cognitive disabilities, which you can’t see. There are 33 million people in the United States with a cognitive disability, and that can range from short-term memory loss to vision impairment. A lot of us work in the technology industry and feel the pain of experiences that aren’t designed with accessibility for all users in mind.
So if you think “oh, users with disabilities don’t use our application” because you can’t see them, that couldn’t be further from the truth. There are users with disabilities building those applications.
Jake: Our addressable market is really endless, and the thing we need to be thoughtful about is how our application supports not only current users but also people who may use us in the future. We need to think about how our navigation and hierarchy can remain flexible while being accessible to as many people as possible.
Homer: How many of us wear glasses? We have to think about how our tool interacts with magnification tools to support those users. And users of Guru have no age limit—everyone gets older, and we shouldn’t expect our users to stop using technology because of their demographic.
We have a tool that empowers everyone to document and share information in a way that’s actually accessible to their whole team. We’re seeing more and more users exploring Guru and asking how to author and share accessible content because they realize that it will affect everyone.
Our application isn’t only designed for power users; it’s for anyone who wants to be able to write up and share information across their organization. We’re giving them the power and freedom to do that.
Note: This interview has been edited for brevity and clarity.
As part of our commitment to improving the accessibility and usability of Guru, we have a dedicated design system “pod” that focuses on creating consistent, accessible, and beautiful experiences across Guru. Today, we’re sharing an interview with the leaders of that pod to provide a look into their thoughtful and deliberate process of creating a great design system.
Thanks for joining us today! To start, can you share a little about yourself and your role at Guru?
Homer: My name is Homer Gaines, and I am a certified accessibility specialist who has been working in the accessibility space since 2001. Now, I’m the Staff UI Engineer at Guru, leading the Design System team.
Jake: I’m Jake Sauer, and I’m the Lead Product Designer on the Design System and Search teams. I’ve been with Guru for a little over four years and have been in product design for about a decade.
What brought you to the design system team at Guru?
Homer: I’d worked with some of Guru’s engineering leaders before and held a similar role where I focused on accessibility and helped build the design system. When they came to Guru, they brought me over to help set up the design system and get Guru up to speed from an accessibility standpoint.
Jake: I was the second product designer at Guru, and we didn’t have any semblance of a design system at the time. In my second year, we were looking to re-do the hierarchy of our product, which led me to build out the first honest attempt at a short-lived design system (I even called it “SAGE,” which is what our new design system is called).
At the time, it was only adopted by designers—we never thought of it as a holistic system that would be useful to engineering and design. When we stood up the design system working group again last year, I was the natural candidate for design lead.
Can you share some of the goals of the design system team and the goals of the design system at Guru?
Jake: Designers can typically move faster than engineers when it comes to prototyping and ideation, but it still requires a lot of upfront building. So my goal is that the design system allows designers to think less about the components of the UI and more about the user’s experience, which helps with the velocity of iteration.
Also, I was historically the single source of truth on design system patterns, so other designers would have to come to me for questions about styles of buttons, text, etc.
I didn’t want to be the “shoulder tap” for the answer—I wanted to build out a system that would empower all designers to make decisions for themselves, keeping the best user experience in mind.
Homer: And for engineers, our goal is to have the design system create parity between the engineering and design teams. This increases the confidence of our designers because they know that when they’re building a new experience, they’re pulling from pre-vetted, accessible components that already exist in the product.
This also gives the engineer that ends up building the project similar confidence because they know they’re working with elements that already exist in the product. They can easily go “grab” those components from the SAGE library, rather than needing to build them out from the ground up, which improves speed and efficiency.
It also ensures consistency with our brand voice—when you use a design system, the whole application looks like one cohesive product, even if it’s built by several different teams. You want to create a seamless experience that feels consistent across all pages of the product.
Lastly, the design system allows us to bake in our accessibility needs right within the components. We can be sure our code has correct semantic markup, has been tested for screen readers and keyboard inputs, and that components are focusable when needed.
We have one single source of truth that ensures the integrity of these features, and we can be confident that our quality won’t degrade over time.
What are the benefits of having a design system in place?
Homer: The design system improves the employee experience for designers and engineers. It increases collaboration and confidence between the team that we’re building consistent and accessible experiences.
Jake: The design system increases consistency, clarity of use, reusability, and ultimately, flexibility within the guidelines. It’s really important to have accessibility baked into every experience. Now that we’ve shored up Guru to meet the current design system, it allows us to iterate and improve more quickly because we can update components across the whole app.
Homer: Yes, the designer experience is key. It’s one thing for the designers and engineers to just grab components and put them into the interface and call it a “feature,” but the design system explains the why behind how all of these experiences are built.
It also impacts usability across both paths: usability for those who are abeled and usability for those who are disabled. For example, assistive chat works completely differently than someone using a mouse, so we need to be cognizant of how the design system works with different forms of assistive technology.
What are the impacts of not having a design system in place?
Homer: CONFUSION!
Jake: Yes, confusion! There’s also sometimes a “shiny object” mentality with designers that leads them to want to completely rebuild experiences they’re unhappy with.
The design system takes away some of that flexibility, which doesn’t actually hinder the designer—it frees and challenges them to think, “how can I combine these components and UX patterns to create what I do want to build?” It takes away the guesswork of “do we have a button that looks like this already?” or “what do we call these types of users?”
Homer: Without a design system, you run into situations where developers end up building out two sections of an application with similar features and functions that are coded entirely differently. This makes it hard to maintain the code–a test that passes for one section could completely fail for the other.
The design system also allows the engineers to worry less about the presentation layer because it’s already taken care of for them within each component. Without it, you’d have to track down every area of the application that feels similar every time you want to make a stylistic change.
The power in the design system is how it cascades: If we make a change to a button in the design system, it’s automatically changed everywhere that button lives throughout the application.
Jake: Something unique about Guru is how tightly our Product Managers, UX Designers, and Engineers work. In some organizations, designers will end up “tossing designs over the wall” for engineers to pick up, making it much harder any time designs need to be updated. With a design system, the engineers don’t have to worry about tracking down designers if something is a pixel off-center. Instead, they can be confident that by using design system components, everything will be correct.
Can you share your perspectives on where we are regarding the usability and accessibility of our product?
Homer: From a usability perspective, we’re in a much better spot than where we were a few years ago, simply because the UI is becoming more unified. We still have a long way to go, but we’ve taken our “first pass” to shore up most of the most confusing parts of our application. Now, we can go back and make those fine tweaks that make all the difference.
When I say “usability,” I also mean accessibility because usability should be for all of our users.
Jake: I agree. I think we’ve come a long way thanks to the design system and the usability project we recently completed. One of the best things about our design system is that it’s made our designers more cognizant of how important accessibility is—we’ve moved away from picking colors because they’re “pretty” or designing experiences that are just “cool,” and now take time to assess accessibility from the onset.
Homer: We’ve also come a long way in terms of in-app copywriting (microcopy). We link out to Guru Cards that detail our microcopy standards right within the design system, which helps everyone make sure in-app copy is accessible.
Can you both share your vision for the design system team and accessibility at Guru?
Homer: My vision for the team is to be the central hub for design and development documentation and usability of every area of the app. I see us maintaining standards for global experiences across the app and working with partners across the company to make that happen.
Why is it important to build a highly usable product in our industry (knowledge management) specifically?
Homer: Roughly 10% of the global population has a disability. When we think about that, we usually think of physical disabilities—but the largest group of people with disabilities have cognitive disabilities, which you can’t see. There are 33 million people in the United States with a cognitive disability, and that can range from short-term memory loss to vision impairment. A lot of us work in the technology industry and feel the pain of experiences that aren’t designed with accessibility for all users in mind.
So if you think “oh, users with disabilities don’t use our application” because you can’t see them, that couldn’t be further from the truth. There are users with disabilities building those applications.
Jake: Our addressable market is really endless, and the thing we need to be thoughtful about is how our application supports not only current users but also people who may use us in the future. We need to think about how our navigation and hierarchy can remain flexible while being accessible to as many people as possible.
Homer: How many of us wear glasses? We have to think about how our tool interacts with magnification tools to support those users. And users of Guru have no age limit—everyone gets older, and we shouldn’t expect our users to stop using technology because of their demographic.
We have a tool that empowers everyone to document and share information in a way that’s actually accessible to their whole team. We’re seeing more and more users exploring Guru and asking how to author and share accessible content because they realize that it will affect everyone.
Our application isn’t only designed for power users; it’s for anyone who wants to be able to write up and share information across their organization. We’re giving them the power and freedom to do that.
Note: This interview has been edited for brevity and clarity.
Experience the power of the Guru platform firsthand – take our interactive product tour