Erin Murphy on Designing Tools for Expert Users

Ron Minsky introduces Erin Murphy, a Jane Street UX designer whose career includes NASA’s Jet Propulsion Laboratory, independent design consulting and illustration. Their discussion connects the challenge of designing for scientists and spacecraft operators with the work of building tools for traders and engineers.

Murphy had assumed that people at JPL were scientists, engineers or roboticists, not designers. A champion at the lab wanted to bring human-centered design into spacecraft design and operations, and contacted her school while she was studying interaction design and user experience.

At the University of Washington she had also worked with a professor interested in testing and iterating interfaces in technical settings, including a Boeing cockpit design project. That experience showed her how storyboards could represent what a person is thinking while navigating a digital system.

For Murphy, human-centered design means going beyond the system or the idea of a product to talk with people individually about what they are trying to accomplish with a tool. Those conversations make the user's goals part of the design process.

One early JPL project sought to make Earth-orbiting mission data easier for scientists to find. Researchers had faced a laborious search across sites and personal contacts; the team wanted a consolidated portal with more useful information about the available data.

The data included atmospheric measurements such as carbon dioxide concentrations. The interface needed to make clear the level of processing, which satellite supplied a dataset and whether information came from a ground-based data center, so researchers could understand and compare its provenance.

Designing for experts in a domain she did not know was difficult for a new designer. Murphy says JPL taught her to be comfortable asking basic questions, learning how other disciplines think and exploring a technical environment without pretending to be an expert.

She interviewed scientists and attended an atmospheric research conference near JPL. Although she could not follow every presentation, she took notes, introduced herself and found researchers willing to explain their work. The approach later helped her understand Mars rover missions and continues to inform her work at Jane Street.

Minsky asks what colleagues learned from that research. Murphy recalls how storyboards resonated: they showed a scientist or rover planner using an interface, encountering a problem and reaching a possible solution, rather than only depicting the system’s internal mechanics.

JPL had large workflow diagrams nicknamed “bed sheets,” rich with boxes and arrows describing the system. Murphy's drawings added another layer: how a person moves between those systems, whether the page provides enough information and how scientific intent travels through the workflow.

A storyboard uses panels much like a comic strip. In one example a scientist specifies the science to be done, then a rover planner checks whether the rover can reach a location or position its arm for spectroscopy. The sequence gives colleagues a shared view of a day’s work across people and tools.

Murphy often draws while interviewing someone, making their explanation tangible and reflecting it back for correction. Because she is not herself a scientist or rover planner, reconstructing the experience helps her build intuition. She can revisit the storyboard with users as the design evolves.

Workflows can branch and rejoin, and Minsky asks whether storyboards capture those choices. Murphy says they can, though she often begins with a linear account to understand a complex process before adding the possible paths.

Murphy sees illustration and design as one practice rather than separate talents. Drawing lets her bring a possible future into the present, where people can ask whether it would be useful, test it and consider alternatives. For her, it is a tool for making sense of observations, not merely artistic expression.

She encourages others to draw even if they feel insecure about their skill. A messy sketch can honestly signal that the answer is not settled and invite a colleague to add an idea. Engineers already draw systems at whiteboards; Murphy adds the layer of what a person sees and does.

Murphy learned about Jane Street through a friend and was initially skeptical about what a designer would do at a quantitative trading firm. Her curiosity about complex systems and the opportunity to work with knowledgeable people led her to interview; the conversations helped demystify the work and the team’s ambitions for design.

She says older ways of building internal tools may not scale as the firm grows. People need better integrated tools that do not require guessing how to proceed, particularly when the user is not the engineer who built the original tool.

Murphy found that engineers already cared about user experience and had channels for feedback. Minsky adds that as a firm grows, simpler and more discoverable interfaces benefit more people, and the expanding number of interconnected tools makes learning each one more demanding.

Watching real users is a distinct skill, Minsky says. An interface can seem obvious to its builders until they see someone encounter it for the first time. Murphy’s early work demonstrated how much a team could learn from observing that experience.

Her first project involved a meeting tool that combined audio and video options, including a separate low-latency audio system. She watched people create a meeting, enter a room and try to start it, recording the points where the interface confused them and sharing observations with engineers.

Minsky notes that a meeting joining people in New York, London and remote locations sounds simple but has demanding audio and latency requirements. The team spent years refining the system; scanning a marker to identify a room and starting the right meeting with a button are examples of simplicity produced by substantial work.

Murphy’s initial observations showed too many ways to start a meeting presented with the same visual hierarchy. New users could struggle to know where to begin or feel confident they would hear and see colleagues. The solution had to respect the firm’s low-latency needs, not merely copy an outside product.

Asked how engineers received the design process, Murphy says they were receptive and recognized that user experience was a dimension in which they could learn. Building a working product that people also find useful requires the disciplines to adapt their collaboration together.

When the team discussed new features, she asked what users actually needed, what help channels showed and how people completed the task today. These questions brought attention to users who were not in the planning room before the team assigned priorities.

Murphy's usual research method was a scheduled session in which a person attempted tasks while she took careful notes. At Jane Street she has also adopted lighter, in-the-moment conversations: noticing someone using a tool and asking about the experience as they work.

She still sees value in structured one-on-one research, particularly for a new product. But an environment where colleagues readily talk at desks or in hallways gives her opportunities to observe work in context, build relationships and learn the language of an unfamiliar domain.

Minsky connects this communication style to office layout. People sit close together on large trading floors, and even small changes in distance can change who talks to whom. Moving groups closer or farther apart can unexpectedly alter communication patterns.

Murphy describes a help channel that reports when someone logs into a tool. An engineer added an approximate indication of the user's distance, making it easier to find someone nearby and ask about their experience. Those conversations can feed continuous iteration into the design.

The discussion shifts from meeting tools used by almost everyone to expert tools. Murphy works on Blueprint, for managing and provisioning applications, APD, for running apps and automated jobs, and observability tools that reveal performance across distributed systems.

Unlike a meeting, scheduling a job or operating an application is not part of her own ordinary workflow. She therefore relies on engineers who use the tools to explain their goals and where current systems fail them. Minsky says growth has made that separation between builder and user increasingly common.

Minsky asks how expert tools differ from consumer products. A consumer interface may gradually introduce information and use generous space, while someone who works with a tool every day may want dense information and rapid access instead.

Murphy says the feedback initially surprised her: users wanted smaller fonts, less white space and more information on screen. They also wanted responsive layouts because they might shrink a tool into one corner of one of several monitors.

Minsky describes workstations with multiple monitors covered by small views into live systems, often with alerts and sounds. Spreadsheets, text editors and terminals exemplify the dense, functional interfaces many employees rely on; users may prefer more lines of code over decorative interface elements.

Those tools have limitations too. Minsky recalls a large codebase with limited ability to draw visualizations, and points to tooltips as a simple way for a graphical interface to provide help exactly where it is needed. Web interfaces offer these capabilities, though something valuable may be lost in a transition.

APD presents this tradeoff: Murphy is working on a web experience for an existing command-line tool, with better integration into other applications. Minsky notes that the terminal restricts visual choices, which can protect users from poor design even as it limits what designers can show.

Simply placing a command line inside a browser is one possible transition, but it may not use the web’s full capabilities. Murphy has become more aware of users who keep their hands on the keyboard and now considers clear key bindings and keyboard navigation as part of her design principles.

Minsky says keyboard sequences can be much faster for experienced users, who develop fluent habits and remain in a flow. Murphy says web replacements need to preserve expected behavior for common and consequential actions, including the critical key bindings users rely on.

If a replacement ignores those habits, people may refuse to adopt it and continue tolerating an older system that no longer scales well. Murphy therefore tries to understand and prioritize the keyboard translation early, before a new interface disrupts important workflows.

Minsky cites Vim, Emacs and VS Code as examples of different philosophies for expert keyboard tools. Many editors grew from tools engineers built for themselves; he asks how to combine that close domain insight with the broader methods of interviewing users and designing for them.

Murphy calls that one of her central challenges. She will not become a trader or an engineer, but she can develop more intuition and empathy by immersing herself in their environment, observing their work and seeing how different tools fit together. She does not claim to have solved the problem.

At the time of the conversation Murphy was the firm’s only UX designer, and the team was looking for another. She sought people who had shipped products, learned from users’ responses and demonstrated that they could enter unfamiliar, complex domains and work with experts.

She hopes a growing design team will eventually bring perspectives from many disciplines. For the immediate role, the ability to clarify what needs designing and what challenges users face is especially valuable, whether a candidate’s background is in finance, aerospace or robotics.

Murphy says Jane Street gives her unusual access to users and to the systems behind their tools. She has even navigated those systems through a command line, a depth of technical involvement she had not expected when she imagined her design career.

Compared with previous environments where a designer might hand off requirements without knowing how a system would be built, she has experienced a more holistic process. Engineers have taken time to explain distributed systems and implementation constraints without making her feel judged.

Minsky identifies two benefits: going deep into a domain and collaborating closely with engineers. He argues that good software often finds a solution that is simple both for the end user and for the people implementing it, which requires the disciplines to work together.

The hardest adjustment for Murphy is accepting that her knowledge of a domain will not equal her users’. The firm is also moving from a culture of quickly creating and teaching internal tools toward more holistic experiences for users with different expectations, including web interfaces.

Minsky hopes that evolution does not sacrifice the flexibility of quickly building tools. He values the command line’s composability: commands share conventions, and pipes let people combine programs that were not explicitly designed to work together.

Graphical interfaces offer advantages such as tooltips, but Minsky considers it an open challenge to retain that kind of composability. He asks Murphy how to preserve extensibility as tools such as Blueprint and APD connect technical components.

Murphy says she has not thought about the question as extensively. Her approach has been to use consistent navigation, layouts and visual patterns across applications, including observability tools, so that people can more readily understand what is in front of them.

A design system can package reusable components, buttons, colors and states for people building their own web applications. Minsky agrees that reusable widgets have value, while distinguishing that from the harder problem of connecting independently built tools.

He describes one trading-desk pattern in which one tool publishes the security currently in focus and other independent tools follow it. He also considers interfaces that let users build dashboards graphically and then inspect or edit a textual representation, or switch between filter controls and a query language.

Minsky asks about beauty in UX design. Murphy is wary of the idea that a designer arrives at the end merely to make an interface pretty. Sometimes “pretty” means clear and reassuring, she says, but it can also obscure the domain research and functional decisions that good design requires.

Murphy argues that clarity and beauty depend on understanding a tool’s mechanics, environment and complexity. Applying a final coat of polish without that understanding can limit both what gets built and the designer’s collaboration with the team.

Minsky responds that visual appeal can matter functionally because of how people see and interact with information, even though judgments are subjective. Murphy agrees it is subjective; she uses established patterns for color and type while concentrating on what users are trying to do.

When someone calls an interface prettier, Murphy wants to know whether it actually helps. For her, beauty is making a tedious workflow approachable and useful in daily work. The visible polish is a byproduct of the deeper work of understanding the domain and designing for it.