BLURB

Erin Murphy is a UX designer at Jane Street, and before that, she worked at NASA’s Jet Propulsion Laboratory building user interfaces for space missions. She’s also an illustrator with her own quarterly journal. In this episode, Erin and Ron discuss the challenge of doing user-centered design in an organization where experts are used to building tools for themselves. How do you bring a command-line interface to the web without making it worse for power users? They also discuss how beauty in design is more about utility than aesthetics; what Jane Street looks for in UX candidates; and how to help engineers discover what their users really want.

SUMMARY

Erin Murphy is a UX designer at Jane Street, and before that, she worked at NASA’s Jet Propulsion Laboratory building user interfaces for space missions. She’s also an illustrator with her own quarterly journal. In this episode, Erin and Ron discuss the challenge of doing user-centered design in an organization where experts are used to building tools for themselves. How do you bring a command-line interface to the web without making it worse for power users? They also discuss how beauty in design is more about utility than aesthetics; what Jane Street looks for in UX candidates; and how to help engineers discover what their users really want.

Some links to topics that came up in the discussion:

• Erin’s website that shows off her work.
• Her quarterly journal of sketches and observations.
• An article about Erin’s design work with NASA JPL.
• A paper that among other things talks about the user study work that Erin did at JPL.
• Jane Street’s current UX job opening.

TRANSCRIPT

00:00:03

Ron

Welcome to Signals and Threads, in-depth conversations about every layer of the tech stack. From Jane Street, I’m Ron Minsky. It’s my pleasure to introduce Erin Murphy, who’s a UX designer here at Jane Street. Erin does a lot of interesting work here and also has a really interesting and varied background. She’s worked at NASA’s Jet Propulsion Laboratory, which is not a place I knew hired UX designers. Worked as a design consultant on her own, founded her own independent design studio. She’s also a talented illustrator who has her own quarterly journal and has done a lot of exciting design work here. So, thanks for joining me.

00:00:35

Erin

Thank you so much for having me.

00:00:36

Ron

So, I just love the fact that you worked for the JPL. It ties deeply into some of the things that I think are interesting about the kind of UX projects we have here, because I imagine the JPL is a place that’s designing for experts of various kinds. And a lot of the design work, not quite all of it, but a lot of it here is also focused on various kinds of experts. Anyway, I’m just super curious, how did you get to the JPL?

00:01:00

Erin

I mean, I had the same thought, I think, when I was in school, that in my head, those who went to NASA’s Jet Propulsion Laboratory were engineers, they were scientists, they were roboticists. A designer was just something that did not seem like it fit into that sphere. And certainly, when I joined JPL, I feel in a lot of ways that I lucked out. There was an individual who was working there that really wanted to bring human-centered design thinking to the way that we design spacecraft and the way that we think about operating spacecraft. And it was an early enough stage where there were not as many design schools at the time that were focused on interaction design and user experience, which was the thing that I was studying in school. (00:01:41): And so, it happened that they reached out to the school. And at the time I was actually working with a professor at the University of Washington, who was really interested in thinking about how design principles – and thinking, how do you test and iterate on user interfaces with a person – how could that fit into more technical environments and not just consumer products? So, there was already some exposure that I was getting, just working with that professor and working on a project for cockpit designs with Boeing, where I was actually starting to see a similarity of creating storyboards, thinking about what a person is thinking about when they are navigating a digital system. That for me was like, oh, I see the way in. The way in was actually knowing the right individuals who are looking for that type of talent.

00:02:25

Ron

When you talk about this process of building and designing things with humans involved in that process, is that what you mean when you talk about human-centered design?

00:02:33

Erin

Yes. I think there is this, instead of just going off of the idea of what kind of thing we want to build out or thinking exclusively about the system itself, but actually talking with an individual, and interviewing them, and having a one-on-one chance to discuss what they’re trying to achieve with the tool, that’s what I typically find myself doing.

00:02:54

Ron

So, when you got to JPL, what were the actual kind of projects you were working on? How did JPL come around to thinking they needed someone to focus on design? You mentioned there was someone there who championed the idea, but in what kind of context, what kind of projects were being worked on?

00:03:07

Erin

I think one of the first projects that I was working on, actually, was to help scientists actually access orbital data from Earth orbiting missions. There was an interest in creating some web portal and doing it in a way where it’s not the standard, I guess, catalog that a lot of scientists were used to, where you didn’t have as much insight into maybe the metadata. It was a real laborious process to find the right kind of data. And you’d have to go to all sorts of different sites, or know the right kind of people who had that data available on some kind of USB or could send it to you directly on an email. And so, at the time, the very first project I had a chance to work on was trying to consolidate into one data portal, all of the Earth-based information that JPL was collecting and make it more accessible for a wider audience of researchers.

00:03:56

Ron

You said Earth-based data, is that geospatial information about the Earth itself, about the moon? What’s the data sets?

00:04:02

Erin

Yeah. Mostly Earth and specifically like CO₂ concentration and just understanding the composition of our atmosphere. And so there were different data products that were available to people. And we wanted to create a workflow and experience for people to know what level of data. There’s some processing that might go into the actual data itself, and we wanted to create a UI that displayed that level a lot more clearly. We wanted to organize it in a way that you knew exactly which satellite they were pulling data from or if there was an actual data center on Earth that was collecting information that they could then maybe compare against.

00:04:35

Ron

So, you wanted to surface, both the data and the provenance essentially of where the data came from?

00:04:39

Erin

Yeah, exactly.

00:04:40

Ron

What were the challenges in figuring out how to put this all together? As you sit down with scientists at JPL who are trying to do something, what were the things you learned that surprised you and informed the kind of work you were doing?

00:04:51

Erin

I think it was really hard to be a new designer and then also design for experts within a domain I had absolutely no familiarity with.

00:04:59

Ron

Wait, you hadn’t previously studied astrophysics before going to JPL? (laughs)

00:05:03

Erin

I really hadn’t. I think the most that I got from my experience in school that prepared me for this was probably working with a lot of the students within the engineering program, and just getting a sense of how they think about problems that are slightly different from designers. And the big takeaway from that is just how to ask questions and how to unpack an environment that I’m not familiar with. And I think that’s one of the sharpest tools that JPL really equipped me with as a designer, was to be comfortable in spaces where the domain is unclear or not as exactly relatable for someone like myself who’s not an expert. And then have the tools to just be interested and ask questions without any fear of looking silly or maybe asking something that seems too basic.

00:05:50

Erin

In retrospect, I think I can actually still go to this website for all this orbital data. But to go back and look at the design now, it’s a pretty, I think, straightforward problem space that I would do totally differently. But in addition to trying to think about, “How do we make sense of all the data products that a scientist would want to have access to and might want to look through and use for their research? How do you build a tool?” And that was just something at that time in my career I just did not have a lot of insight into. And so, it was a lot of just giving it a try, asking a lot of questions. I did a lot of interviews with different scientists.

00:06:27

Erin

From what I remember, there was this convention where all these scientists who were studying the Earth’s atmosphere actually came to kind of like a conference local to JPL at the Caltech School. And I was able to just sit in the crowd, not really understanding what was going on in the presentation slide deck, but I was able to take notes and follow up with people in that group and just introduce myself as a UX designer trying to create this sort of data portal. And there were a lot of very interested and happy participants who were willing to give me insight into their work. And I think it’s a thing that even beyond some of the Earth-based work that I was doing at JPL, once I started getting into more of the Mars Rover missions, that same level of how do you understand a domain and understand what a person’s trying to achieve within that domain.

00:07:14

Erin

The skills I was picking up from just talking with these researchers really translated well. And that’s, I think, something that – it’s really a key element to the way I do a lot of my design work at Jane Street as well – just really understanding what are people trying to do, what is their actual domain, and not being too afraid to dig into some of the technical details of that.

00:07:34

Ron

So you talked a lot about ways in which you learned in the process, which it seems like you’re really focused on yourself learning things, which seems really important. At the same time, I’m sure that when you go into a room, and sit with someone, and walk through how they access things, and you have maybe engineers who are working on the systems, they’re paying attention, I imagine they get surprised and learn things too. Do you have examples of the kinds of things that the colleagues you are working with learn from these interview processes?

00:07:57

Erin

I remember the feeling of having people get excited about storyboards. We’ve talked about this I think in the past a little bit, the idea of just being able to showcase what you as the designer sees as the experience of, say a rover planner or a scientist in their environment, looking at a very specific interface, reaching a breaking point or something that the tool isn’t serving them in their challenge and then coming up with some kind of solution in an actual new UI. I remember the storyboards just resonating, I guess, with that audience, because they just hadn’t thought about their process from that kind of perspective. You get these things called bedsheets, which are huge workflow diagrams that really just articulate how this system will be built out. And they’re really just a lot of boxes and arrows, and it’s very rich information that the designer should also be aware of. (00:08:49): But there’s this other layer on top of it of just like, well, how does a person navigate between these distributed systems? Do they have enough information on the page to feel confident that they’re navigating through that system efficiently? In the case of the scientists that were working on this, how does input from that team, what kind of science intent that they have, how will that actually move through the system? That’s a little bit abstract. And I can totally talk a little bit more in detail on that, but that seemed to be the thing that resonated with people. We weren’t just looking at boxes and arrows anymore. We were thinking about, “What is a person’s experience through those boxes and arrows?”

00:09:23

Ron

So for someone who’s never seen one before, what is a storyboard?

00:09:26

Erin

So, a storyboard typically looks like you have multi-panels that just highlight these significant events in a person’s workflow. So, the thing I was referring to is this idea of maybe a scientist who is working on a team that is trying to get data from the spacecraft. The storyboard could offer like, here are scientists that are able to use a particular tool to articulate what science they’d like to do that day. The next panel might show how that information goes to the rover planner to see if it’s even feasible to do. Can you actually drive to this location? Can you actually extend the arm to do this type of spectroscopy? And so, the storyboard is just outlining an actual panel, very much like a comic strip, essentially, that helps people envision what you are seeing as the day in the life of that scientist, in collaboration with the rover planner, in collaboration with the actual software tool.

00:10:19

Ron

What’s the workflow for you actually creating these comics, I guess? Is this like, you go and talk to them and get your sense of what the process is, and then you, on your own, go and draw it all out, and show it to them, and it’s your way of communicating to them what you’ve captured about what their workflows are like?

00:10:34

Erin

Essentially, yeah. I would say that there is this process of, when I’m learning about a new domain for the first time, being able to have a one-on-one conversation with a person and actually drawing in real time with them, is definitely a part of the process as well. And just being able to put into some tangible state what they’re saying so that I can reflect it back to them is my ultimate goal. Because what I want to do is actually just simulate what they’re doing, because a lot of these domains that I’ve worked within, they’re not entirely relatable experiences. I’m not an engineer and I’m not a rover planner, I’m not a scientist. Though, that would be cool. I’m none of these individuals. So, in order for me to feel like I have a good intuition and judgment around what they’re trying to do, I need to re-create that experience.

00:11:17

Ering

Storyboards for me help, because they are these visual aids that look like a comic strip. They tell a story that’s sequential. And it’s a really great communication tool for when I do go back and follow up with that person to just understand if I am following along with what they’re saying, and if it’s something I can continue to reference as I build out their system or as I design their system.

00:11:39

Ron

Are these storyboards actually always sequential? When I think about the user interface, there’s a certain “choose your own adventure” part of it. There are lots of different paths you can take and different things that you can do. Do you sometimes include that in the storyboards by having them fork and merge to illustrate different paths through the system?

00:11:54

Erin

Yes. And I think when I’m actually in the mode where I’m translating something that a person’s doing with maybe a series of tools and trying to consolidate into one nice succinct workflow, yeah, I’m definitely starting to branch out into, “You can go in so many different directions if you land on this one page.” But I’m super methodical and I tend to create very linear patterns for these things, so… Again, I’m often working with these complex workflows or there’s some elements to what an engineer is trying to do that I might not be as familiar with, so I do try to lay it out very linearly at first, but account for that kind of complexity over time.

00:12:31

Ron

So, in addition to being a designer, you’re also an illustrator. And it sounds like this actual physical process of drawing is a big part of how you approach the communication around it. How do you relate these two different parts of how you think? Are they just one whole, or are these two different skills that you mix together sometimes, but not always? How does that all fit?

00:12:48

Erin

That’s an interesting question. I think that it’s one whole, because I just don’t see them as different. I didn’t think that drawing was going to be this useful tool, I suppose, in my career. I assumed that when I originally went to school – I really wanted to be an architect. And that seemed like a complete one-to-one of the skills that I was passionate about and having a practical application of them. But I didn’t see that in some of the work that – especially in places like JPL or Jane Street, I didn’t see drawing as a tool that would be helpful, at least at that point in my career. I see it as a way of just reflecting back to people and showing tangible evidence that I understand something. I just need to see things. And that’s probably why I find myself as a designer… I think that a lot of times designers are offering the skills to bring what could be a future experience for someone or a future reality into the present, so that we can interrogate it and think about, well, is this actually going to be useful?

00:13:46

Erin

Should we test it with some people? Are there other ways we can do this? Sometimes I just need to be able to see what the future is, and drawing is my method for bringing that into a present state, where I can actually make sense of it. So, for me it’s like sense-making. It’s not even an artistic expression. It’s just that there’s a lot of things that I’m learning in these domains. And the best way to catch on to what I’m observing, what I’m hearing from conversations with engineers, what I’m seeing in just observing scientists that are looking at the recent download of data from a spacecraft – drawing makes that real to me in a lot of ways.

00:14:22

Ron

How universal is this? Do other designers who are also in the human-oriented design space… is doing this in a very drawing-focused way a common approach?

00:14:31

Erin

I would say that drawing unfortunately gets a bad rap. I think that there’s a lot of designers that I’ve spoken with personally that are very insecure about their drawing skills. And they don’t want that to be the thing that makes or breaks their design process, and I certainly don’t think that it is. That’s my chosen method and has been helpful for me. I tend to encourage everyone to draw, though. I think actually the more messy the drawing, the more honest it is. And just the more like, “I’m trying to be in this space where I don’t know what the answer is, but I need to create some signal for another person to help or another person to add their opinion.” So, I feel like it’s a very human method. I’ve seen it actually work quite well in these environments that aren’t entirely human. There’s engineers, there’s aerospace, there’s all these elements that don’t really seem all that relatable. But if you can create some drawings, you can create an understanding of what you’re doing, and connect more with your colleagues, and understand what they’re trying to achieve.

00:15:30

Ron

And to be fair, engineers do a lot of drawing too. There’s lots of people standing in front of whiteboards, trying to put up structures that represent things about designs and how systems fit together. I guess it tends to be less human-oriented. You’re drawing pictures of the human using the thing and we usually draw the thing.

00:15:45

Erin

Yes.

00:15:45

Ron

And also our drawing skills are less good.

00:15:47

Erin

There’s kind of like, layers, right? I think that it’s actually fun to draw with engineers, because they are often like, “Here’s the underlying system.” And I feel like I offer the layer on top of it, of, “If this is how we’ve built out the back end, and if this is how the data’s supposed to behave, then there’s this top layer of what a person’s going to see.” And that’s the part that I know is part of my lane and what I’m trying to understand. And it’s interesting to draw with people and I try to encourage my engineering colleagues to do that wherever we can.

00:16:15

Ron

So, you’ve had a really interesting and varied career as a designer. How’d you get here?

00:16:19

Erin

So, honestly, the way I got here, I hadn’t heard of Jane Street before. It is not something that-

00:16:25

Ron

We’re not really big in the design world? (laughs)

00:16:27

Erin

We’re not… yet. Not yet. I hadn’t actually heard that they were looking for a designer, but I did have a friend who knew someone who was working here. And she had told me, “Erin, there’s a place that you should probably consider working for, because there’s a lot of nerds that are trying to build out these really complex systems. It’s perfect.” And she was right.

00:16:45

Ron

(laughs)

00:16:46

Erin

(laughs) And so, I found out that they were trying to hire a UX designer. And I was really skeptical the entire time, to be honest. I just didn’t understand, what would a designer do at a quantitative trading firm or prop trading firm? The design space felt very foreign to me.

00:17:06

Erin

And so, I took on the interview, one, because I wanted to work with some people that were very smart and interested in making complex systems more manageable and useful. Certainly, that was one part of it. But I was also just curious. I wanted to know more about: what would a designer do in an environment that’s thinking about the dynamics of our economy? And what kind of products would those teams be building? And because I didn’t have words to describe it, even after researching it and just looking into what Jane Street is known for, that made me even more interested, that I was not wrapping my head entirely around what the firm was trying to do.

00:17:41

Erin

And I knew I needed to talk to people who were working there to demystify all of that. And so, I certainly used my interview to basically understand that. And in so doing, I met the team that I was on and really enjoyed the rapport, and the ways that they were envisioning bringing design into their work, and having a design culture.

00:17:59

Ron

So, now that you’ve gone through that process, can you articulate that a little more clearly? Why does Jane Street want to hire UX designers?

00:18:06

Erin

I think that we’re discovering that some of the older methods of building tools internally might not scale well into the future. And what I mean by that is, we want to have better integrated tools, and we want to have an experience for people where they don’t have to guess too much on what they’re doing when they land on a new internal tool. And I think that that does start with: how are multiple people using it, not just one engineer who created the tool and will maybe create some documentation, people can train up on it. Maybe that worked at a certain point of maturity in the firm, but – I don’t think that at any point people were not aware of the user experience. The more I work with engineers and see their process, I was really pleasantly surprised when I started that there was already an interest in following up with users, and there were dedicated channels to collect feedback from people in the moment. But there was this awareness that maybe they can do a better job.

00:19:02

Ron

And I think part of this is just a matter of scale. As you have more people, the leverage you get from really improving and tuning the interface that you provide people, just gets bigger and bigger. When I started at Jane Street, there were 35 people or something like that. Now there’s 2,600. And so, the amount of leverage that you get by making things simpler to use, simpler to discover is big. There’s also just way more stuff to learn. And so, having more of the things that you come across and need to use as part of your job, be really easy to pick up and use… When the firm was smaller, we just built much less stuff. So, you have a big complicated system with lots of interconnections between different teams and you want to keep the cross terms down, the amount that you pay for all of these extra connections.

00:19:43

Ron

You want to get value from all the things that people build without it being as much friction for people. You mentioned that people already cared about this kind of user experience question, which I think is right. But another aspect of it is, it’s not just about having someone who’s dedicated to it, but there’s a real expertise that comes in. And just understanding the approach, this whole idea of sitting down with end users and watching what they’re doing, is in some sense, just obvious that you should do it, but it also feels kind of silly and wasteful in time and stuff. And I think having talked to a bunch of people who’ve been through some of these processes with you, people are surprised by how much they learned through this and stuff that they thought was going to be super obvious. And of course, people will understand this. You look in actual life, what happens when people pick up the tool and realize, oh man, they’re holding it wrong. And I think that’s one of the values that comes from having people who’ve just done this before.

00:20:29

Erin

That was probably the very first month of Jane Street for me, not only learning about the domain itself and learning “What do traders actually do?” For the first project that I jumped into, there’s a tool that we’re using to ensure that we have the right settings for meetings, and you’re able to have the appropriate audio setting, and the appropriate video conferencing tool. And we’re using a separate open source tool that helps people have the preferred low-latency audio experience that they want. There was this effort to really sit down with people and actually watch them use this tool, encouraging them to create their own meeting and have me just shadow them as they go to a specific room, try and initiate their meeting from there, being able to see where in the UI did they get messed up or tripped on. What are the certain things on the UI that they felt like they were having issues in understanding? And seeing that in real time, documenting it, videotaping it, and then sharing it with the Engineering team was really insightful for them.

00:21:26

Ron

Yeah. And the whole thing of having a meeting, it seems like such a simple thing. We just want to go into a room and hit a button, and have a meeting, and have a meeting with some people who are here in the New York office, and some people who are in London, and maybe some people who are remote dialing in from their home office, and having that whole thing work. It’s not nearly as simple as it should be. And we did a bunch of work on our side. We have different requirements than the average user of Zoom, both in the size of the meetings, and the latency requirements, and the audio, and a bunch of other things, that mean that a lot of the external solutions just weren’t a really good match here.

00:22:01

Ron

And from my perspective, I feel like over the years as we built this out and worked on it, I got to really experience how this thing that should be simple kind of wasn’t. It was hard to get all the pieces to work. And there was a lot of careful thought and effort that happened over the course of years of machining that process down, and making it smoother, and simpler, until cute things like attaching things to the wall that you could scan with your phone, so that your phone could know what room you’re in and actually dial in the right meeting in the right place. Now it’s just delightful. I feel like on a regular basis, I walk in, I think, this stuff is so nice. I walk in, I hardly have to think. I hit a single button and it basically does the thing that I want. And the thing that can be lost between that relatively simple experience is how much work is required to make the thing actually simple.

00:22:48

Erin

Absolutely. I think that was the tricky thing for me when I started, which is: where do we need to simplify it? When I first saw the mobile UI, I had immediate assumptions on what were the things that needed to be improved. I think one of the things specifically was there were so many different ways that you could start your meeting. It wasn’t just one simple button, which we’ve evolved into now, or a very easy way to find other options. But at the time, everything on the UI was just the same hierarchy, and the same color and organization on the page. And for a person who had never done this before and was maybe used to some of these external tools, it was hard to know where they needed to start.

00:23:31

Erin

And it was hard to engage them in a way that they felt pretty confident that they were going to make it to a very important meeting or be able to have the ability to hear their colleagues and see them at the same time. And so, these things that do seem simple and have been resolved in the past are made. We are integrating a little bit of complexity with this kind of low latency tooling that fits for our very specific use case of allowing traders to feel like they’re actually on the same trading floor together. And to do that, it did require actually meeting with people and not just coming up with designs that were just adopting the same patterns that we had seen in other tools or have experienced with other tools.

00:24:09

Ron

So, I expect part of the process of doing all of this was teaching people within the team that you were working on how to approach these problems with a new set of intellectual tools. And I’m curious, how did that go? There’s a lot of teaching people how to do new things, convincing them it’s worthwhile to spend time on this. And you’re coming into a domain where they already know how to build software or they feel like they know how to build these tools. What was the process like of getting the engineers around you to take part in a full way in this kind of design process?

00:24:36

Erin

I feel like I was lucky, because I feel like the engineers just recognized that there is a whole other dimension to their system that they maybe didn’t have as much expertise or experience building out, which is the UX. That’s something that comes at the end, from what I gather, for a lot of engineers, where it’s like, you think deeply about how the system should work, how it should function. And then, “Oh yeah, we should probably make a UI so that people can use it.” Now, that’s kind of like a gross oversimplification, but I think that it seemed as though, and from what I’ve experienced even elsewhere, knowing how to integrate that collaboration between building a functional product, but that also people want to use and find useful, is always something that we have to adapt and figure out as a team. I feel lucky, because I think people were very receptive to it. And they were very interested to know, “What do you need to do to make something more user-friendly?”

00:25:29

Erin

Yes, it was very much, oh, whenever we were presenting new features or we were identifying the tool for the conferencing, there were a lot of things on their roadmap that people were interested in building out – new functionality that they wanted to see. And through asking questions around like … Well, do people need this? Have you received a lot of insight from our help channels of people requesting this feature? What does the tool do now and how do people navigate through that today? We should maybe have some kind of insight into, “What are people doing?” before we actually assign any kind of priority on what we want to build out next… I felt like by asking those questions, that reminded the team that there’s going to be people using the tool who are not in this room and actively hearing some of our reasoning for adding this feature. Those people exist, and we should try and think about what they would want, is the first step, just like generating awareness of it.

00:26:22

Ron

In some sense, that all sounds like a much better experience than I would’ve expected.

00:26:28

Erin

One thing I could say, I think this is actually more recent, I’ve actually noticed that I’ve had to adapt some of my own research methods to the ways that we are building out these tools. So, I’m used to setting up these meetings with people where we can sit down and look at the tool together, and just go through a set of tasks and see in real time how they are able to use the latest build of our tool together. And I will take notes diligently on what it is that is breaking in the UI, what is not very understandable. I’m used to this very methodical process where you are sitting with a person in that moment. And what I’ve noticed in some of the projects that I’ve done recently is that those methods have worked. And there’s an interest in the Engineering team to continue those discussions, but they’ve actually wanted to have more discussions with users.

00:27:16

Erin

I’ve had to break out of some of my more methodical approaches to research and actually adapt some of the cultural elements of Jane Street into the research. And what I mean by that is going up to people in the moment and asking them like, “Oh, we’ve noticed that you logged in to this product. And I’m just kind of curious what your experience has been like.” And asking them in real time as they’re working through the latest build to talk about their methods, versus the more organized research efforts that I would do. It feels now like we’re actually trying to find even more lightweight ways to gather information as the person’s using the tool.

00:27:51

Ron

And how does that tie into what you see as the culture of the firm? Why culturally does that more ad hoc lightweight stuff seem more preferable?

00:27:57

Erin

It all depends, I guess also on the state of that product. I would say that. When we’re first building out something in its green field, it’s good to just meet with people one-on-one. But what I was noting with this cultural element is that there is this environment at Jane Street that I’ve noticed as I’m working through designing internal tools, where people are really receptive to communication and having these casual moments where we catch one another in the hall or we are able to stop by one another’s desk. I’m used to environments where it’s a little bit more formal in some ways, where you need to set up actual meetings or establish these very distinct points of communication. But I think that there’s actually an opportunity to learn even more about what people are doing when you’re able to see them in context, and actually meet with them and establish a relationship of who that person is, what they’re trying to do with the tool, and where they might be running into some kind of issue.

00:28:52

Erin

And I felt like that was more of a cultural thing. And it makes it almost even more approachable for designers to enter into this space. There’s this environment that’s actually quite welcoming to talking about the domain and showing what they’re trying to do with their software. Which I think ensures that a designer who’s coming completely from the outside is able to practice that domain, and learn the language, and feel empowered to connect with their end users. So, that’s a Jane Street experience that I’ve had and I’ve been wanting to adapt my approach to research around it.

00:29:25

Ron

It’s interesting. I think of that as a cultural thing, this very free flowing communication style, but it’s also a cultural thing that’s reinforced by architecture. The way we lay out the people is – we have these big trading floors with lots of people all pretty physically close to each other. And I think the reason we’ve wanted that from the beginning is all about communication, about making it really cheap to talk to someone who’s next to you. And I think that’s the thing that I’ve noticed over many years is that it’s really surprising how big of an effect small differences in ease of communication is to how people behave. We periodically reorganize where people sit and move groups around, and some of that’s because we have to. The firm is growing, you need to move things. And sometimes it’s just good to mix things up, because you move two groups closer to each other, and two other groups farther away, and it just changes the communication pattern in a really surprising way.

00:30:11

Erin

Oh, absolutely. Yeah. And there’s actually this new feature that we had added to our help Slack channel. There’s a channel that’s just alerting us when a person logs into the tool. And we get their username, and we can easily find where they are in the office, and we can go up and talk to them. One of the engineers on the team added a very rough estimation of how close they are to you. So, it’ll tell you, “Oh, this person’s right around the corner. This person is 54 meters away from you, or this person is two floors above you.” And so, I don’t know, even just knowing where they’re located and having an awareness of, “Oh, I just walked by,” there is a lot of connection you can build. And I feel like the design itself becomes just stronger by having that constant iteration that is informed by these discussions with real users.

00:30:57

Ron

So, tools for meetings are a good example of a tool that’s used very broadly. No one is an expert in having meetings. Sometimes I feel like I’m an expert in having meetings, but that’s my own problem. But there are lots of tools that we’re building that are tools that are really focused for experts. And in many ways I think a lot of what we need from the UX side of things is, like you were doing at Boeing, building cockpits. Building systems designed for people who are experts in the field that are often focused on presenting information in a really dense and efficient way, and pretty different from what you might expect from a consumer software kind of environment. Can you say a little bit more about some of the projects that you’ve worked on that are a little bit more in that space?

00:31:35

Erin

There’s a few projects that I’m working on. The one that I actually just mentioned, that has the ability to know who’s logged in is a tool called Blueprint, which is a tool that’s allowing people to manage and provision their applications in a more standard consolidated system. So, that’s one of the things that I’m designing for. Another is a tool called Appd, which is helping people basically run apps and jobs, like automated procedures that maintain the functionality of their systems. And then we have a lot of the observability work. So, we’re thinking about these distributed systems that we’re building out. And we want to have a solution internally that allows us to have better visibility into the performance across all of the different systems that your app might be interfacing with. Those are some of the main tools that are outside of the realm of relatable workflows.

00:32:26

Erin

I feel like there are experiences that I’ve had remotely that have been cumbersome with some of our own video conferencing tools. So, I can pull from that working schema of mine. But when it comes to things like, maybe automating a certain job or to run at a very specific time of the day, these experiences are outside of my realm of what I tend to do and what I do as a designer. And that does require interfacing a lot more with the actual engineers who are using the tools to understand what they’re trying to achieve and how the current systems are not serving their needs.

00:32:57

Ron

I think, actually, this has been a lot of how I think about the development of how we’ve built tools for people over time. Early on we were all able to rely on the fact that we’re essentially building tools for ourselves. You’d build a tool and you would use it and other people would use it, but you were always very close to the use case. And then as the organization grows and there’s a wider diversity of different kinds of things you need to do and there’s just more expertise in different corners, you end up designing things for people whose jobs aren’t that much like yours. That’s a whole different discipline of, “How do you figure out what some other person wants?” and you can’t anymore rely on the stuff that’s just in your head. It just changes everything dramatically.

00:33:32

Erin

Yeah, it definitely takes you out of your comfort zone, I suppose.

00:33:36

Ron

So, are there ways in which the designs and the principles behind the designs are different when you think about these, kind of, focused expert tools, versus when you think about building tools for more occasional casual use? I’m thinking a little bit about, I look out at consumer tools and there’s a certain sameness, I feel like, to lots of different broadly focused, of like – a certain airy prettiness and distance between the different UI components and stuff that shows up there. And it feels like there’s a set of things that people are optimizing for about stickiness and making it really easy for people to get into new things, that all feels very different from what you want to optimize for when you’re building a tool for someone who, every day they’re coming in and doing their job deeply integrated with this tool. How does that difference in goals affect the way the designs work out?

00:34:22

Erin

The airiness of our consumer products is definitely something that I’ve certainly designed systems around in the past. It is all about being very thoughtful about how you introduce information to the end user over the course of their full experience with a tool. It’s so different at a place where I’m working with people that are used to information-rich tools or things that are just you want to have an awareness of all the information you have access to all at one time. And I think the principles I’m still calibrating in a lot of ways. It has been a culture shock in a lot of ways to hear people say, like, “Oh, I actually want to see everything on my screen. This font is far too big.” Or, “I don’t like that there’s so much white space in this area. This actually makes me nervous. We could fill that with more information.”

00:35:11

Erin

That is a very common piece of feedback that I get. And a lot of individuals, when I come to them with a Figma prototype of potential direction that we might take, I have a lot of memories of some of my initial conversations with people just wanting to make things more compact, wanting to know, “Is there any more information that I could see for this state of this job or this app? I want to know what I have access to. And I’d also like it to be responsive, because I’m going to make it super small on my screen and push it off to the left-hand side of one of four monitors that I’m using. So, their environment is very different from what I think I would design for if I was creating an experience for an average consumer.

00:35:50

Ron

Yeah. It’s maybe worth painting a picture of what a typical workstation looks like here. There’s almost a bare human rights minimum. You have to have at least two monitors. Someone on a trading desk might have four or six, and people who are doing jobs that involve intense live monitoring of things typically have these monitors painted over with many little boxes. Each is a different view into a different system that they’re watching and there are all blinking lights and noises going on.

00:36:18

Erin

Lots of noises, infinite noises. Traders moved to our floor, and now I get to hear the cacophony of things happening. I’m always curious what they mean, but yeah.

00:36:28

Ron

And when I think of what are the prototypical user interfaces that people really dive into and use a lot, there are things like a spreadsheet, which is dense grids full of constantly changing numbers. There are text editors. People vary a little bit on exactly how intensely they feel this way, but certainly there are lots of people who are like, “Get rid of all the Chrome. I just want as many lines of code that I can get on my screen at the same time.” And then the other one is the terminal, where again, the terminal is simple and functional and lots of very dense presentation of data. And I love all of those things and I think they’re all very useful, but for a long time Jane Street operated, this whole web thing had never happened.

00:37:08

Erin

It just doesn’t exist.

00:37:09

Ron

That’s right. We didn’t know how to use it and we mostly didn’t try. And I think there’s a lot of virtues to the kind of tools that I was just talking about, but there are also profound limitations. At some point in our evolution, we had, I don’t know, 5 million lines of code in our code base, but not the ability to draw a straight line.

00:37:26

Erin

No. (laughs)

00:37:26

Ron

So, very limited ability to do visualizations, certainly in a programmatic way. And another way in which I think these user interfaces tend to be impoverished is, they’re not very good at providing you with help. Just the basic affordance of a tooltip is magic. It’s just like an incredibly simple and useful way to provide people information at the place exactly where they need it. I love Emacs, but it’s not good at that kind of thing. And so, in some sense, I think those affordances are why we cared so much about putting more and more stuff into web UIs as a way of delivering user interfaces. You also give something up. There’s something valuable about the spreadsheet and text editor, and terminal world. I’m kind of curious how you think about the trade-offs between those different ways of building experiences for end users. I know you are not primarily a command-line denizen.

00:38:20

Erin

No, but I feel like I’ve had more experience learning to navigate through the command line. The Appd tool is a command-line interface right now. The goal is to actually take what exists and turn it into a web experience that provides people better integration with other web applications that can help you build some context around, “Is your app functioning correctly?” That’s probably not a good description of it, but yeah, for me, I’m following you. Appd feels kind of like the tool that’s related to some of the trade-offs that we have to think about between a command line and a web experience.

00:38:52

Ron

So, one of the nice things about terminals as a way to surface UIs, is they give you very few choices, which is a weird thing to think is good. Isn’t it good to have more choices? But one of the nice things, especially inside of an organization that’s really bad on average at visual design, is that you can’t spend a lot of time deciding which font you want to use, and what is the size of the font, and what’s the width of the bevel. You have no choice of fonts and there is no bevel. You’re forced to only think about, “How am I going to put together this array of characters in order to get across the thing I want to get across?” And there’s a degree to which constraining the design space gets better things out the other end. I think if you give people who aren’t really good at free-range design web UIs, you’re going to get a lot of eye-bleeding bad designs that are confusing and hard to use.

00:39:43

Erin

What I’ve seen from some translation away from a CLI to the web experience is you just take the command line at the bottom and you bring it into a web experience, and that is just the one place that you go for navigation. Things just behave as if you were in a CLI, but you’re actually in a browser, in a web browser itself. That’s a way to go.

00:39:5

Ron

(laughs)

00:39:5

Erin

It’s not really taking full advantage, I guess, of some of the other things you can do.

00:40:05

Ron

I’ve definitely seen, I know we have some UIs that operate that way, and there are parts of that where I look and see, it’s like, I think that looks like a command line. I’m like, oh, now I feel comfortable.

00:40:14

Erin

Being able to just maintain your hands on the keyboard at all times is just like another user behavior, I suppose, that I’ve also just become a lot more cognizant of as I’m designing things. So, in addition to if you are finding yourself translating away from a command-line interface where you can really just navigate the entire thing through key bindings and just using your keyboard, being able to have a UI that’s a web UI, specifically, that has very clear direction on which key bindings you can use and an ease of use from the keyboard. It’s something that is now very much a part of my approach now or a set of principles, I suppose, that I refer back to as I design more experiences within Jane Street.

00:40:54

Erin

And I sometimes look back at even some of the things that I made in my first six months at the firm. And I’m aware now of how complicated they could potentially be for someone who’s just used to using their keyboard. I’m already starting to build a slightly more in-tune awareness around, “What does it mean to have a good user experience for this population of users?”

00:41:14

Ron

Right. And maybe it’s worth saying, the reason why we care so much about keyboard interfaces is because they’re just dramatically faster. You look at someone using a spreadsheet or an editor, they reach to touch their mouse and you want to slap their hand, it’s like, don’t do that, because it’s just so much lighter in the end. You get the set of sequences of keystrokes wired into your neurons and it just makes things go in a much smoother way. Again, for an expert, for someone who has been using the tool for a long time, they can be in that state of flow where they can just almost effortlessly move really quickly through the user interface. And that’s really great.

00:41:45

Erin

I think that’s one of the bigger challenges that I’ve had with working with a user community that predominantly works just on the keyboard is, how do you still translate that ease of use that they have right now with their command-line interfaces to a web application? There’s some things that are going to be completely different with the web UIs. But for the things that are standard, if you’re going to change the status of something, if there’s a set of actions that people are used to doing and they have the critical impact on your system, those need to behave in the way that they expect and that they’ve experienced already in their command-line interface.

00:42:24

Erin

I think the stakes are high when we’re trying to offer a web experience in lieu of a known command-line interface. Making sure that there is an accurate interpretation of what people actually need to take action on via their keyboard and making sure that’s reflected properly in the web UI is incredibly important. And if we don’t do it right, that just leads people to not want to adopt that tool. And so, I feel like there’s a lot of additional work that I feel I need to do in the very beginning stages to prioritize that translation of critical key binding to the web UI, so that there isn’t a drop-off of users from feeling like they’ll just continue to tolerate maybe a system that’s not scaling well to their evolving workflows and what they need as a team.

00:43:06

Ron

I feel like you would learn a lot about how people think about keyboard interfaces if you studied the three editors we support. There’s Vim, Emacs and VS Code, and each of them have dramatically different philosophies. It’s a very interesting space. The other thing that I think is interesting about the editor space, text editors in particular, are tools for experts by experts. These tools were designed in the ’70s, many of them, and in many ways aren’t that different from the original versions that were in the ’70s. I mean, they’ve grown in lots of ways, but a lot of the core idioms around which they’re built are preserved from those early designs. It was the opposite of human-oriented design or something. It was just some engineers who wanted something and they built the things that they wanted, and that is a different way of getting humans in the mix.

00:43:48

Ron

But there’s this interesting question of when you think about designing tools for experts. This whole thing of interviewing people and trying to understand their workflow seems very important, but at the same time, this expert insight into, “What are the workflows and how do you design ways of interacting that really match those workflows tightly,” one of the questions I’m interested in is how do we effectively integrate those two kinds of insights together to build really excellent tools for experts that both capture what’s unique about the domain, and also leverage these broader insights about how to design things?

00:44:17

Erin

I think about that as being one of the bigger challenges of my design career at Jane Street, for sure. I have an awareness that there are a lot of tools that we’ve been able to build out because enough people found existing systems to be problematic. And so, they just created a new one. Enough people have trained up on it, and enough people learned how to use the tool, and they’re content. And I think that for me, I know I’ll never be an engineer. I’ll never be a trader. That is not the scope of work that I can provide. But the big challenge for me is how can you actually still understand their domain enough to have that kind of intuition or build up a little bit more of that empathy around what these experts are experiencing.

00:45:03

Erin

I can’t say that I’ve figured out how to do that. I will say that the experiences I’ve had at JPL, this first year at Jane Street, it does feel like being immersed in that environment and having these conversations with people where I’m able to observe in real time what they’re actually doing and see exactly how they’re trying to integrate these different tools into their workflow. That’s the thing I’m most interested in learning more about.

00:45:30

Ron

Yeah, it’s hard stuff. So, you’ve obviously spent your time working on a bunch of concrete design projects, but another thing that you’re thinking about is how to build out design as a discipline here and growing that team. You are a UX designer here. You’re also currently the only UX designer here. And we’re actively looking to add more people to that team. And I’m curious, how are you thinking about this process of trying to find people? What do you think we should be looking for in finding people who would be a good match for these kinds of problems and would be excited about working here?

00:45:59

Erin

Yeah. We’re actively looking for another user experience designer that’s excited about learning about this particular domain, and has already the skillset and experience of building out and shipping products for people, and they’ve already started to use some of their designs. They have that experience of making decisions on a tool, putting it out into the world, and seeing what kind of response from their user community they can use to improve their system. So, I feel like the individuals that we’re looking for, we’re certainly interested in people with user experience design background, but we’re looking for a lot of designers who have demonstrated an ability to be in a domain that’s not as familiar. So, certainly, a number of people that we’ve had conversations with have had experience in the FinTech world. There are people who have maybe worked in aerospace. There’s a couple of individuals that I’ve spoken to that are familiar with robotics and are going through that same kind of process of, “How do you partner with experts to build complex tools?”

00:47:04

Ron

So, essentially, are you looking for people who’ve had the experience of building for people who are experts in things that they themselves are not experts in?

00:47:12

Erin

I would say so. We see a future where there’s actually a lot more diversity of designers from all sorts of different disciplines. I think that’s the ideal situation, is just to have a variety of perspectives to inform what people are trying to do, and build out designs in collaboration with our engineers and traders. But for now, we are looking to see if there are individuals who are able to jump into a really difficult and complex domain, and clarify what needs to get designed, and clarify exactly what the challenges are for people that are working on these types of tools.

00:47:46

Ron

So, that’s what you’re looking for in the people that you want to find. What do you think should make Jane Street an exciting place for a designer to come work at? What’s the unique opportunity here?

00:47:55

Erin

My sense is that you get to just go a lot deeper into what an experience is like for an individual who’s going to use your end product. I think that this is the one place where I’ve had the most latitude to just go up to individuals, talk with them about the tools that they’re working on, understand more on how tools that I’m designing for can be improved. And subsequently, I’ve just learned a lot about systems we’ve built out. And I found myself navigating through those systems on a command-line interface, which I never thought I would have to do in my career. I always thought that I would just live in this design research space and think at a high level on what things need to happen and never would I venture into the depths of how it was built out.

00:48:41

Erin

But in creating these relationships with my colleagues and learning what people actually need from their tools, I see it as this need for designers to go even deeper in their understanding of what they’re actually building. And there are times at other firms, other agencies, places that I’ve worked at in the past, where you don’t get that much collaboration with your engineering counterparts. And you do have to just live in this place in the product life cycle where you don’t really know how this thing is going to get built out and you just inform what a person would need. And I think that I’ve had much more exposure to this more holistic process of how we actually make a functional tool and what are some of the things that people will run into, what challenges people will run into with that new system.

00:49:25

Erin

I just feel like I have a lot more access to that than I have in any other place. And there’s almost a culture here that’s excited to help you navigate that space. Some of the things that I’ve done, especially like the command-line interface or learning a little bit more on how we architect these distributed systems, all of those things are pretty foreign and just outside of my scope of knowledge. But there are a lot of individuals here that are very happy to sit, and talk through that, and share their knowledge in a way that doesn’t feel at all judgmental and it doesn’t feel like it has this negative impact on their productivity. They see it as an opportunity to make another team member more informed of what they’re building, and in so doing, have a deeper empathy into what they can produce, what they can implement versus what are some of the things that we can’t do yet. I don’t have that kind of reach when I’m just a designer either working on my own thing or on some of these other past teams.

00:50:18

Ron

It sounds like to me there’s two things you’re pointing out here. One is you get a chance to go deep in the domain. So, if you’re the kind of person who really likes geeking out and understanding the details of stuff you wouldn’t normally get a chance to dig into, that’s an exciting thing. And the other thing is just highly collaborative with the Engineering team. You’re not making a design on the outside and saying, “Here are some specifications of things to do.” You’re working back and forth with the people who are building the system. On that latter point, I wonder how you even do it the other way. It seems really hard to design a thing where you’re not working closely with the Engineering team, because I feel like if you’re just designing what you want the thing to be, the world seems very wide open.

00:50:54

Ron

There’s lots of, “This is what the ideal user flow would look like.” There are lots of constraints about what’s easier and harder to do, and I feel like a lot of the art of designing great software is figuring out a thing which is simultaneously simple for the end user and also simple to implement. Simplicity is a profound value, both in design and in software engineering. Finding that middle point where you can be simple on both dimensions at once, I feel like requires a lot of collaboration and understanding. You said a lot of nice things about what it’s been like working here and doing design here, but what has been the hardest part of adapting to the kind of work we do here?

00:51:30

Erin

I think the hardest thing that I’ve had to deal with is maybe just accepting some of the limitations that I have as a person that’s not deeply embedded in a domain to the same degree as the end users that I’m designing for. I feel like I have experienced this in other very technical complex domains that I’ve worked with, but there is something about being in an environment at this point. This particular point in Jane Street is just interesting, because I feel like people are still used to creating tools when they need them, and having a shared knowledge across other engineers that they work with to just train up and use that tool. There’s sort of an ease to making sense of these domains, that I think for myself, it can actually be quite challenging.

00:52:18

Erin

I don’t write code, I don’t build out my prototypes I use. All of that is done for me in Figma. And I think that the hardest part for me is being in a world that’s transitioning away from what they’re used to, which is being able to spin up tools as they need, and then going towards a world that actually there’s holistic user experience for tools, and there’s an understanding that the end users have very different expectations for a web experience, and maybe sometimes even a preference to have a web experience over something like an existing CLI.

00:52:53

Ron

Although my hope is that we don’t totally give up on that flexibility of just spinning things up. We’ve been using command-line tools for a long time. I don’t expect that to actually stop. One of the things I think is one of the big, quite open challenges in building graphical user interfaces, is how do you share some of the benefits that you get from more traditional, more language-oriented tools? I think the thing that’s great about command-line tools is they’re organized around words rather than pictures. And there’s a kind of composability to language, a grammar that you have for how you can construct things. On the Unix command line, the nicest part of it is this pipe operator, the ability to run a bunch of commands and pipe output from one to the other.

00:53:35

Ron

And the whole system has been engineered so that there’s a standard way in which you represent data or a few standard ways in which you represent data. And it’s just easy and light and natural to take a bunch of different tools that were built, not necessarily explicitly to work with each other, but with a shared set of idioms and values. And then you can just put them all together and make something new in a pretty simple and pretty lightweight way. And there are limits to how well those user experiences work. You don’t get tooltips, but you get this profound composability. And I’d love to see a world where we had graphical user interfaces that retained some of that composability. And I don’t quite know how to do it. I think it’s actually a hard problem.

00:54:16

Ron

Something about having this linguistic aspect not be totally lost is something that I’d like to see there. And I don’t know. I’m curious if you’ve thought about this kind of composability question as you start stepping into tools like Blueprint and Appd that are more about connecting lots of technical pieces together, this kind of extensibility, how do you retain that?

00:54:34

Erin

I haven’t really thought as extensively about this. I guess the way that I approach building out these tools for Appd and Blueprint right now, is there are things that you can communicate through consistent navigation, consistent layout of a page, that can help a person make sense of the information in front of them graphically, without having to read through… Again, I don’t really use that much of these command-line interfaces, so I don’t entirely always know what it feels like to have something that you can actually read out and understand what the program is going to do. But there are certain patterns and elements of consistency that I’m trying to infuse in the designs that I’m building out for, not just like Appd and Blueprint, but even for some of the newer tools that we’re seeing emerge for some of our observability platform applications.

00:55:26

Erin

And I think that maybe that is the way of having some… I don’t know if you can really spin up things and have your own applications, but if people are trying to build out user interfaces or extend maybe from something that’s already been built out, there could be user patterns that we’ve already identified as being helpful and we’ve utilized across Appd and Blueprint, that maybe someone else could use for their own tooling and reuse, I guess. There is an interest in taking a lot of the design system work that we had done early on of creating these consistent components, consistent buttons, the right kind of coloring. And when you have a certain button state, there’s consistent states that you would see. All of that can actually be packaged up into something that can be reused. If you were interested in building out your own web application, ideally in the future, you would have all of these components ready for you to pull in and actually build out your experience.

00:56:25

Ron

Yeah, for sure. There’s some important composability that comes roughly at the level of widgets, where you build a widget that has not just the right visual presentation, but the right behavior baked into it in a way that you can then hook that into other pieces. And there’s a lot of work we’ve done on the web programming side to make that kind of component stuff really good. The thing that I feel like is hard to do is this cross-tool compatibility of like – you built a tool, and you built a tool, and you built a tool, and now you want to hook all those tools together. I’ve seen some patterns that I think work reasonably well. One of the things that some of the trading desks have done is they might have one tool that decides where their focus is, what’s the particular security that they’re paying attention to, and then maybe a bunch of other tools in the back end.

00:57:05

Ron

That tool will publish that information and the other tools can watch it, and then something changes. And all of your tools, even though they were implemented independently, will all change focus at the same time to pay attention to the new thing you’re doing. So, that’s one way of getting things to hook together. Another thing I feel like I’ve seen done, but I don’t know if I’ve ever seen it done well, is there are some kinds of tools where you try and have a dual life to the UI. So, there’s these cool dashboarding apps where you can click some buttons, and create some views, and create some buttons, and create some sources of data that pull different sources of data, and create a visualization that then people can watch and interact with.

00:57:39

Ron

And it’s a really easy way to get started up, but then you might want to be like, okay, but now what if I want to turn that into a textual representation that I can edit in a different way and commit to a source code repository? And so, having this dynamically constructed structure of the UI can live a double life, where you can flip it from a purely graphical specification into like, “Oh, yeah, here are the five components you have combined, here’s the definition of those components.” And then you could go in, edit and transform it, or even programmatically generate those. So, I feel like that’s a kind of thing, that you see little versions of that.

00:58:12

Ron

Another actually good example is you have all sorts of UIs for doing filtering. Your issue tracker or whatever has some way of filtering. And sometimes you can have something where there’s a SQL-like query language that lets you do it. And sometimes there are UIs where you can click buttons to say, filter down to this, filter down to that, or whatever. And one thing you can do is you can have the set of buttons that you do, could behind the scenes be constructing the SQL query that represents the filter, and then have this way of flipping back and forth between the two representations. So, you’re both a UX designer and an artist. And I’m curious, how do you think about the role of beauty in UX design?

00:58:51

Erin

Oh, God. (both laugh) I mean that’s probably the best response to it. I’m always trying to avoid the concept that the designer has come to the Engineering team and their role is to help make the UI pretty. I think that’s a shorthand for a lot of people that – it’s not entirely dismissive. I think that for people, “pretty” is actually a term that means it’s clear, it makes sense, it makes a person feel confident that they know what to do when they arrive at the landing page of an interface. I do sometimes feel like it’s also a shorthand for you as a designer can come in at the end and not have any insight into the domain and still do your job, I’m sure. You can come in at the end and put a nicer polish to everything and it will all work out. This is something that the designer doesn’t need to be embedded in any way into the thinking, and the functionality, and what this tool should do for a person.

00:59:53

Erin

And so, beauty has just been this really tricky element to my design process. I don’t think that this is the case for a lot of other designers. I’ve had conversations with people about the idea of making things “pretty” – that quote or that term – and it doesn’t seem to bother people as much. I think that for me, it just erases a very important element to the design process, where you can’t get to something that’s clear and beautiful without really understanding what it should be and having an awareness of the complexities of it. I don’t think that you can just be brought into building out a tool and just polish it. You need to actually understand the mechanics of what it is, what environment it exists within.

01:00:43

Ron

There’s almost something dismissive about talking about things being pretty, because it’s just like putting a fresh coat of paint on a thing.

01:00:48

Erin

And I think that it can really limit what you build out and the kind of collaboration you can really have with a person, like a designer who’s coming onto your team to codify what it is a person’s trying to do into something that we can actually interact with on a screen.

01:01:05

Ron

[inaudible]. But there’s something about picking the right clear and simple way of presenting data and presenting your options and doing it in a way that… I don’t know, something about the visual appeal does matter at a functional level. The way in which humans see and interact with things I think makes some kind of difference, but it’s complicated and very subjective, I think.

01:01:25

Erin

So subjective. I think that’s probably the thing that makes it hard a lot of the time for me to actually think about beauty as its own isolated thing when I am designing interfaces. There are patterns and best practices for color treatments and font sizes that you’ll see on a screen, but I very rarely am prioritizing it. It’s almost like I’ll just take those patterns that already exist and really put a lot more of my effort into making sure I’ve fully understood what people are trying to do and how you can use all those pieces to orchestrate that desired experience.

01:02:04

Ron

It’s not the primary thing that you’re thinking about?

01:02:04

Erin

It’s not even a compliment at times. A lot of people are always like, “Oh, wow, this interface is so much prettier now.” Or like, “Oh, I just really enjoy using this tool. It’s pretty.” If they don’t mention the usability part, that’s usually where I’m like, “Oh, you say it’s pretty, but tell me more about whether or not it’s actually helping you.” The problem that I’m most interested in is whether or not it’s actually useful and if it’s actually something that people care about incorporating into their day-to-day work. For me, that would be the beautiful thing – like, “Oh, this once really tedious and problematic workflow that a person has tolerated for years is now made much more approachable or it’s so much easier to just pick up and use.”

01:02:47

Erin

That is, I think, the definition of beauty for me, but I often feel like beauty comes in this aesthetic sort of interpretation or what we see is the only thing that designers are able to produce. But I think to even get to that point where it’s clear, and engaging, and something that people want to use, and actually is transformative to their workflow, there’s a lot of work that goes into that, that you can’t do without being able to dive into that domain. Pretty is very much, for me, this byproduct of really understanding what you’re building.

01:03:14

Ron

Well, that seems like a great note to end on. Thank you so much for joining me.

01:03:17

Erin

Thank you so much. This was great.

01:03:21

Ron

You’ll find a complete transcript of the episode along with links to some of the things that we discussed at signalsandthreads.com. Thanks for joining us, and see you next time.