Design through the eyes of a UX engineer
Author: Hope Tambala, Senior Software Engineer — Design Systems
What led me to UX engineering
I remember looking at paper health records in a house without electricity by candlelight one evening.
My host dad (a military physician who was incredibly smart and committed to the health of his patients) asked me to help him organize some of his patients’ records for some vaccine deliveries he needed to do the next day. As a Peace Corps volunteer, you go into many situations during your service where you’re just dumbfounded by the situations you find yourself in. Some are funny, and some are a bit wild. Being in a remote community in the Dominican Republic in pitch darkness, with vital health information (on paper) on an unstable table lit by a candle, is definitely on the latter end.
Before I was an engineer, I worked as a Peace Corps volunteer (an agency/program of the United States government that trains and deploys volunteers to provide international development assistance). During the two years I served, I worked with marginalized communities to teach families about balanced nutrition, inform teenagers about sexual health, and implement systems to address environmental health challenges. Working closely with these communities inspired my passion for health, but working with healthcare professionals in these settings inspired my passion for design and technology. Seeing a capable and passionate physician working with dozens of paper health records late into the night made me realize that there has to be a better way to organize all of this. This particular story has a happy ending; my host dad successfully distributed vaccines to 20 people in 3 communities the next day, and I raised money to buy him a rechargeable lamp. If only all solutions could be this simple.
One fast fix here led to another quick bug squashed there. Suddenly, I realized I loved thinking and working on design from an engineering perspective.
Of course, I’m very late to the health information technology game. Still, as an impressionable young adult a year out of college, I’m glad I found that spark and desire for health and technology during my service because it led me to my work here at Cityblock, tackling health challenges with technology. My experience ties so closely to the mission of Cityblock, where we’re designing innovative ways to help healthcare professionals deliver care at scale to marginalized populations. My specific role as a UX engineer is an exciting role where I solve Cityblock’s design challenges with code as a software engineer.
I joined Cityblock first as a product engineer, working on full-stack solutions for our care delivery. It was impactful work with a fantastic team. It made me appreciate our product teams’ culture of diversity and clever problem-solving. Through my product engineering work, I noticed a few areas for improvement in our design system documentation, tooling, and codebase. One fast fix here led to another quick bug squashed there. Suddenly, I realized I loved thinking and working on design from an engineering perspective. I quickly joined the UX team after that.
One of my first tasks as a UX engineer was to develop a “job description” for the kind of work I should be doing. It was a challenging process. I entered this position assuming I’d be doing similar work to the design-focused bug squashing I was doing before, but I soon realized how much bigger my role is, being in-between two important cogs in our technical organization: engineers and designers. At times, it’s challenging to come up with the next steps for our design systems development. There are so many resources about understanding how to build design systems from scratch but very little on how to help it mature.
How the role is evolving
The best advice I received was from a veteran in the design system space who took the time to hear me ramble about my challenges in defining the next steps for our system. Having worked as a UX engineer and now a UX engineering manager, she bluntly said to stop thinking about what a UX engineer is supposed to do and start thinking about what your organization needs. “Don’t look externally for that information; look internally. Stop comparing your design system’s work to others. Find pain points, talk to stakeholders, validate, and ask repeatedly, ‘Is this the problem I should be solving’ and keep doing this until…well, forever.”
So titles don’t necessarily help us improve our system; people’s skill sets do.
After internalizing this advice, I began to better understand what Cityblock engineers and designers need, and my role evolved. The challenge of helping designers and engineers was always the same; however, my process of pinpointing high-impact opportunities improved. Understanding where the work of the design system ends and where product teams’ work begins was necessary; otherwise, I’d be running around trying to touch every feature and make little impact. Evangelizing my existence (something I didn’t imagine myself as an engineer having to do very often) allowed others to know that we had a design system and we had someone in charge of it. This also really helped with prioritizing what was necessary to do. Engineers and designers started coming to me with meaningful, impactful ideas for work rather than me having to come up with ideas out of the ether.
What do I consider myself to be
Am I an engineer with design thinking principles or a designer who codes?
It doesn’t matter (is that a cop-out answer?). For a long time, I thought the distinction mattered. Still, the longer I worked on our design system, managing its improvement, and facilitating others to do the same, I realized that having too many labels (keywords too many) for all of our design systems maintainers (designers, engineers, directors, or managers) was counter-productive. I use code to tackle design problems primarily in the same environment our engineers tackle business problems. Designers use their design experience to knock out design problems in Figma. Product engineers propose improvements to our system via demos of how our system can solve their business problems. So titles don’t necessarily help us improve our system; people’s skill sets do.
Through many of my earlier growing pains as a UX Engineer, it took me a while to understand that I manage an internal tool/product. The concept of component libraries in codebases isn’t new, but treating it as this larger product that has “customers” is (relatively). In addition, design systems are blowing up in the tech industry, with the number of open-source libraries snowballing. So I had a decent amount of resources to copy and learn from to understand how to think about Cityblock’s system.
A question that I often ask myself is, “Who am I building for?” I thought it was a simple question, but once I dug into it, I realized that I’m managing a system that has two groups’ interests in mind: 1) developers/designers and 2) Cityblock’s technology users (our staff). I’m helping the first group help the second group.
Day-to-Day
Being part of a small but impactful design team and an engineering team of one for our design system, I put several hats on here. Some light product management duties include evangelizing our design system’s usefulness, road mapping improvements to the system, and validating decisions. As an engineer, I have tech lead-like responsibilities like thinking about the technical vision of the design system (frequently reaching out to other senior engineers throughout the organization for their advice) and leading scrum activities like standups, retrospectives, or sprint planning. And frequently, I’m brought into conversations to provide design feedback to engineering work or discuss technical capabilities to enable our designers.
she bluntly said to stop thinking about what a UX engineer is supposed to do and start thinking about what your organization needs.
You can easily miss the forest for the trees in this role. I sometimes find myself caught up in the details, and I sometimes lose focus on the bigger picture. Nailing the perfect way to restructure a page in our product can get in the way of actually doing the work (or bringing others in to help out). Balancing priorities and delegating work is a growth area for me. Leading efforts can be as impactful (often better, actually) as doing the work yourself. Making sure the day-to-day work adds up to meaningful long-term impact is an area I’m excited to continue figuring out!
Understanding what our product teams do, their domain or business mandate, and how they work has made it easier to prioritize what our design system should be doing and how I should partner with them. I’m currently the only engineer on the UX team, and it can be challenging to embed myself in multiple product teams as a collaborative partner in the early stages of their projects. But, we’ve been lucky to have so many internal volunteers and partners for some of our current work. It will be exciting to see how our team will grow and work on more considerable systematic front-end challenges.
What are we excited about figuring out?
Early in my work here, I primarily focused on improving and standardizing smaller elements of our UI (buttons, checkboxes, and radios). Recently we’ve been working to enhance the user experience and accessibility of some larger parts of our UI in our core product to ensure they consistently meet our high standards. Thinking through some challenges like “How should we scale our design system across different products like Electronic Health Records (EHRs)?” or “How can we deliver consistent experiences across our products’ most important and complex features? “ is pretty energizing. My team is excited to dig into high-impact design system problems that will make it easier for developers and designers to create new features and improve the experience for our users, who in turn, manage the complex needs of our members. It’s been quite the journey from organizing paper records in candlelit rooms for marginalized communities, to revolutionizing the user experiences of care management tools in the Medicaid and Medicare space.
You can learn more about Cityblock at www.cityblock.com
For Cityblock career opportunities, please visit cityblock.com/careers
