Signals and Threads - From the Lab to the Trading Floor with Erin Murphy

Episode Date: July 12, 2024

Erin Murphy is Jane Street’s first UX designer, 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.You can find the transcript for this episode  on our website.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.

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, is 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. Thank you so much for having me. So I just love the fact that you worked at 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 kind of 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? 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 kind of fit into that sphere. And I certainly, when I joined JPL, I feel in a lot of ways that I kind of 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 early enough stage where there was 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. And so it happened that they reached out to the school. And at the time, I was actually working with a professor 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 that 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 like knowing the right individuals who are looking for that type of talent. When you talk about this process of building and designing things with humans involved in that process, is that kind of what you mean when you talk about human-centered design?

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 one-on-one chance to discuss what they're trying to achieve with the tool. That's what I typically find myself doing. 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 kind of mentioned there was someone there who championed the idea, but in what kind of context, what kind of projects were being worked on?

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 like the standard, I guess, catalog that a lot of scientists were used to, where you didn't have as much insight's not like the standard, I guess, catalog that a lot of scientists were used to where you didn't have as much insight into maybe like 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. You said Earth-based data. Is that like geospatial information about the Earth itself, about the Moon, about like what's the data sets? Mostly Earth and specifically like CO2 concentration and just understanding the composition of our atmosphere. And so there was different data

products that were available to people. And we wanted to create kind of 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. So you wanted their surface, both the data and the providence, essentially, of where the data came from. Yeah, exactly. 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?

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. You hadn't previously studied astrophysics before going to JPL? I really hadn't. I think the most that I got from my experience in school that kind of prepared me for this was probably working with a lot of the students within the engineering program and just kind of 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 just how to kind of 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 just 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. 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 like a pretty, I think, straightforward problem space that I would do totally differently. But in addition to trying to think about like, 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. From what I remember, there was like 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 understand what was going on in the presentation slide deck, but was able to kind of 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 was 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, 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. So you talked a lot about ways in which you learned in the process, which it seems like

you're really focused on your self-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 that are paying attention, I imagine they get surprised and learn things too. Do you have like examples of the kinds of things that the colleagues you were working with learned things from these interview processes? I remember the feeling of having people get excited about storyboards. We've talked about this, I think, in the past 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 bed sheets, which are huge workflow diagrams that really just articulate how will this system 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. 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 kind of 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 kind of 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. So for someone who's never seen one before, what is a storyboard? 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 kind of 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 kind of 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 kind of outlining an actual panel, very much like a comic strip, essentially, that helps people just kind of envision what you are seeing as like the day in the life of that scientist and collaboration with the rover planner in collaboration with the actual software tool. 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 kind of 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? 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 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 recreate that experience. 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'm 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. Are these storyboards actually always sequential? When I think about a 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? 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 just so, again, I'm working often 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. 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? 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 assume 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 like a place 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 a 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 kind of interrogate it and think about like, well, is this actually going to be useful? Should we test it with some people? Are there other ways we can do this? I just feel like 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, 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 just makes that real to me in a lot of ways. How universal is this? Do other designers who are also in the kind of the human-oriented design space, is doing this in a very drawing-focused way a common approach? 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 are engineers, there's aerospace, there's all these kind of 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. 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 like the thing. Yes. And also our drawing skills are less good. There's kind of like layers, right? Like 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. If this is how we've

built out the backend and if this is how the data is 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 kind of interesting to draw with people. And I try to encourage my engineering colleagues to do that wherever we can. So you've had a really interesting and varied career as a designer. How'd you get here? So honestly, the way I got here, I hadn't heard of Jane Street before. It is not something that... We're not really big in the design world. 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. 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. 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 of it, but I was also just curious. I just 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 like

not wrapping my head entirely around what the firm was trying to do. 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. 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? 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 like, well, 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. 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 like 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. You want to keep the cross-terms down, the amount that you pay for all of these extra connections. You want to get value from all the things that people build without it being as much friction for people. And you mentioned that people already cared about this kind of user experience question, which I think is right. But another aspect of it, 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, it's 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 learn through this and stuff that they thought was going to be like 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 are holding it wrong. So yeah, and I think that's one of the values that comes from having people who've just done this before. 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. 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 kind of see like 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. Yeah. And the whole thing of having a meeting, it seems like such a simple thing.

Yeah. 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 like the average user of Zoom, both in like the size of the meetings and the latency requirements on 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. And from my perspective, I feel like over, you know, years as we built this out and worked on it, I got to over 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's 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 to 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 as a regular basis, like I walk and I think, oh, this stuff is so nice. Like I walk and 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 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. 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 like what were the things that needed to be improved. I think one of the things specifically was just there were so many different ways that you could start your meeting. It wasn't just one simple button, which we've kind of evolved into now or 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.

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 like 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.

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, right? 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. 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? I feel like I was lucky because I feel like the engineers just recognize that there's like 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 kind of 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 should it function. And then, oh, yeah, we should probably make a UI so that people can use it. That's like kind of 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, like, what do you need to do to make something more user-friendly? Yes, it was very much, oh, whenever we were presenting new features or we were identifying, like,

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 I felt like through asking questions around like, well, do people need this? Have you received a lot of insight from like 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 like, what are people

doing before we actually assign any kind of priority on like 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. In some sense, that all sounds like a much better experience than I would have expected. I just feel like it's really...

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, like, how are they able to use the latest build of our tool together? And I will take notes diligently on like 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 kind of 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. I've had to like 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 like going up to people in the moment and asking them like, oh, you've noticed that you logged into this product. And I'm just kind of curious like 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 a more organized research efforts that I would do.

It feels kind of now like we're actually trying to find even more lightweight ways to gather information as the person's using the tool. And how does that tie into what you see as the culture of the firm? Like why culturally is that more ad hoc lightweight stuff seem more preferable? 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 greenfield, 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 like 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 kind of relationship of who that person is, what they're trying to do with the tool and like where they might be running into some kind of issue. And I felt like that was more of a cultural thing. And it kind of 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 I felt like that's a Jane Street

experience that I've had, and I've been wanting to adapt my approach to research around. It's interesting. I think of that as a cultural thing. It's very kind of free-flowing communication style, but it's also like a cultural thing that's reinforced by architecture. The way we lay out the people is like 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 of 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. Oh, absolutely. Yeah. And there's actually this new feature that we had added to our Help Slack channel that 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. Like this person is 54 meters away from you or this person is like two floors above you. And so, I don't know, even just like knowing where they're located and having an awareness of, oh, I just like walk 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. 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, right? Building systems designed for people who are expert 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? There's a few projects that I'm

working on. The one that actually I 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 like some of the main tools that are kind of outside of the realm of relatable workflows. 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 sort of 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. I think, Aki, this has been a lot of how I think about the development of how we've built tools for people over time is early on, we were all able to rely on the fact that we're essentially building tools for ourselves, right? 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. 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. Yeah, it definitely takes you out of your comfort zone, I suppose. 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 was thinking a little bit like 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 the new thing that all feels very different from what you want to optimize for when you're building a tool for someone every day they're coming in and doing their job deeply integrated with this tool. How does that like difference in goals affect the way the designs work out? 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. Like that's, that is a very common piece of feedback that I get. And a lot of individuals are just, 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, like, is there any more information that I could see for this state of this job or this app? Like, 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 like the left-hand side and, you know, one of four monitors that I'm using. So their environment is like very different from what I think I would design for

if I was creating an experience for an average consumer. Yeah, it's maybe worth painting a picture of what a typical workstation looks like here. There's almost a bare, you know, human rights minimum. You have to have at least two monitors. Someone on a trading list 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 they're all like blinking lights and noises going on. Lots of noises, infinite noises. Traders move to our floor and now I get to hear the cacophony of things happening. I'm always curious what they mean, but yeah. And when I think of what are the prototypical user interfaces that people really dive into and use a lot, there's 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 like as many lines of code as 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, you know, 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. It just doesn't exist. That's right. Like, 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. You know, at some point in our evolution, we had, I don't know, five million lines of code in our code base, but not the ability to draw a straight line. So the ability to do it.

Very limited ability to do visualizations, certainly in a kind of programmatic way. And another way in which I think these kind of user interfaces tend to be impoverished is they're not very good at providing you help. Just the basic affordance of a tooltip is magic, right? 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. 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. It's probably not a good description of it. But yeah, for me, I'm following you. AppD feels like 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. So like one of the nice things about terminals

as a way to surface UIs is they give you very few choices, which is like a weird thing to think is good, right? 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 kind of 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 reign to design web UIs, you're going to get a lot of eye-bleeding bad designs that are confusing and hard to use. 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 kind of just behave as if you were in a CLI, but you're actually in a browser and a web browser itself. That's a way to go. It's not really taking full advantage, I guess, of some of the other things you can do 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 it looks like a command line i'm like oh now i feel comfortable being able to like just maintain your hands on the keyboard at all times it's 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 kind of translating away from a command 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 kind of 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 like something that is now very much a part of my approach now or a set of principles, I suppose,

that I kind of refer back to as I design more experiences within Jane Street. 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. 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, go, go in a much smoother way. Again, for an expert, right? 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. 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, yeah, 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, you're going to change the status of something. If there's like a set of actions that people are used to doing and they have a critical impact on your system, those need to behave in a way that they expect and that they've experienced already in their command line interface. 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. 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 like 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. You know, these tools were like designed in the 70s, many of them, and like 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 sort of 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. But it'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 like 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? I think about that as being one of the bigger challenges of my probably design career at Jane Street, for sure. It's just, 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 in their 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. 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 kind of like being immersed in that environment and having these conversations with people where I'm able to observe in real time what they are 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 observe in real time what they are actually doing and see exactly how they're trying to integrate these different tools into their workflow. That's the thing I'm like most interested in learning more about. 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, like, 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 the kind of problems that you would be excited about working here? Yeah, we're actively looking for another user experience designer that's excited about learning about this particular domain and has already the skill set 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 like 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 like 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. So essentially, are you looking for people who had the experience of building for people who are experts in things that they themselves are not experts in? 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 like 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 kind of looking to see if there are individuals who are able to kind of 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. So that exactly what the challenges are for people that are working on these types of tools. 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? 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 like 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 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 kind of live in this design research

space and think at a high level on like what things need to happen. And never would I venture into the depths of how it was built out. But in creating these relationships with my colleagues and learning what people actually need from their tools, I see it as like 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 kind of 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 like this more holistic process of how we actually make a functional tool. And like, what are some of the things that people will run into? What challenges people will run into with that new system? Like, 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, are learning a little bit more how we architect these distributed systems. All of those things are pretty foreign and just outside of my scope of knowledge. But there is 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 and 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 right 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 kind of working back and forth with the people who are building the system. On that latter point, I sort of wonder, like, how do you even do it the other way? It seems really hard to, like, design a thing where you're not working closely with the engineering team because I feel like if you're just kind of designing what you want the thing to be, the world kind of seems very wide open. There's lots, you know, 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 like a profound value, both in design and in software engineering. Finding that kind of 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? 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. 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 like transitioning away from what they're used to which is being able to kind of 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 like a web experience and maybe sometimes even a preference to have a web experience over something like an existing CLI. Although my hope is that we don't like totally give up on that flexibility of just kind of 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 like one of the kind of 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 like pipe operator, the ability to like run a bunch of commands and pipe output from one to the other. And the whole

system has been engineered so that there's like a kind of standard way in which you represent data or a few standard ways in which you represent data. And it's like 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 kind of 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 tool tips, 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. Something about having this kind of 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 Apti that are more about connecting lots of technical pieces together, this kind of extensibility, like how do you retain that? I haven't really thought as extensively about this.

I guess the way that I kind of approach building out these tools for like Apti and Blueprint right now is like there are things that you can communicate through consistent navigation, consistent layout of a page that can like help a person make sense of the information in front of them graphically without having to kind of read through. Again, like I don't really use that much of these command light interfaces. I don't entirely always know like what it feels like to have something that you can actually like 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 Apti and Blueprint, but even for like some of the newer tools that we're seeing emerge for like some of our observability platform applications. And I think that that maybe is like the way of having some, I don't know if you can really like spin up things and like 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 like 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 like taking a lot of the design system work that we had done early on of like creating these consistent components, consistent buttons, the right kind of coloring. And when you have like a certain button state, there's consistent states that you would see. All of that can actually be kind of 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. Yeah, for sure. There's like some important kind of 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 like, there's a lot of work we've done on the kind of web programming side to make that kind of component stuff really good. The thing that I feel like is hard to do is this kind of cross tool compatibility of like, you built a tool and you built a tool and you built a tool. to make that kind of component stuff really good. The thing that I feel like is hard to do is this kind of cross-tool compatibility of like you built a tool and you built a tool and you built a tool. And now you want to like hook all those tools together. I've seen some patterns that I think work reasonably well.

One of the things that like 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 are paying attention to? And then maybe a bunch of other tools in the backend, you know that tool will publish that information the other tools can watch it and then like something changes and like all of your tools even though they were implemented independently will all kind of change focus at the same time to pay attention to the new thing

you're doing so that's like one way of getting things to hook together another thing i feel like i've seen done but i don't know i've ever it done well, is there's some kinds of tools where you try and have a dual life to the UI. So there's these cool like dashboarding apps where you can like click some buttons and create some views and create some buttons and create some sources of data that pull different sources of data and kind of create a visualization that then people can like watch and interact with. 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 like edit in a different way and commit to a source code repository. And so like having like this dynamically constructed structure of the UI, 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 like edit and transform it or even programmatically generate those. So I feel like that's like a kind of thing that you see like little versions of that. Another actually good example is like 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 like

a SQL-like query language, unless you do it. And sometimes there are UIs where you can like click buttons to say filter down SQL-like query language, unless you do it. And sometimes there are UIs where you can like click buttons to say, filter down to this, filter down to that or whatever. And one thing you can do is you can have like the set of buttons that you do could behind the scenes be like 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? Oh, God.

I mean, that's probably the best response to it. I'm always like trying to avoid the concept that like the designer has come to the engineering team and their role is to help make the UI pretty. I think that's like a shorthand for a lot of people that it's not entirely like dismissive. I think that for people, pretty is actually a term that means like, 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 like a shorthand for like 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 like 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 like what this tool should do for a person. 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 like making things pretty, that kind of quote or that term, and it doesn't seem to bother people as much. I think that for me, it just kind of erases like 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 like the complexities of it. I don't think that you can just like be brought into building out a tool and just like polish it. Like you need to actually understand the mechanics of what it is, what environment it exists within.

There's almost something dismissive about talking about being pretty, because it's just like putting a fresh coat of paint on a thing. 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. There's a little bit, 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 like, I don't know,

something about the visual appeal, I feel like 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, right? I think. 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 like 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 like a screen, but I very rarely am like prioritizing it. It's almost like I will 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 like, how can you use all those pieces to kind of like orchestrate that desired experience? It's not the primary thing that you're thinking about. It's not even like 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. It's 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 kind of pick up and use. That is, I think, the definition of beauty for me. And I, but I often feel like beauty comes in this like kind of aesthetic sort of interpretation or like what we see is like the only thing that designers are able to produce.

But I think to even get to that point where it's like 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 that you can't do without being able to dive into that domain. Pretty is very much for me like this kind of byproduct of really understanding what you're building. Well, that seems like a great note to end on. Thank you so much for joining me. Thank you so much. This was great.

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.