“People want to interact with technology less in their life, not more. They don’t want an extra thing to look at, to check, to operate.”
Evan Sullivan ’13
Long before he became a human-machine interface designer doing R&D on autonomous vehicles at Honda, before he was a successful app designer, before he was a computer-obsessed adolescent, Evan Sullivan ’13 was a baby on a UCLA Medical Center operating table getting a liver transplant. That intervention saved his life and forged his lifelong connection to the university, where he attended as a student at the UCLA Lab School and later earned his bachelor’s degree. Now, as a designer of technology interfaces for people to use intuitively, he traces his career back to a fateful student job at UCLA.
You literally grew up at UCLA, but you almost didn’t attend college there. What lured you back?
After high school I wanted to be a cinematographer, so I enrolled in a small film school out in the [San Fernando] Valley. About halfway through that program, I attended a reunion for the liver transplant program at UCLA. While I was walking around on campus, I felt such a strong draw back to UCLA, like it was somewhere I was meant to be. The next day, I dropped out of film school and re-enrolled in community college to transfer to UCLA. I worked my butt off for two years trying to get straight A’s, and [after those] two years, I got into the philosophy department at UCLA.
How did studying philosophy lead to working in tech?
I spent a lot of my childhood building my own computers and tinkering with them, and when I got to UCLA, I took a student position in IT support. While I was there, they were redesigning the website through which users would submit help tickets. Having never designed anything before, I jumped in and put together a mock-up of a potential design. I showed it to my bosses, and they said, “Yeah, that looks really good, but we’ve already developed the other version, so we don’t have budget to build a new design.” That was kind of a bummer. But over the next three weeks, I looked around on the Internet and learned how to put together a website. So I coded up this design and took the fully coded version back to my bosses, and they said, “Well, if this is fully built, let’s go live with it. Why not?”
Why put all that unpaid time into a project that had already been completed?
At the IT group, you’re helping users with software problems and computer problems, and I saw a lot of users having problems [because] the software was designed in a way that didn’t really make sense. What I really cared about was addressing the root cause of the issues.
How did you explore that interest?
While I was at that IT job at UCLA, I was actually biking to work every day, and I wondered if I needed to wear sunscreen. I looked on the app store for an easy, well-designed app to check the risk of sunburn, and I couldn’t find anything. So, high off my success of doing the website redesign, I thought maybe I could build a sunburn risk app myself. Over the next year or so — again, just going online and reading tutorials — I pieced together the Sun Risk application and submitted it to Apple.
And your little app then becomes an unexpected hit. What doors has that opened?
Sun Risk reached the top 14 on the paid weather app charts. I guess that caught the attention of Honda, who reached out to me and asked if I wanted to join them doing interface design in their research group. Of course I said yes; that sounded like a pretty cool gig. So for the past two years, I’ve worked at Honda doing research and development in interface design within the car. We were looking at what the in-car experience was going to look like in five or 10 years — a lot of things involving autonomy, the Internet and computing within the car. And more recently, I’ve jumped over to working on the production of apps that let you remotely control your car and schedule service and stuff like that.
How has this changed the way you think about how humans interact with technology?
People want to interact with technology less in their life, not more. They don’t want an extra thing to look at, to check, to operate. The key is how do you make this new technology that enables you to do more things without also requiring more of your time and attention.
It sometimes seems that so much technology has been created because it could be, rather than because it’s actually needed.
I’ve always found it’s better to design from the humble aspiration of just trying to solve someone’s simple problem, rather than trying to be the next phenomenal app.
With potentially tens of millions of people using any given technology, how do you design to accommodate such a huge diversity of users?
That’s one of the biggest challenges of design in general. The most important thing is to focus on what the diversity in your user group is. Any product is pretty much going to be built one way. You can support different languages and disability needs, like color blindness, and that’s all very important, but at the end of the day, your product is going to be a pretty specific thing. One of the best ways to make sure it works for a lot of different people is to talk to a lot of different people who will actually be users of your product, and let them test the product before you solidify your design decisions.
Any dream projects in the works?
A dream would be to try to tackle some really big software, such as health care–facing software or some of these more complex business systems, because there really is a need there. So often, the most frustrating software you encounter is already within some of the most frustrating contexts in life, whether you’re doing taxes or you’re sick and you’re trying to deal with medical bills.That’s the last time you want to deal with a frustrating or poorly designed interface. You can really make an impact on people’s lives if you can improve those experiences even just a bit.
If you can make doing taxes easier or even enjoyable, I will buy that software.
I’ll get right on it.