How Designers and Engineers Collaborate to Build Accessible Public Services

A lot of hands touch each product and service that gets built at Code for America. From client research to marketing, everything we create goes through a collaborative process full of feedback loops, iteration, and countless Zoom meetings. We want to hone in on one particular part of that process today: the overlap in work between engineers and designers.

Recently, we sat down with Senior Product Designer Carlie Hundt and Software Engineer Alex Gonzalez, both on the Integrated Benefits team, to learn more about how they collaborate. Carlie and Alex have been working together on MNBenefits.mn.gov, a partnership between Code for America and Minnesota counties and tribal nations that allows residents of the state to apply for several public benefits in one easy application.

How does collaboration between design and engineering lead to better outcomes? 

Carlie: When I started at Code for America as a new product designer in 2019, I had never worked with an engineer before. I had heard stories from friends at other tech companies that engineers were isolated from other team members, so I had preconceived notions of what the relationship might look like. Lo and behold, two years later, engineers are some of the team members I meet and collaborate with most often. When I think about the sphere of influence around a product, designers and engineers are right there near the center—and that’s because we are assembling the look, feel, and functionality of it every day. 

Alex: That’s very true. Engineers like me write the backend code that operates the product, and designers build the frontend experience that people interact with. But as a team, we share the same mission: creating human-centered services. Working at the intersection of government and tech, we build services that affect people’s health and wellbeing. We want to prioritize their needs over potential technical or design challenges—but that can be hard with tight deadlines and a growing backlog. That’s why Carlie and I have been really intentional about the way we collaborate, so we can understand each other’s processes and re-center the client’s voice when we are met with tough product decisions. 

Carlie: One way that we collaborate well is by “pairing” on new designs. Alex will invite me to a Zoom meeting where I give specifications on a design and I watch him make changes live in the codebase. As a visual learner, seeing Alex edit his code side-by-side with my designs has been transformative to how I understand technical constraints and anticipate potential challenges.

Is learning each other’s work processes a key part of what makes this collaboration sustainable?

Alex: Absolutely. Carlie hosts Design Office Hours, a space in which she shows her work to the team. It’s in various stages of completion, and she does it to receive constructive critiques and give us engineers a heads up on what she’s hearing from the qualitative research team about client needs. Hearing her ideas early gives me a window into her decision-making process, especially with regards to how it’s shaped by user feedback across channels—like usability testing, text surveys, and live chat. She’s even convinced me to volunteer to be a notetaker on a few client interviews, too. Those experiences have helped me understand how feedback gets integrated into designs and why she advocates for certain changes. 

Carlie: Thanks, Alex. I really do appreciate having you take notes. I’m counting on you signing up for a few more shifts this fall!

Alex: You got it. I would encourage every engineer to do the same—you learn a lot by stepping out of the codebase and talking directly with the people who are using the service. We recently implemented a new design Carlie came up with that changed the way we handle the home address section of MNbenefits, our service that allows Minnesota residents to apply for multiple benefits at once. Our conversations with people who use the product revealed that some of our applicants who are experiencing homelessness or living in temporary shelters were not able to complete our application because it required a permanent address. That’s a big deal, because those are the same people who probably need that assistance the most. 

Carlie: It was tricky because we were working within the state’s constraints that require all applicants to provide a physical address; paper mail is the county’s primary mode of communication and being able to receive mail is often a prerequisite for benefits. So, the design question became: How might we extend benefit access to the nearly 8,000 people who are currently experiencing homelessness in Minnesota, while also meeting the state’s address requirements? 

Why is it so challenging to expand a government service like this to people without a permanent address?

Alex: It sounds simple, but implementing this enhancement was actually fairly complex. Our solution gives applicants the option to either provide a friend or family member’s address, or to be pointed to a USPS General Delivery mailbox near them. By seeing this idea when it was in the early prototype stage, the engineers were able to consider and discuss the complexities involved early in the process. In this case, we had to figure out a way to point the applicant to the USPS General Delivery mailbox nearest to them, so we needed to compile a list of all mailboxes in the counties we were serving, then create a routing logic based on locations. Having early discussions around these complexities allowed us to come to the best solution from both the engineering and client experience perspectives, all while centering the people using our service who are facing hardship.

How else are you thinking about accessibility for people who use MNBenefits?

Carlie: In the design world, the most commonly talked about marker of accessibility is ensuring access for people with visual impairments—so things like being mindful of fonts, colors, and placement. We wanted to go beyond that. On MNbenefits, our goal is to increase access to benefits for all Minnesotans—but especially for folks who are marginalized, like non-English speakers, members of tribal nations, and people with disabilities. Often these are the same groups that could benefit a lot from assistance, so we have to ensure that anything we build is accessible, easily understood, and meets them where they are. This focus is pretty unique in the technology space—where other organizations that build technology products may see these as “edge cases,” we see these as opportunities to make sure our product can be used by as many people as possible. There are no edge cases when it comes to building accessible products.

Alex: We know from a 2011 study by the US Department of Health and Human Services that one in three working-age adults has a disability. The same study also tells us that 65% of Americans with disabilities participate in one or more social safety net programs—so we really need to make sure the tech we build for public benefit programs is accessible to people with disabilities. This also highlights the need to account for different types of disabilities, as some may be mobility based, while others may be cognitive, auditory, or visual. As a developer, I see this as a pretty awesome opportunity to contribute to a robust codebase that can be used widely, across devices, by the largest possible number of people. It has also been shown that building accessibility into a codebase improves overall usability, code quality, search engine performance, and more. By centering the real people using our application, we can build truly accessible, inclusive products. There’s no better judge of a good engineer than the people who use their product. 

It seems like one of the biggest impacts an engineering/design collaboration can have is making sure feedback from people using the product gets integrated back into the structure of the product itself. Why is closing that loop so important to accessibility?

Carlie: We can’t even begin to design an inclusive and accessible product unless we listen first—that’s the baseline. It’s imperative for all of us in the technology space to understand the breadth and depth of accessibility. That’s why we are open-sourcing the accessibility checklist we created for MNBenefits.mn.gov, which includes everything from checking to ensure colors meet Web Content Accessibility Guidelines contrast standards to making sure that we use descriptive language in our links and heading (such as ‘Contact us’ instead of ‘Click here’).

Alex: Working at Code for America, accessibility is ingrained into our process because we are designing digital public services that need to work for everyone. When we’re implementing new features, like for people without a permanent address, accessibility means that we prioritize building the service in a way that will not restrict the user base. We define accessibility as a core attribute to our product, and inclusion as a method to achieving it. This basic principle guided us in our work on MNBenefits.mn.gov to build a responsive and mobile-first browser experience (based on data that more than 60% of our visitors were mobile users) and eliminate the need to create and maintain login accounts. Our collaboration has unearthed just how extensive the term “accessibility” really is. 

How has this collaboration changed your view of working across disciplines?

Alex: Something I’ve found really interesting in working with Carlie as a designer has been the realization that our disciplines share similar interests. As a developer, I want to compartmentalize logic into generic and reusable pieces of code—basically creating building blocks—so my team can iterate at a faster pace. I notice the same process from a design perspective with the desire to create reusable design components which not only allow for faster iteration on designs, but also create visual consistency and branding. I think this comes together really powerfully through Honeycrisp, our internal design system, because it’s a marriage of this thinking from both sides: the design and the code. The system not only has a repository of HTML that we can repurpose, but also a lot of design components that have been vetted for accessibility and are ready to use. It allows for accessibility to be baked in from both sides, from the design of the user interface components to the code that goes into making those UI components accessible. Reusable components will also be a key piece of how we’ll expand our work in the future.

Carlie: We took some of our inspiration for Honeycrisp from Gov.uk, which pioneered the accessible design system. What’s unique about our system is that it ties together three things: designing of elements, coding of elements, and then the user research that backs up these elements as ones that have met a high standard for both usability and accessibility. Honeycrisp is basically the embodiment of the collaboration between design and engineering.

What advice do you have for other designers and engineers who want to build collaborative work processes?

Alex: Engineers, don’t be afraid to drop in with the designers on your teams and vice versa! It’s important to work together to build UI components, tools, and even products that are reusable. This saves time for both designers and engineers, because we no longer need to reinvent the wheel from scratch each time we start a new project. It also means that we can quickly scale good ideas so more people have access to them. That’s what accessible services are—flexible and scalable. 

Carlie: My advice is to stay curious and lean into technical conversations about the product you’re designing! Opening up new channels of communication between engineers will change the way you think and create in the design process. And at the end of the day, stay true to the needs of the people who you serve.